re:Invent AWSはどのようにソフトウェアを開発しているのでしょうか？ラスベガスで開催中のre:Inventカンファレンスで行われた、控えめながらも示唆に富むセッションによると、AWSは小規模なチームでソフトウェアを開発しているそうです。
「Amazon の DevOps 文化」と題して、教育部門の主任テクノロジストである Leo Zhadanovsky 氏と、AI および ML のカスタマーサクセス リードである Alyssa Lee 氏が、同社が「最新のアプリケーション」の構築、テスト、展開、保守に関してベストプラクティスと考えていることを説明しました。
聞いたところによると、私たちのショッピングカートはかつて4万行のPerlスクリプトだったそうです
「アマゾンは規模が大きいので、あなたのビジネスには当てはまらない部分があるのは明らかです。決して、これがあなたのやり方だと言っているのではなく、それが私たちのやり方だというだけです」とリー氏は語った。
モダンアプリケーションとは何か？ザダノフスキー氏は、AWS導入以前のAmazon.comのeコマースサイトについて説明した。「90年代後半はモノリシックなアプリケーションで、それを支えるチームはモノリシックでした。聞いた話では、ショッピングカートは4万行に及ぶPerlスクリプトだったそうです」。ザダノフスキー氏によると、ソフトウェア開発者はグレッグという人物で、そのスクリプトはGregPOS.cgi（Greg Point of Saleの頭文字）と呼ばれていたという。「その後、グレッグが退社し、別の人物がその4万行に及ぶPerlスクリプトを保守するようになり、POSの意味が変わってしまったのです」。
「私たちが学んだのは、脆弱性を分解し、モノリシックなサービスをマイクロサービスに分解し、それらの小さなサービスをサポートするためにチームのサイズを調整することです。」
自動化も鍵となる。「真にスケールするには、すべてを自動化する必要があります。これにはインフラストラクチャも含まれます」と彼は述べ、インフラストラクチャをコードとして定義することの重要性に言及した。インフラストラクチャをコードとして維持するには規律が必要だ。緊急の変更が手動で行われ、デプロイメントが定義と一致しなくなると、「スタックを更新するとすべてが壊れてしまう可能性があるため、不安になります」とザダノフスキー氏は述べた。「そのような状況は避けたいのです。」
リー氏とザダノフスキー氏によると、チームは通常6人から15人で構成され、「2枚のピザチーム」とも呼ばれ、使用するプログラミング言語など、かなりの裁量権が与えられているという。「しかし、継続的インテグレーション、継続的デリバリー、バージョン管理には標準ツールを導入しています。なぜなら、それらのために異なるツールを使うことにあまり意味がないことがわかったからです」とザダノフスキー氏は付け加えた。
また、一般的なアプリケーションタイプ用のテンプレートのライブラリもあるため、「開発者はゼロから開発するのではなく、その[ベストプラクティス]から反復することができます」と同氏は述べた。
Amazonはどのようにしてアプリケーションをマイクロサービスに分割したのだろうか？「機能ではなく、スケーリング係数に基づいて分割することにしました」とZhadanovsky氏は述べた。スケーリング係数とは、ストレージ使用量、ネットワークスループット、CPU需要といった指標のことだ。あるサービスがボトルネックになった場合、簡単にスケールアップできるというのがその理由だ。
「たとえ社内サービスを構築する場合でも、それをどのようにスケールアウトするかを考える必要があります」とザダノフスキー氏は述べた。「社内で広く採用される可能性もあれば、外部サービスになる可能性もあります。現在公開されているサービスの多くは、かつては社内サービスでした。」
各サービスは独立して動作する必要があります。「ジェフ・ベゾスが送ったメールには、この日までにすべてのサービスはAPIを介して相互に通信しなければならないと書かれていました」とザダノフスキー氏は言います。あるサービスが別のサービスのデータを必要とする場合、「そのデータに対してクエリを実行することはできません。これは制御不能です。あらゆる可用性の問題やセキュリティ上の問題が発生する可能性があります。私がしなければならないのは、そのサービスのAPIと通信することです。」
APIは契約であり、パフォーマンスのしきい値内で動作する必要があると彼は述べた。「しきい値を超えている場合は、アラームがトリガーされます。」
これは、ターゲットサービスがデータベースを別のものに交換したり、別のキューイングシステムを使用したりできることを意味します。「API経由で通信しているだけなので、問題ありません。」
リー氏はチームの編成方法について説明した。その目的は、責任が重複しすぎることで生じる意思決定の麻痺を回避することだと彼女は述べた。「Amazonでは、いわゆる『シングルスレッドオーナー』と呼ばれるチームを作ることで、この問題を解消しています。各チームには各分野の専門家が1人ずついます。」つまり、「ある分野で問題が発生した場合、誰に相談すればよいかが明確に分かるのです。」
チームはAWS内部で構築されたすべてのものを所有します
アマゾンはリーダーシップ原則を公開しており、「私たちはそのリーダーシップ原則に従って生きています」とリー氏は主張した。
1人の担当者は1つのチームにしか割り当てられませんが、「当社には、特定の分野に情熱を持つ人たちの小さな社内コミュニティがあります。セキュリティの面でサポートが必要なのに、セキュリティ担当者が対応できない場合は、Slackなどでメッセージを送信すると、チーム外の誰かが駆けつけ、サポートしてくれます」とリー氏は言います。
サービス間の依存関係はどうなっているのでしょうか？ APIが変更されたらどうなるのでしょうか？「設計上、APIに互換性を破る変更は行いません」とザダノフスキー氏は言います。「追加するだけです。」これは、パブリックサービスの扱い方と似ています。「APIを非推奨にした回数は、おそらく片手で数えられるほどです」と彼は言います。
- AWS が HPC 向けに調整された自社製 Graviton CPU と、更新された Nitro システムに合わせて調整されたネットワーク スタックを導入
- AWSはウォーター・ポジティブ・ギャングに加わり、2030年までに実現すると主張
- AWS、AppSyncの「Confused Deputy」脆弱性を修正
- アマゾンはインドで2番目のAWSリージョンを追加し、44億ドルを投資する
製品やサービスが大きくなり複雑化すると、小規模チームはどうなるのでしょうか？「機能を追加していくにつれて、チームが大きくなりすぎるのは避けたいものです」とザダノフスキー氏は言います。「そこで、チームを細分化していくのです。」
例えばS3（Simple Storage Service）は、数十年前に登場して以来、膨大な数の機能を追加してきました。「S3の様々な機能を見てみると、おそらく主要な機能カテゴリー全てにおいて、2枚のピザで構成されたチームが存在するでしょう。」
各チームの自主性を考慮しつつ、サービスの品質、セキュリティ、一貫性はどのように維持されているのでしょうか？ サービスや機能のリリース前には、レビュープロセスを経る必要があると参加者に説明されました。「当社には、経験豊富なソフトウェアエンジニアの小さなコミュニティであるプリンシパルエンジニアがいます。彼らの仕事は、他のチームに助言し、ベストプラクティスを広めることです」とザダノフスキー氏は述べています。「彼らは、計画段階とリリース前にアーキテクチャレビューを行い、ベストプラクティスに準拠していることを確認しています。」
「当社ではアプリの [セキュリティ] レビューを義務付けています。サービスに問題が見つかった場合、問題が修正されるまでアプリはリリースされません。」
オペレーションレビュー（OR）もあります。「これは、これまで発生した問題に基づいて進化していきます。過去の問題から学んだことを整理し、次回同じ問題を回避できるようにORを開発しています。」
Javaで問題がある場合は、James Goslingに問い合わせることができます
プリンシパルエンジニアも専門的な問題に対応しており、中には著名人も含まれます。「Javaの生みの親であるジェームズ・ゴスリングがいます。彼はプリンシパルより一つ上のレベルのディスティングイッシュドエンジニアです。Javaに関する質問があれば、彼に相談してください。」
毎週のチーム間運用レビューでは、前週の運用上の問題を詳しく調査し、大きな問題がない場合は、ランダムに選んだチームのサービスのログを分析して、改善できる点を確認します。
リー氏とザダノフスキー氏は、AWSではサーバーレスへの偏りがあると述べた。「OSの管理はしたくないでしょう」とザダノフスキー氏は述べた。継続的デプロイメントが目標だ。「2019年には、社内で6000万回のデプロイメントを実施しました。デプロイメントとは、コード行の変更を指すこともあります。」デプロイメントは失敗する可能性があり、それは理解している。「私たちは意図的にデプロイメントをスローロールしています」とザダノフスキー氏は述べた。初期テストのための「カナリア」デプロイメントがあり、その後、あるリージョン、そして別のリージョンへとデプロイしていく。「いつでも停止してロールバックできます」とザダノフスキー氏は述べた。
もう一つの目標は、ザダノフスキー氏が「エッグシェルセキュリティ」と呼ぶものを避けることです。「多くのお客様を見てきましたが、エッグシェルレベルのセキュリティ、つまり外側は堅固で内側は柔らかいセキュリティを採用している企業があります。ファイアウォールを突破できれば、どこにでも移動できます。私たちはそのようなセキュリティを望んでいません。モダンなアプリケーションとは、あらゆる層にセキュリティが組み込まれ、すべてのマイクロサービスが独自のセキュリティを管理することを意味します。VPNのようなものはもう必要ありません。ゼロトラストなのです。」
これらはAmazonで実践されている原則であり、モノリシックなアプローチが復活しつつあるこの時代に、同社がマイクロサービスの重要性を力強く訴えているのは新鮮でした。しかし、このクラウド大手には、自社サービスへの社内アクセスが可能で、すべての機能に月額料金が加算されることがないなど、一定の利点もあります。そして、JavaクエリにはGoslingが対応しています。®
