Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,291 views

Published on

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

Published in: Technology
  • 当日頂いたご質問のうち、回答できなかったものについて、こちら https://gist.github.com/a-know/a44f3da1b39a96f4a53a にて回答致しております。合わせてご確認頂ければと思います。m(_ _)m
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

フィードフォースと 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!!!

×