Eight meets AWS
•
15 likes•6,761 views
2013.03.16 JAWS DAYS 2013 Day2のTrackC 17:00からのセッションで発表したときの資料です。
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Eight meets AWS
Similar to Eight meets AWS (20)
More from Tetsuya Mase
Eight meets AWS
- 1. Meets Sansan株式会社 間瀬 哲也
- 2. Profile ■ 間瀬 哲也 (MASE Tetsuya) ● 略歴: 開発 → 運用 → 運用+インフラ ● Sansan株式会社 • リンクナレッジ事業部所属 インフラ担当 • Eight(別事業部)はインフラ助っ人 ● AWS歴：1年ちょっと ● 好きなAWSサービス：S3 ● Twitter: @matetsu • ひとりごと ● Facebook: tetsuya.mase • メシログ
- 3. Outline ■ Sansan株式会社について ■ EightとAWS ● AWS以前のEight ● AWSへの移行 ● 運用 ● 課題 ■ まとめ ■ 最後に AWS初級～中級くらいの方を想定した内容となっています。
- 4. Sansan株式会社 ■ 名刺管理 ● ビジネス向け: リンクナレッジ ● コンシューマ向け: Eight ■ 2007年6月設立 (6期目) ■ 最近社名表記やロゴを変更
- 5. リンクナレッジ ■ 「営業を強くする名刺管理」 ■ 6年 800社以上 ■ AWSではなくオンプレミス
- 7. Eight 正確にデータ化 オペレーターが手作業で
- 8. Eight 人脈を維持&管理 自動でつながる SNS連携
- 10. AWS以前のEight ■ 別のプライベートクラウドサービス ● 限定公開のPrivate β版を提供 ● 当時のサービス規模としては安定 書類申請ベース 作業完了まで数営業日 ※利用当時の情報です 「今」必要なものが、 「今」手に入らない
- 11. クラウドサービスの再検討 重要視した点 実績 ・他のユーザ サポート ・評価 スピード ・事業スピードを ・手厚さ 落とさない ・迅速さ ・事業者自身 自由度 可用性 ・好きなときに ・高可用な 好きなように セキュリティ システム構成 ・自システムの構成 ・サービス自体
- 12. 悩みに悩んだ 国産のとか 今使ってるサー ビスの別ライン ナップは？ 自分たちのサービスは AWSは？ 自分たちで責任をもって 運用するしかないでしょ！ 海外のRuby PaaSは？ インフラできる人 今からオンプ いないけど、IaaS レ？ で大丈夫？
- 13. そして AWS
- 14. そうと決まればやりましょう！ 移行期間は？ 2ヶ月！ 誰か経験者は？ いません！ じゃあ、設計と 勉強会で探してき かどうするの？ ます！
- 15. あれ？
- 16. まずは何をした？ 詳しい人を味方につける サーバーワークスさんに コンサルを依頼 導入部分やネットワーク設計のベース EC2以外のサービスの使い方 教わる→やってみる→質問する→やる
- 17. 次に 触ってみる まずは手を動かす！ つまづいたら調べる 困ったら #jawsug で聞いてみる 壊れたらまた作ればいい
- 18. そして 設計通りに作りこむ 時間がないんじゃー！ VPCのセキュリティ設定 インスタンス構築の自動化 バックアップ設定 など
- 19. 移行(利用)におけるポイント 構成 自動化 セキュリティ 期間
- 20. ポイント(1): 構成 お作法に従う ■ 基本はMulti-AZ ■ EC2は最小限 ■ 自前で作るより使える サービス ● S3, RDS, Route53, SES, SQS など ● 仕様（癖？）は知って おく必要あり
- 21. ポイント(2): 自動化 (1)サーバセットアップ ■ ベースはAMIで ■ 変動する可能性のある 部分はサーバ構成管理 ツールのChefで ■ web, batch などの roleを割当てて機能ご とに異なる設定を適用
- 22. ポイント(2): 自動化 role[web] Web Role Server Role web Role web Role web web role[batch] cook cook Batch cook book cook Server book book ベースAMI book Image role[image] Server ※cookbook: 自動構築の手順をまとめたもの
- 23. ポイント(2): 自動化 (2)アプリケーションデプロイ ■ コマンド一発デプロイ ■ 複数ノードまとめて ■ Chefのroleと連携 ● Chefのroleに紐付く EC2インスタンスリス トを取得してデプロイ
- 24. ポイント(2): 自動化 $cap production_web deploy Role web Web Server web001 web001 web001 web001 capistrano Web Server repository Batch Server
- 25. ポイント(3): セキュリティ 細かく制限 ■ VPC ● Public/Private Subnet ● Network ACL ● Security Group • InもOutも制限 ● Management Consoleで の設定はつらい！ SDKを活用すると楽できる
- 26. VPCのセキュリティ設定投入
- 27. VPCのセキュリティ設定投入
- 28. ポイント(4): 期間 2ヶ月！ ■ 実質作業期間3週間 ● アプリケーション改修 ● デザイン変更 ● インフラ移行 ● 結合テスト やればできる
- 29. AWSにして助かったこと S3 RDS ELB Route53 SES
- 30. S3 (Simple Storage Service) 運用の手間いらず ■ 名刺画像、ログ、バック アップ用ストレージ ● 簡単に利用できる ● 名刺画像が大量になって もAmazonさんがよしなに ● 99.999999999%の耐久性 これを自前で作るのは難しい
- 31. RDS (Relational Database Service) リリース1ヶ月前にVPCで利用可能に ■ MySQLを利用 ● Multi-AZで可用性アップ • 料金もUP ● 自動バックアップと自前 バックアップ • データの消失怖い 運も味方につけた！？
- 32. ELB (Elastic Load Balancing) 気軽に高可用 ■ Webサーバのフロントに は必ず設置 ● 必ずMulti-AZ ● Internal ELBも活用 • 2012年6月から オンプレミスはこの気軽さはない
- 33. Route53 手軽なDNSサーバ ■ 簡単に管理 ■ 世界中にendpoint ■ ELBやS3との連携 ■ SLA100% 面倒な脆弱性対応も必要ない
- 34. SES (Simple Email Service) 面倒なメールサーバも楽々 ■ メール配信 ● ユーザ向けメール ● システムメール ● 大量配信もよしなに ● ちゃんと運用してれば、 制限解除もスムーズに 大量配信は素人が迂闊に手を出しちゃいかん！
- 36. トレたま効果 コマンド一つでスケールアウト ■ 時間帯の予測が可能 ■ Knifeコマンドの定型化 ● Chefを操作するコマンド ● AutoScaleや CloudFormationは使っ ていないんですよね 通常運用時の10倍アクセスも難なく対応
- 37. 新機能などの設定追加も楽々 Chefにおまかせ ■ まとめて適用 ■ 事前にしっかりテスト ● 検証用のStaging環境 ● Environmentを利用 ■ 開発チームと情報連携 ■ 今ならOpsWorks？ 新機能もスピーディに提供
- 38. 監視は慣れたツールで 運用の肝 ■ Nagios+CloudWatch ■ CloudForecast + CloudWatch ■ 監視にもfluentdも活用 したい ● ログ集約では使ってる APIを使って簡単にカスタマイズ
- 39. 節約も忘れずに Time Is Money ■ ReservedInstance ■ CloudWatchで料金監視 ■ 開発環境は節約徹底 ● 使わないときは停止 ● 使わないEIPはリリース ● 不要なEBSがないか 無駄はダメ
- 40. 見やすさ大事 設定Viewer ■ VPCの設定Viewer ● 特にNetwork ACLと Security Groups • Inとoutを並べて ● Route Table • RoutesとAssociationsを 同時に Management Consoleが見やすければ。。
- 41. 設定Viewer(1)
- 42. 設定Viewer(2)
- 43. つい先週リリース SWF(ワークフロー)を使ったシステム ■ 名刺データ入力システム ● 入力の各工程を小さな サービスに分割 ● 疎結合な仕組みを実現 ● 優先度設定で苦労 • SWFでは未実装 ＃ヤマンさん、色々とご対応ありがとうございます！
- 44. SWFの利用イメージ(1) 入力工程 A→B→C→D→E→F A B C D E F 各工程(の処理)を小さく分割して実装 A B C D E F Service Service Service Service Service Service Worker Worker Worker Worker Worker Worker
- 45. SWFの利用イメージ(2) 名刺の取込 Decider ワークフローを (ワークフローの管理、 開始 処理のルーティング) Startar Get Return SWF domain Workflow Workflow Executions (‘この’名刺のデータ化) Activity A ・・・ Activity E Activity F Get Worker (タスクを ・・・・・・ 処理) Return Operators
- 46. SWFの利用イメージ(3) 名刺の取込 Decider 場合によっては、不要な処理をスキップ Startar Get Return SWF domain Workflow Workflow Executions (‘この’名刺のデータ化) Activity A ・・・ Activity E Activity F Get Worker ・・・・・・ Return Operators
- 47. 事業の未来を担うシステム (となるか？) 拡張性 安さ 正確性 早さ
- 48. 課題 ■ リリース時からインフラにあまり手を入 れられていない パフォーマンスの改善 とくにMySQLまわり ログの活用 EMRで解析、監視など さらなる自動化 人の手は極力排除、新たな一手を
- 49. まとめ AWSをフル活用 ■ 便利でスケーラブルなサービスが多い ● 活用して運用コストをダウン ■ 自分たちの事業に本当に必要なところに 注力する
- 51. おまけ 来たれ！ ■ Eight / Sansan株式会社ではエンジニア を募集しています。 ● 特にインフラ / オペレーションエンジニア の方！ ● Rubyエンジニアも！
- 52. 10万人が使う名刺管理アプリ