2015/04/12 開催 "Amazon Web Service vs Google Cloud Platform" でのセッションで用いたスライドです。 http://gcpug-tg.connpass.com/event/13704/

1. 弊社・フィードフォースとAWSと私
いのうえ（@a_know ）

2. ...で、誰？

3. 自己紹介
4 いのうえ（@a_know）大都会岡山出身
4 株式会社フィードフォース
4 Webアプリケーションエンジニア
4 新人教育 / リーダー業務
4 COBOL → Java → Ruby
4 前職は GCP（GAE）エンジニア
4 スクラム開発

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

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

11. ... I Love GAE!!

12. !

13. ブログもやってます

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

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

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

17. !

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

19. ...で、どこ？

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

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

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

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

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

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

27. !

28. では本題

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

30. 今日はどんなおはなしをするか
4 AWS について
4 ぼくはアプリケーションエンジニア
4 なので、お仕事でやったことがあることメイン !
4 AWS は基本会社でしか触っていない（貧者） ! !
4 ので、「弊社と AWS」的なお話しになります ! ! !

31. AWS

32. 基本情報
4 Amazon Web Services
4 アカウント登録して Go!

33. 基本情報
4 Amazon Web Services
4 アカウント登録して Go!

34. 基本情報
4 Amazon Web Services
4 アカウント登録して Go!
4 一番小さいサーバインスタンス 1年間相当が無料

35. 基本情報
4 11リージョン

36. 基本情報
4 11リージョン
4 特定のリージョンでしか使えないサービスも
4 リージョン毎に Availability Zone
4 物理的に異なるデータセンター

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

39. 弊社と AWS

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

41. 弊社と AWS
4 ローンチまでにサーバ買って、ラックに設置して...
4 遅い
4 将来的な負荷増大もある程度見込んだ性能を...
4 高い
4 クラウド利用のメリット ＞ 従来までの手法のメリット
4 クラウド ≒ AWS 、だった当時

42. 弊社と AWS
4 3年後、別プロダクトで本格利用
4 DBサービスやロードバランサ等、サービスが出 ってきた

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

44. 求められていたこと①

45. 求められていたこと①
4 プロダクトを稼働させるサーバー
4 従来までのスタイル故の "つらみ" からの脱却
4 迫り来る保証期限
4 not disposable
4 配線やラッキングなどの職人芸
4 選ばれし者のみ触れられる聖域
4 プライベートネットワークが構成できること

46. EC2

47. EC2
4 Amazon Elastic Compute Cloud
4 仮想サーバ
4 GCP でいうと Google Compute Engine
4 従量課金、課金単位時間は 1h
4 reserved / spot instance
4 弊社サービスは基本 EC2 上で

48. EC2
4 AWS Marketplace でイメージ（AMI）を subscribe して
使う

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

50. EC2
4 スペックよりどりみどり
4 汎用：t2, m3, ...
4 CPU特化：C3, C4, ...
4 メモリ特化：R3, ...
4 それぞれに small / medium / large ...
4 t2 シリーズには "バースト" が

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

52. EC2
4 Chef-solo で構成管理 ＆ インフラCI
4 CI からテスト用の EC2 インスタンスを立ててた時期も

54. EC2
4 ! が最初にサーバ構築するときは...
$ knife solo bootstrap product
$ rake spec:product

55. EC2
4 ! が構成を変更・追加するときには TDD で！
(edit serverspec)
$ rake spec:vm
(spec failed & edit recipe & cook)
$ rake spec:vm
(spec ok!)

56. ちなみに

58. EC2（VPC）
4 何もせずに EC2 インスタンスを立てると、 default-VPC
に属した状態になる
4 Amazon Virtual Private Cloud
4 仮想ネットワーク
4 ネットワーク内でサブネットや ACL の設定が可能
4 異なる AZ をまたいでの設定も可能

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

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

61. 求められていたこと②

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

63. RDS

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

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

70. 求められていたこと③

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

72. S3

73. S3
4 Amazon Simple Storage Service
4 GCP でいう Google Cloud Storage
4 99.999999999 ％の耐久性
4 99.99 ％の可用性

75. S3
4 ただのファイル置き場...じゃない！
4 permission
4 logging
4 Cross-Region Replication
4 ...

76. S3
4 static resources hosting

77. 求められていたこと④

78. 求められていたこと④
4 巨大なファイルを日次で解析してほしい
4 ファイルによって異なる解析をする必要がある
4 複雑な解析方法に対しても柔軟に対応してほしい
4 「そのためのサーバ」をまた別途構築しなきゃいけない...
よね？（だから時間が掛かるよね？）

79. EMR

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

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

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

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

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

86. How to use EMR
4 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

87. 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

88. How to use EMR
4 これで起動するだけで、
4 指定した数だけ EC2 インスタンスが立ち上がり
4 自動で Bootstrap(含 Hadoop)、クラスタ管理されて
4 Mapper / Reducer として指定したスクリプトも各イン
スタンスに配置されて
4 指定した入力ファイルを mapper の標準入力に渡し
4 （つづく）

89. How to use EMR
4 （つづき）
4 Mapper の標準出力はそのまま Reducer の入力とな
り、reduce 処理も行われる
4 Reducer の結果は output で指定した場所に出力
4 処理が全て終われば、インスタンスは全て自動で
terminate される

90. EMR
4 「Mapper / Reducer をどう書くか？」だけに集中できる
ような EMR 基盤の仕組みを用意
4 ...が、最近 Google BigQuery の production 利用が開始
4 EMR に取って変わるかも？

91. 求められていたこと⑤

92. 求められていたこと⑤
4 自社のサービスを安定的に提供し続けていきたい
4 サーバに異常があったときはすぐに知りたい
4 サーバのスペック変更などが必要なタイミングを前もって
把握しておきたい
4 サーバの状態の推移・傾向を知りたい

93. Cloud Watch

94. Cloud Watch
4 監視＆モニタリングを簡単に実現

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

99. Cloud Watch
4 これらについてのメトリクスも確認可能
4 ただし2週間分... cacti を併用

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

101. Cloud Watch
4 事前準備が必要なものもある
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

102. 求められていたこと⑥

103. 求められていたこと⑥
4 AWS のアカウントの使い回しはセキュリティポリシー的に
やめたい
4 開発者毎にアカウント的なものを設定出来るようにして
欲しい
4 不慣れな人（たとえば新人さん）の誤操作で事故につな
がらないようにして欲しい

104. IAM

105. IAM
4 AWS Identity and Access Management
4 ある AWS アカウントにアクセスするユーザー・グループを
管理
4 アクセス権をコントロール
4 無料

107. 求められていたこと⑦

108. 求められていたこと⑦
4 知らないうちに、変なところから変な操作されたりしてな
い？
4 意図してない AWS 操作は発生してない？
4 その証左をいつでも提出できる状態にして欲しい

109. Cloud Trail

110. Cloud Trail
4 アカウントの AWS API の呼び出しを記録
4 AWS マネジメントコンソール
4 AWS SDK
4 CLI（コマンドラインツール）
4 AWS CloudFormation など）を使用した API の呼び出
しも

111. Cloud Trail
4 Cloud Trail 記録用の s3 bucket を指定
4 API 呼び出し元の ID
4 source IP address
4 リクエストのパラメータ、レスポンス
4 これらが json で記録

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

114. その他、弊社で利用している AWS
サービス
4 「ドメイン設定して欲しい」
4 Route 53
4 DNS, failover とかも

115. その他、弊社で利用している AWS
サービス
4 「CDN って手軽に用意できないかな？」
4 Cloud Front
4 「キャッシュ・セッションストアってさ...」
4 ElastiCache
4 これらは触ったことがないです... orz

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

117. 良い（と感じている）ところ
4 使っている人が多い
4 サポートが手厚い（と感じている）
4 安くはないかもしれないが、GCP との価格競争に応戦でき
ている
4 新しいサービスが次々と
4 （比較的）Ruby から扱いやすい
4 略称が（ほぼ）一意

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

119. いまいち（と感じている）ところ
4 単価が安くなっても、課金単位時間が 1h ェ...
4 後続の GCP に性能的に劣っているところが明らかになっ
てきた？
4 常に危険に晒されている感
4 仮想通貨採掘に利用されたケースも...

120. 感想とか

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

123. 感想とか
4 Web UI からポチポチやれば、サーバは簡単に立てられる
4 「そこでアプリケーションを安全に動作させる」というこ
とを考えると...
4 AWS （IaaS）に精通していること ＜ OS やミドルウ
ェアを適切に使うこと
4 セキュリティ、ネットワークに関する知識も
4 AWS 独自オプションで楽できたり、とかはある

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

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

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

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

128. 感想とか
4 PaaS での開発から IaaS での開発へ
4 ミドルウェアに問題があった場合、解決までのプロセス
は第三者に委ねるしかない
4 「いつ復旧するの？」...orz
4 「今度同じような障害があっても、次はもっと早く復
旧できるよね！」...orz

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

130. まとめ（的なもの）

131. まとめ（的なもの）
4 弊社・フィードフォースと AWS と私についてのお話
4 求められるものに対して、AWS は応えてくれてきた
4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud
Trail
4 良いと思っている点、いまいちだなと思っている点
4 個人的な感想

132. まとめ（的なもの）
4 弊社・フィードフォースと AWS と私についてのお話
4 求められるものに対して、AWS は応えてくれてきた
4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud
Trail
4 良いと思っている点、いまいちだなと思っている点
4 個人的な感想
4 I Love GAE!!!