[レポート] Amazon の開発プロセス – How Services Are Created at AWS #awssummit

2019.02.26

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

こんにちは、菊池です。

本日は、ドイツ・ベルリンで開催中のAWS Summit Berlin 2019に参加しています。

本記事は、朝一番に開催されたセッション、「The Software Development Process at Amazon - How Services Are Created at AWS」のレポートです。

セッション概要

AWS is today recognized as one of the pioneers of DevOps, agile development, automation, continuous deployment, and automation in general. But we did not always develop software this way. This session will explore our journey from monolith to a service-oriented architecture and 2-pizza teams. You will learn why we adopted certain practices and how we develop software inside Amazon.

スピーカーは、Jonathan Weiss, Sr. Manager, Software Development, AWS です。

レポート

  • Amazon は数百の異なるビジネスを展開
  • re:Invent 2018の期間だけで、106の重要な新機能・サービスを公開
  • 少しもスピードを落とさない
  • ソフトウェア開発のライフサイクルは、デリバリーパイプラインとフィードバックループ

10の学び

  1. マイクロサービス
  2. DevOpsチーム
  3. セルフサービスツール
  4. 継続的デリバリー
  5. 悲観的なデプロイ
  6. 自動テスト
  7. 最適化されたECTループ
  8. 全てをモニタリング
  9. 全てを計測
  10. 顧客の声を聴く

マイクロサービス

15年前、モノリシックなアーキテクチャだった

現在ではマイクロサービス化

  • サービス指向アーキテクチャ
  • 1つのことをうまくやる
  • APIで接続
  • 高度に分離

チーム

  • 2ピッツァチーム
    • 高いアジリティ、自律的、オーナーシップを持ったチームを維持する

セルフサービスツール

  • 1つの技術にとらわれない
  • ベストプラクティスを奨励
  • 1つのことを上手にやる

継続的デリバリー

  • パイプラインの整備
    • リリースプロセスの自動化
    • より高速・信頼できるリリースの実施
  • 数1000のチーム x マイクロサービス x 継続的デリバリー x 複数環境 = 数百万のデプロイ

悲観的デプロイ・自動テスト

各環境でのテスト・リリースプロセス

最適化したECTループ

  • Edit - Complie - Test ループ
  • コードレビュー
  • ステージング
  • プロダクション

  • 開発ライフサイクルでの問題の発見
    • 早い段階で発見できる方がより理想的

全てをモニタリング・計測

あらゆるメトリクスをモニタリングするオペレーション文化

顧客の声を聴く

  • 声を聴くのは簡単なことである
    • 何がしたいか
    • リリースしたものへのフィードバック

まとめ

AWSの高速な新機能・新サービスの開発が、どのような文化によって実現されているかの紹介でした。