[レポート]ビジネス変革を実現するクラウドジャーニー～DevOps と Microservices～ #AWSSummit

AWS Summit Tokyo 2016

#レポート

#AWS

丹内優紀

2016.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

丹内です。タイトルのセッションに出たのでレポートします。

クラウドジャーニー

ジャーニー = 旅路。クラウド適用の旅である
Stage of Adoption: 多くの会社でのクラウド移行のベストプラクティス
1. 個別プロジェクト
2. ハイブリット化
3. 大規模移行
4. クラウド最適化
AWSユーザが行うべきアクションと、AWSに要請するアクション(DX導入、サポート導入など)がある。

amazon.comのクラウドジャーニー

書籍の販売から始まり、kindleやメディア、AWSなどのイノベーションを起こし続けている
最初はモノリシック。ある程度はパイプラインで自動化されている
- 密結合なので、メンテナンスと維持が難しい。マージフライデーと呼ばれるほど。
- ビルドやテストに時間がかかり、デプロイがボトルネックになる
- サービスに問題が生じるとサイトが止まってしまう
これらの問題を解決するために、サービスを分割した
マイクロサービスと取り入れる
- マーチン・ファウラーが提唱
- ビジネス能力にもとづきアプリケーションを分割する
Two Pizza Teamsを取り入れる
- サービスチームと呼ぶ
- you build it, you run it
- サービスごとにデリバリパイプラインを所有する
amazon以外でも、NetflixやNike、Capital Oneなどがre:Inventで発表している

原則とプラクティス

(セッション中の)DevOpsの定義
- build -> test -> releaseしてから monitor -> planのフィードバック・ループを高速化する効率の良さ　とする
ビジネスにITをアラインさせるにはフィードバックが必要
- 顧客が必要な物がわかっていないことが多い
- 例えば、昔は早く走る馬が欲しかったので馬術が発達したが、本当は早く移動できる自動車があればよかった
- 実験のサイクルを早く、安く実行できる必要がある
Lean Startup
- 新規事業立ち上げのフレームワーク
- アメリカの起業家やGEでプロセス化されている
- 従量課金と調達性の良さで、クラウドはLean Startupと相性が良い
Culture
- 組織間の壁を取り払う必要がある
- 余裕件と説明責任を、個人ではなくチームに移譲する
- 小さなチームを維持する
- 常に改善を続け、手段(How)には柔軟性を残す
Amazon Our Leadership Principalsという、全社員が作り見直し実行する行動規範あり、公開されているが、そのなかからDevOps向けをピックアップ
- Customer Obsession: 顧客中心
- Owner Ship: 自分の仕事として動く
- Bais for Action: 必要以上に考えこむよりも、計算されたリスクを飲み込んで行動し学習する
Practice
- CI/CD
- Infrastructure as Code
- カナリアリリース、Blue-Green/Red-Blackデプロイ
- マイクロサービス
- 運用タスクを自動化してシンプルに
Tool
- コード管理やパイプライン
- 構成管理
- モニタリング
- 開発者間のナレッジ共有
- セキュリティ分析
マイクロサービスのためのkey
- Elastic: サービスごとに独立したスケールアウト・イン
- Resilient: サービスごとに独立した障害時の境界線
- Composable: サービスごとに均一なAPI
- Minimal: 小さなサービス
- Complete: サービスとして完結
マイクロサービスのコンポーネント
- Client
- Gateway: APIGW
- Discovery: ELB
- ビジネスドメイン: Lambda, EB, ECS
- データストア: DDB, RDS
- バージョン管理: CodeCommit
- 成果物リポジトリ: S3
- パイプライン: CodePipeline
AWS Professional Service
- AWSのアーキテクトがクラウドジャーニーをサポートするサービス
- トレーニングを提供