弊社・フィードフォースとAWSと私

いのうえ（@a_know ）

...で、誰？

自己紹介4 いのうえ（@a_know）大都会岡山出身4 株式会社フィードフォース4 Webアプリケーションエンジニア4 新人教育 / リーダー業務

4 COBOL → Java → Ruby

4 前職は GCP（GAE）エンジニア4 スクラム開発

...(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ)... "vs" ...

　

... I Love GAE!!

!

ブログもやってます

代表的なエントリ（ぼく）4 「Google Compute Engine 入門」を読んで、AWS と GCP の違いをまとめてみた

代表的なエントリ（ぼく）4 gcp ja night #28 に参加してきたので色々まとめるよ

代表的なエントリ（ぼく）4 "Google App Engine for Java実践ガイド" を Go で書く！

!

株式会社フィードフォース

...で、どこ？

弊社紹介・株式会社フィードフォース4 文京区春日

弊社紹介・株式会社フィードフォース4 BtoB な自社サービスを開発（Ruby / Rails / AWS）

4 GitHub / heroku / Circle CI / slack

技術ブログやってますtech.feedforce. jp

代表的なエントリ（へいしゃ）4 CircleCI + DockerでサーバCI始めました

代表的なエントリ（へいしゃ）4 このブログはGitHub Pages＋CircleCIで運用しています

代表的な エントリ（へいしゃ）4 「LEGO(R)ではじめるスクラム入門」に参加してきました

!

では本題

今日はどんなおはなしをするか

今日はどんなおはなしをするか4 AWS について4 ぼくはアプリケーションエンジニア4 なので、お仕事でやったことがあることメイン !

4 AWS は基本会社でしか触っていない（貧者） ! !

4 ので、「弊社と AWS」的なお話しになります ! ! !

AWS

基本情報4 Amazon Web Services

4 アカウント登録して Go!

基本情報4 Amazon Web Services

4 アカウント登録して Go!

基本情報4 Amazon Web Services

4 アカウント登録して Go!

4 一番小さいサーバインスタンス 1年間相当が無料

基本情報4 11リージョン

基本情報4 11リージョン4 特定のリージョンでしか使えないサービスも

4 リージョン毎に Availability Zone

4 物理的に異なるデータセンター

基本情報4 AWS のアカウント ≒ GCP のプロジェクト4 ひとつの AWS アカウント内で複数プロジェクトを回すのはつらそう

4 プロダクト毎に AWS アカウントを作成

弊社と AWS

弊社と AWS4 弊社での利用開始は2009年1月4 当時ローンチしたサービス「えもにゅ」のため

弊社と AWS4 ローンチまでにサーバ買って、ラックに設置して...

4 遅い4 将来的な負荷増大もある程度見込んだ性能を...

4 高い4 クラウド利用のメリット　＞　従来までの手法のメリット4 クラウド ≒ AWS 、だった当時

弊社と AWS4 3年後、別プロダクトで本格利用

4 DBサービスやロードバランサ等、サービスが出揃ってきた

それ以降、数々の要求にAWS は応え続けて来てくれた

求められていたこと①

求められていたこと①4 プロダクトを稼働させるサーバー4 従来までのスタイル故の "つらみ" からの脱却4 迫り来る保証期限4 not disposable

4 配線やラッキングなどの職人芸4 選ばれし者のみ触れられる聖域

4 プライベートネットワークが構成できること

EC2

EC24 Amazon Elastic Compute Cloud

4 仮想サーバ4 GCP でいうと Google Compute Engine

4 従量課金、課金単位時間は 1h

4 reserved / spot instance

4 弊社サービスは基本 EC2 上で

EC24 AWS Marketplace でイメージ（AMI）を subscribe して使う

EC24 AWS Marketplace でイメージ（AMI）を subscribe して使う4 "Market" だけど、無料のものもここに登録されている4 自作のイメージを使うのにも Marketplace への登録が必要

EC24 スペックよりどりみどり4 汎用：t2, m3, ...

4 CPU特化：C3, C4, ...

4 メモリ特化：R3, ...

4 それぞれに small / medium / large ...

4 t2 シリーズには "バースト" が

EC24 ! が起動からセットアップをする場合4 Webコンソールからポチポチ...でも立てられる、けど4 gem aws-sdk & rake task で API 操作を自動化4 起動・停止・ステータス取得... etc.

$ rake ec2:create:product$ rake ec2:status:product

EC24 Chef-solo で構成管理 ＆ インフラCI

4 CI からテスト用の EC2 インスタンスを立ててた時期も

EC24 ! が最初にサーバ構築するときは...

$ knife solo bootstrap product$ rake spec:product

EC24 ! が構成を変更・追加するときには TDD で！(edit serverspec)

$ rake spec:vm

(spec failed & edit recipe & cook)

$ rake spec:vm

(spec ok!)

ちなみに

EC2（VPC）4 何もせずに EC2 インスタンスを立てると、 default-VPC に属した状態になる

4 Amazon Virtual Private Cloud

4 仮想ネットワーク4 ネットワーク内でサブネットや ACL の設定が可能

4 異なる AZ をまたいでの設定も可能

EC24 その他一般。4 Security Group でアクセス制限

EC24 その他一般。4 Elastic IPs で簡単にグローバル IP アドレス付与4 1アカウントで設定できる IP の数には限りがある

4 ELB でロードバランス

求められていたこと②

求められていたこと②4 立てたサーバからアクセスできる DB サーバが必要4 従来までのスタイル（ry

RDS

RDS4 Amazon Relational Database Service

4 GCP でいう Google Cloud SQL

4 Multi AZ は便利だなー4 "Amazon RDS のマルチ AZ 配置では、異なるアベイラビリティーゾーンに同期スタンバイレプリカが自動的にプロビジョニングされて維持されます。"

4 Automatic Failover

RDS4 Multi AZ は 1オプションで設定可能4 mandatory maintenance にも

求められていたこと③

求められていたこと③4 巨大なファイルをカジュアルに置いておく場所が欲しい4 空きディスクサイズにビクビクしたくない

4 http でアクセスできるようにして欲しい

S3

S34 Amazon Simple Storage Service

4 GCP でいう Google Cloud Storage

4 99.999999999 ％の耐久性4 99.99 ％の可用性

S34 ただのファイル置き場...じゃない！4 permission

4 logging

4 Cross-Region Replication

4 ...

S34 static resources hosting

求められていたこと④

求められていたこと④4 巨大なファイルを日次で解析してほしい4 ファイルによって異なる解析をする必要がある4 複雑な解析方法に対しても柔軟に対応してほしい

4 「そのためのサーバ」をまた別途構築しなきゃいけない...よね？（だから時間が掛かるよね？）

EMR

EMR4 Amazon Elastic MapReduce

4 Hadoop（MapReduce） を手軽に扱うためのサービス4 EC2 インスタンスを指定された数だけ起動4 各インスタンスで bootstrap action 実行4 EMR クラスタを構成4 これらを自動でやってくれる

EMR

4 EMR クラスタ4 マスター：全体の構成管理4 コア：データを読み込みつつデータ処理4 タスク：データ処理のためにリソースを提供（無くても良い）

Hadoop MapReduce ?4 Map → Shuffle → Reduce

4 Map : データを分割4 Shuffle : 分割されたデータを配分4 Reduce : 配分されたデータに対して処理を実施4 Hadoop を使うなら Map と Reduce のところだけ考えれば良い

Hadoop streaming4 Mapper / Reducer だけ作れば良い4 標準入力を受けられる・標準出力できさえすれば、どんな言語で書いても ok !

Hadoop streaming4 Map : データ（標準入力）をもとに "key <tab> value" の形式で標準出力すれば ok

4 Reduce : "key <tab> value" の形式で標準入力されるデータに対して行いたい処理をし、その結果を標準出力すれば ok

How to use EMR4 Web コンソールからの起動も行えるみたいだけど、もっぱら gem 経由（例はコマンドラインツール）

$ elastic-mapreduce --create --alive --name "Test Cluster" \ --instance-group master \ --instance-type m1.small --instance-count 1 \ --instance-group core \ --instance-type m1.small --instance-count 2 \ --bootstrap-action \ s3n://a-know-s3/bootstrap-actions/install.sh

How to use EMR$ elastic-mapreduce --stream --step-name "Test Streaming" \ --input s3n://a-know-s3/input/development.log \ --output s3n://a-know-s3/output/streaming_out \ --mapper 'ruby s3n://a-know-s3/mapper/log_mapper.rb' \ --reducer 'ruby s3n://a-know-s3/mapper/log_reducer.rb' \ --jobflow xxxxx

How to use EMR4 これで起動するだけで、4 指定した数だけ EC2 インスタンスが立ち上がり4 自動で Bootstrap(含 Hadoop)、クラスタ管理されて4 Mapper / Reducer として指定したスクリプトも各インスタンスに配置されて

4 指定した入力ファイルを mapper の標準入力に渡し4 （つづく）

How to use EMR4 （つづき）4 Mapper の標準出力はそのまま Reducer の入力となり、reduce 処理も行われる

4 Reducer の結果は output で指定した場所に出力4 処理が全て終われば、インスタンスは全て自動で

terminate される

EMR4 「Mapper / Reducer をどう書くか？」だけに集中できるような EMR 基盤の仕組みを用意

4 ...が、最近 Google BigQuery の production 利用が開始4 EMR に取って変わるかも？

求められていたこと⑤

求められていたこと⑤4 自社のサービスを安定的に提供し続けていきたい4 サーバに異常があったときはすぐに知りたい

4 サーバのスペック変更などが必要なタイミングを前もって把握しておきたい4 サーバの状態の推移・傾向を知りたい

Cloud Watch

Cloud Watch4 監視＆モニタリングを簡単に実現

Cloud Watch4 監視設定可能な項目4 CPU 使用率4 ディスクの Read / Write 量4 NW 通信量4 ステータスチェック4 CPU credit（t2）4 課金額（Estimated Charge with CloudWatch）

Cloud Watch4 これらについてのメトリクスも確認可能

4 ただし2週間分... cacti を併用

Cloud Watch4 Cloud Watch でしか取れないものもある4 RDS とか ELB などの AWS独自サービス4 agent などのインストールができないので...

Cloud Watch4 事前準備が必要なものもある4 デフォルトではメモリの監視ができない4 メモリの使用量を Cloud Watch に送信するような

script をインスタンス側に仕掛ける必要あり※1

※1: Amazon CloudWatch Monitoring Scripts for Linux - Amazon CloudWatch https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/mon-scripts-perl.html

求められていたこと⑥

求められていたこと⑥4 AWS のアカウントの使い回しはセキュリティポリシー的にやめたい4 開発者毎にアカウント的なものを設定出来るようにして欲しい

4 不慣れな人（たとえば新人さん）の誤操作で事故につながらないようにして欲しい

IAM

IAM4 AWS Identity and Access Management

4 ある AWS アカウントにアクセスするユーザー・グループを管理4 アクセス権をコントロール

4 無料

求められていたこと⑦

求められていたこと⑦4 知らないうちに、変なところから変な操作されたりしてない？

4 意図してない AWS 操作は発生してない？4 その証左をいつでも提出できる状態にして欲しい

Cloud Trail

Cloud Trail4 アカウントの AWS API の呼び出しを記録4 AWS マネジメントコンソール4 AWS SDK

4 CLI（コマンドラインツール）4 AWS CloudFormation など）を使用した API の呼び出しも

Cloud Trail4 Cloud Trail 記録用の s3 bucket を指定4 API 呼び出し元の ID

4 source IP address

4 リクエストのパラメータ、レスポンス4 これらが json で記録

その他、弊社で利用している AWS サービス

その他、弊社で利用している AWS サービス4 「ドメイン設定して欲しい」4 Route 53

4 DNS, failover とかも

その他、弊社で利用している AWS サービス4 「CDN って手軽に用意できないかな？」4 Cloud Front

4 「キャッシュ・セッションストアってさ...」4 ElastiCache

4 これらは触ったことがないです... orz

良い（と感じている）ところ

良い（と感じている）ところ4 使っている人が多い4 サポートが手厚い（と感じている）4 安くはないかもしれないが、GCP との価格競争に応戦できている

4 新しいサービスが次々と4 （比較的）Ruby から扱いやすい4 略称が（ほぼ）一意

いまいち(と感じている)ところ

いまいち（と感じている）ところ4 単価が安くなっても、課金単位時間が 1h ェ...

4 後続の GCP に性能的に劣っているところが明らかになってきた？

4 常に危険に晒されている感4 仮想通貨採掘に利用されたケースも...

感想とか

感想とか4 「AWS をやってる」というよりは「IaaS をやってる」（稼働環境を自分で作ってる）という気持ち4 でもやっぱりロックインは多少されてる感4 （お仕事で）EC2 の代わりに GCE を使う未来？4 学習コスト・既存資産　＜　導入メリット？4 用途と目的により使い分けていくのかなぁとか

感想とか4 Web UI からポチポチやれば、サーバは簡単に立てられる4 「そこでアプリケーションを安全に動作させる」ということを考えると...

4 AWS （IaaS）に精通していること　＜　OS やミドルウェアを適切に使うこと

4 セキュリティ、ネットワークに関する知識も4 AWS 独自オプションで楽できたり、とかはある

感想とか4 Chef が導入されたことなどにより、インフラエンジニアの「作業」が僕らにも "見える" ようになってきた4 「サーバを立てて、そこでアプリケーションを安全に動作させる」ことのプロが、インフラエンジニア（だと思う）

4 今後もしばらくは "プロ" と相談しながらじゃないとキツそう

感想とか4 Chef が導入されたことなどにより、インフラエンジニアの「作業」が僕らにも "見える" ようになってきた4 動作確認とか技術検証とかはインフラエンジニアを介さなくても可能になってきているのは !

感想とか4 PaaS での開発から IaaS での開発へ4 新鮮、勉強になってる（知らないことだらけ）4 「奥の手」を使ってなんでもできる感じ（？）

感想とか4 PaaS での開発から IaaS での開発へ4 PaaS がいくら便利でも、やりたいことが出来なかったら使えない4 僕らにはどうにもできないハードルがあったりする4 「すみません、（技術的に）できません...」が、一番悔しい

感想とか4 PaaS での開発から IaaS での開発へ4 ミドルウェアに問題があった場合、解決までのプロセスは第三者に委ねるしかない4 「いつ復旧するの？」...orz

4 「今度同じような障害があっても、次はもっと早く復旧できるよね！」...orz

感想とか4 PaaS での開発から IaaS での開発へ4 PaaS のアプリケーション開発に集中できることのメリットは大きい4 最終的には GAE + MVMs みたいなところに繋げたい

まとめ（的なもの）

まとめ（的なもの）4 弊社・フィードフォースと AWS と私についてのお話4 求められるものに対して、AWS は応えてくれてきた4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud

Trail

4 良いと思っている点、いまいちだなと思っている点4 個人的な感想

まとめ（的なもの）4 弊社・フィードフォースと AWS と私についてのお話4 求められるものに対して、AWS は応えてくれてきた4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud

Trail

4 良いと思っている点、いまいちだなと思っている点4 個人的な感想4 I Love GAE!!!