フィードフォースと AWS と私

3,579 views

Published on

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

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
  • 当日頂いたご質問のうち、回答できなかったものについて、こちら https://gist.github.com/a-know/a44f3da1b39a96f4a53a にて回答致しております。合わせてご確認頂ければと思います。m(_ _)m
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
3,579
On SlideShare
0
From Embeds
0
Number of Embeds
1,990
Actions
Shares
0
Downloads
7
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

フィードフォースと AWS と私

  1. 1. 弊社・フィードフォースとAWSと私 いのうえ(@a_know )
  2. 2. ...で、誰?
  3. 3. 自己紹介 4 いのうえ(@a_know)大都会岡山出身 4 株式会社フィードフォース 4 Webアプリケーションエンジニア 4 新人教育 / リーダー業務 4 COBOL → Java → Ruby 4 前職は GCP(GAE)エンジニア 4 スクラム開発
  4. 4. ...(つд )ゴシゴシ
  5. 5. (;゚д゚)... "vs" ...
  6. 6.
  7. 7. ... I Love GAE!!
  8. 8. !
  9. 9. ブログもやってます
  10. 10. 代表的なエントリ(ぼく) 4 「Google Compute Engine 入門」を読んで、AWS と GCP の違いをまとめてみた
  11. 11. 代表的なエントリ(ぼく) 4 gcp ja night #28 に参加してきたので色々まとめるよ
  12. 12. 代表的なエントリ(ぼく) 4 "Google App Engine for Java実践ガイド" を Go で書 く!
  13. 13. !
  14. 14. 株式会社 フィードフォース
  15. 15. ...で、どこ?
  16. 16. 弊社紹介・株式会社フィードフォース 4 文京区春日
  17. 17. 弊社紹介・株式会社フィードフォース 4 BtoB な自社サービスを開発(Ruby / Rails / AWS) 4 GitHub / heroku / Circle CI / slack
  18. 18. 技術ブログやってます tech.feedforce.jp
  19. 19. 代表的なエントリ(へいしゃ) 4 CircleCI + DockerでサーバCI始めました
  20. 20. 代表的なエントリ(へいしゃ) 4 このブログはGitHub Pages+CircleCIで運用しています
  21. 21. 代表的な エントリ(へいしゃ) 4 「LEGO(R)ではじめるスクラム入門」に参加してきました
  22. 22. !
  23. 23. では本題
  24. 24. 今日はどんなおはなしを するか
  25. 25. 今日はどんなおはなしをするか 4 AWS について 4 ぼくはアプリケーションエンジニア 4 なので、お仕事でやったことがあることメイン ! 4 AWS は基本会社でしか触っていない(貧者) ! ! 4 ので、「弊社と AWS」的なお話しになります ! ! !
  26. 26. AWS
  27. 27. 基本情報 4 Amazon Web Services 4 アカウント登録して Go!
  28. 28. 基本情報 4 Amazon Web Services 4 アカウント登録して Go!
  29. 29. 基本情報 4 Amazon Web Services 4 アカウント登録して Go! 4 一番小さいサーバインスタンス 1年間相当が無料
  30. 30. 基本情報 4 11リージョン
  31. 31. 基本情報 4 11リージョン 4 特定のリージョンでしか使えないサービスも 4 リージョン毎に Availability Zone 4 物理的に異なるデータセンター
  32. 32. 基本情報 4 AWS のアカウント ≒ GCP のプロジェクト 4 ひとつの AWS アカウント内で複数プロジェクトを回す のはつらそう 4 プロダクト毎に AWS アカウントを作成
  33. 33. 弊社と AWS
  34. 34. 弊社と AWS 4 弊社での利用開始は2009年1月 4 当時ローンチしたサービス「えもにゅ」のため
  35. 35. 弊社と AWS 4 ローンチまでにサーバ買って、ラックに設置して... 4 遅い 4 将来的な負荷増大もある程度見込んだ性能を... 4 高い 4 クラウド利用のメリット > 従来までの手法のメリット 4 クラウド ≒ AWS 、だった当時
  36. 36. 弊社と AWS 4 3年後、別プロダクトで本格利用 4 DBサービスやロードバランサ等、サービスが出 ってきた
  37. 37. それ以降、数々の要求に AWS は応え続けて来てくれた
  38. 38. 求められていたこと①
  39. 39. 求められていたこと① 4 プロダクトを稼働させるサーバー 4 従来までのスタイル故の "つらみ" からの脱却 4 迫り来る保証期限 4 not disposable 4 配線やラッキングなどの職人芸 4 選ばれし者のみ触れられる聖域 4 プライベートネットワークが構成できること
  40. 40. EC2
  41. 41. EC2 4 Amazon Elastic Compute Cloud 4 仮想サーバ 4 GCP でいうと Google Compute Engine 4 従量課金、課金単位時間は 1h 4 reserved / spot instance 4 弊社サービスは基本 EC2 上で
  42. 42. EC2 4 AWS Marketplace でイメージ(AMI)を subscribe して 使う
  43. 43. EC2 4 AWS Marketplace でイメージ(AMI)を subscribe して 使う 4 "Market" だけど、無料のものもここに登録されている 4 自作のイメージを使うのにも Marketplace への登録が 必要
  44. 44. EC2 4 スペックよりどりみどり 4 汎用:t2, m3, ... 4 CPU特化:C3, C4, ... 4 メモリ特化:R3, ... 4 それぞれに small / medium / large ... 4 t2 シリーズには "バースト" が
  45. 45. EC2 4 ! が起動からセットアップをする場合 4 Webコンソールからポチポチ...でも立てられる、けど 4 gem aws-sdk & rake task で API 操作を自動化 4 起動・停止・ステータス取得... etc. $ rake ec2:create:product $ rake ec2:status:product
  46. 46. EC2 4 Chef-solo で構成管理 & インフラCI 4 CI からテスト用の EC2 インスタンスを立ててた時期も
  47. 47. EC2 4 ! が最初にサーバ構築するときは... $ knife solo bootstrap product $ rake spec:product
  48. 48. EC2 4 ! が構成を変更・追加するときには TDD で! (edit serverspec) $ rake spec:vm (spec failed & edit recipe & cook) $ rake spec:vm (spec ok!)
  49. 49. ちなみに
  50. 50. EC2(VPC) 4 何もせずに EC2 インスタンスを立てると、 default-VPC に属した状態になる 4 Amazon Virtual Private Cloud 4 仮想ネットワーク 4 ネットワーク内でサブネットや ACL の設定が可能 4 異なる AZ をまたいでの設定も可能
  51. 51. EC2 4 その他一般。 4 Security Group でアクセス制限
  52. 52. EC2 4 その他一般。 4 Elastic IPs で簡単にグローバル IP アドレス付与 4 1アカウントで設定できる IP の数には限りがある 4 ELB でロードバランス
  53. 53. 求められていたこと②
  54. 54. 求められていたこと② 4 立てたサーバからアクセスできる DB サーバが必要 4 従来までのスタイル(ry
  55. 55. RDS
  56. 56. RDS 4 Amazon Relational Database Service 4 GCP でいう Google Cloud SQL 4 Multi AZ は便利だなー 4 "Amazon RDS のマルチ AZ 配置では、異なるアベイラ ビリティーゾーンに同期スタンバイレプリカが自動的に プロビジョニングされて維持されます。" 4 Automatic Failover
  57. 57. RDS 4 Multi AZ は 1オプションで設定可能 4 mandatory maintenance にも
  58. 58. 求められていたこと③
  59. 59. 求められていたこと③ 4 巨大なファイルをカジュアルに置いておく場所が欲しい 4 空きディスクサイズにビクビクしたくない 4 http でアクセスできるようにして欲しい
  60. 60. S3
  61. 61. S3 4 Amazon Simple Storage Service 4 GCP でいう Google Cloud Storage 4 99.999999999 %の耐久性 4 99.99 %の可用性
  62. 62. S3 4 ただのファイル置き場...じゃない! 4 permission 4 logging 4 Cross-Region Replication 4 ...
  63. 63. S3 4 static resources hosting
  64. 64. 求められていたこと④
  65. 65. 求められていたこと④ 4 巨大なファイルを日次で解析してほしい 4 ファイルによって異なる解析をする必要がある 4 複雑な解析方法に対しても柔軟に対応してほしい 4 「そのためのサーバ」をまた別途構築しなきゃいけない... よね?(だから時間が掛かるよね?)
  66. 66. EMR
  67. 67. EMR 4 Amazon Elastic MapReduce 4 Hadoop(MapReduce) を手軽に扱うためのサービス 4 EC2 インスタンスを指定された数だけ起動 4 各インスタンスで bootstrap action 実行 4 EMR クラスタを構成 4 これらを自動でやってくれる
  68. 68. EMR 4 EMR クラスタ 4 マスター:全体の構成管理 4 コア:データを読み込みつつ データ処理 4 タスク:データ処理のためにリ ソースを提供(無くても良い)
  69. 69. Hadoop MapReduce ? 4 Map → Shuffle → Reduce 4 Map : データを分割 4 Shuffle : 分割されたデータを配分 4 Reduce : 配分されたデータに対して処理を実施 4 Hadoop を使うなら Map と Reduce のところだけ考えれ ば良い
  70. 70. Hadoop streaming 4 Mapper / Reducer だけ作れば良い 4 標準入力を受けられる・標準出力できさえすれば、どん な言語で書いても ok !
  71. 71. Hadoop streaming 4 Map : データ(標準入力)をもとに "key <tab> value" の 形式で標準出力すれば ok 4 Reduce : "key <tab> value" の形式で標準入力されるデー タに対して行いたい処理をし、その結果を標準出力すれば ok
  72. 72. 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
  73. 73. 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
  74. 74. How to use EMR 4 これで起動するだけで、 4 指定した数だけ EC2 インスタンスが立ち上がり 4 自動で Bootstrap(含 Hadoop)、クラスタ管理されて 4 Mapper / Reducer として指定したスクリプトも各イン スタンスに配置されて 4 指定した入力ファイルを mapper の標準入力に渡し 4 (つづく)
  75. 75. How to use EMR 4 (つづき) 4 Mapper の標準出力はそのまま Reducer の入力とな り、reduce 処理も行われる 4 Reducer の結果は output で指定した場所に出力 4 処理が全て終われば、インスタンスは全て自動で terminate される
  76. 76. EMR 4 「Mapper / Reducer をどう書くか?」だけに集中できる ような EMR 基盤の仕組みを用意 4 ...が、最近 Google BigQuery の production 利用が開始 4 EMR に取って変わるかも?
  77. 77. 求められていたこと⑤
  78. 78. 求められていたこと⑤ 4 自社のサービスを安定的に提供し続けていきたい 4 サーバに異常があったときはすぐに知りたい 4 サーバのスペック変更などが必要なタイミングを前もって 把握しておきたい 4 サーバの状態の推移・傾向を知りたい
  79. 79. Cloud Watch
  80. 80. Cloud Watch 4 監視&モニタリングを簡単に実現
  81. 81. Cloud Watch 4 監視設定可能な項目 4 CPU 使用率 4 ディスクの Read / Write 量 4 NW 通信量 4 ステータスチェック 4 CPU credit(t2) 4 課金額(Estimated Charge with CloudWatch)
  82. 82. Cloud Watch 4 これらについてのメトリクスも確認可能 4 ただし2週間分... cacti を併用
  83. 83. Cloud Watch 4 Cloud Watch でしか取れないものもある 4 RDS とか ELB などの AWS独自サービス 4 agent などのインストールができないので...
  84. 84. 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
  85. 85. 求められていたこと⑥
  86. 86. 求められていたこと⑥ 4 AWS のアカウントの使い回しはセキュリティポリシー的に やめたい 4 開発者毎にアカウント的なものを設定出来るようにして 欲しい 4 不慣れな人(たとえば新人さん)の誤操作で事故につな がらないようにして欲しい
  87. 87. IAM
  88. 88. IAM 4 AWS Identity and Access Management 4 ある AWS アカウントにアクセスするユーザー・グループを 管理 4 アクセス権をコントロール 4 無料
  89. 89. 求められていたこと⑦
  90. 90. 求められていたこと⑦ 4 知らないうちに、変なところから変な操作されたりしてな い? 4 意図してない AWS 操作は発生してない? 4 その証左をいつでも提出できる状態にして欲しい
  91. 91. Cloud Trail
  92. 92. Cloud Trail 4 アカウントの AWS API の呼び出しを記録 4 AWS マネジメントコンソール 4 AWS SDK 4 CLI(コマンドラインツール) 4 AWS CloudFormation など)を使用した API の呼び出 しも
  93. 93. Cloud Trail 4 Cloud Trail 記録用の s3 bucket を指定 4 API 呼び出し元の ID 4 source IP address 4 リクエストのパラメータ、レスポンス 4 これらが json で記録
  94. 94. その他、弊社で利用して いる AWS サービス
  95. 95. その他、弊社で利用している AWS サービス 4 「ドメイン設定して欲しい」 4 Route 53 4 DNS, failover とかも
  96. 96. その他、弊社で利用している AWS サービス 4 「CDN って手軽に用意できないかな?」 4 Cloud Front 4 「キャッシュ・セッションストアってさ...」 4 ElastiCache 4 これらは触ったことがないです... orz
  97. 97. 良い(と感じている) ところ
  98. 98. 良い(と感じている)ところ 4 使っている人が多い 4 サポートが手厚い(と感じている) 4 安くはないかもしれないが、GCP との価格競争に応戦でき ている 4 新しいサービスが次々と 4 (比較的)Ruby から扱いやすい 4 略称が(ほぼ)一意
  99. 99. いまいち(と感じている) ところ
  100. 100. いまいち(と感じている)ところ 4 単価が安くなっても、課金単位時間が 1h ェ... 4 後続の GCP に性能的に劣っているところが明らかになっ てきた? 4 常に危険に晒されている感 4 仮想通貨採掘に利用されたケースも...
  101. 101. 感想とか
  102. 102. 感想とか 4 「AWS をやってる」というよりは「IaaS をやってる」 (稼働環境を自分で作ってる)という気持ち 4 でもやっぱりロックインは多少されてる感 4 (お仕事で)EC2 の代わりに GCE を使う未来? 4 学習コスト・既存資産 < 導入メリット? 4 用途と目的により使い分けていくのかなぁとか
  103. 103. 感想とか 4 Web UI からポチポチやれば、サーバは簡単に立てられる 4 「そこでアプリケーションを安全に動作させる」というこ とを考えると... 4 AWS (IaaS)に精通していること < OS やミドルウ ェアを適切に使うこと 4 セキュリティ、ネットワークに関する知識も 4 AWS 独自オプションで楽できたり、とかはある
  104. 104. 感想とか 4 Chef が導入されたことなどにより、インフラエンジニア の「作業」が僕らにも "見える" ようになってきた 4 「サーバを立てて、そこでアプリケーションを安全に動 作させる」ことのプロが、インフラエンジニア(だと思 う) 4 今後もしばらくは "プロ" と相談しながらじゃないとキ ツそう
  105. 105. 感想とか 4 Chef が導入されたことなどにより、インフラエンジニア の「作業」が僕らにも "見える" ようになってきた 4 動作確認とか技術検証とかはインフラエンジニアを介さ なくても可能になってきているのは !
  106. 106. 感想とか 4 PaaS での開発から IaaS での開発へ 4 新鮮、勉強になってる(知らないことだらけ) 4 「奥の手」を使ってなんでもできる感じ(?)
  107. 107. 感想とか 4 PaaS での開発から IaaS での開発へ 4 PaaS がいくら便利でも、やりたいことが出来なかった ら使えない 4 僕らにはどうにもできないハードルがあったりする 4 「すみません、(技術的に)できません...」が、一番 悔しい
  108. 108. 感想とか 4 PaaS での開発から IaaS での開発へ 4 ミドルウェアに問題があった場合、解決までのプロセス は第三者に委ねるしかない 4 「いつ復旧するの?」...orz 4 「今度同じような障害があっても、次はもっと早く復 旧できるよね!」...orz
  109. 109. 感想とか 4 PaaS での開発から IaaS での開発へ 4 PaaS のアプリケーション開発に集中できることの メリットは大きい 4 最終的には GAE + MVMs みたいなところに繋げたい
  110. 110. まとめ(的なもの)
  111. 111. まとめ(的なもの) 4 弊社・フィードフォースと AWS と私についてのお話 4 求められるものに対して、AWS は応えてくれてきた 4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud Trail 4 良いと思っている点、いまいちだなと思っている点 4 個人的な感想
  112. 112. まとめ(的なもの) 4 弊社・フィードフォースと AWS と私についてのお話 4 求められるものに対して、AWS は応えてくれてきた 4 EC2 / RDS / S3 / EMR / Cloud Watch / IAM / Cloud Trail 4 良いと思っている点、いまいちだなと思っている点 4 個人的な感想 4 I Love GAE!!!

×