AWSでのサーバーレス開発

第8章 サーバーレスの運用 サーバーレスの演算子

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

革命は一度だけの出来事ではない。

オードレ・ロード

前の2章では、サーバーレス・アプリケーションの開発、テスト、デプロイの方法を探った。この章では、サーバーレスアプリケーションを本番環境で演算子する方法を学ぶ。サーバーレスの運用の基本は、非サーバーレスソフトウェアのそれと似ている。アプリケーションが期待通りに動作していることを確認し、パフォーマンスが低下したときにアラートを受け取り、インシデントから回復し、ログとトレースを使って問題をデバッグする。しかし、サーバーレスの主要な特性は、従来の演算子へのアプローチにいくつかの調整を必要とする。

おそらく、、演算子に関してサーバーレスの最も重要な側面はスケーラビリティだろう。サーバーレス・テクノロジーとマネージド・サービスは、コンピュート、ストレージ、通信をゼロから最も急増するピークまで自動的にスケーリングする。これは明らかに、季節的な販売イベントやプロモーションを行うECサイトのような、定期的に需要が急増するビジネスや製品を持つエンジニアリングチームにとって大きな利点だ。しかし、サーバーレス・エンジニアがスケールの単位を知り、スケールが従量課金に与える影響を理解することは極めて重要だ。AWS上にサーバーレスアプリケーションをデプロイする場合、クラウド契約を結ぶことになる。AWSはオートスケーリングと高可用性を提供するが、アーキテクチャを設計する際にはサービスの制限内で運用し、スケールについて十分な情報を得た上で判断しなければならない。基盤となるサービスがスケールしても、アプリケーションはスケールしない可能性がある。

第6章では、アプリケーションを初日から毎日本番環境にデプロイし、その振る舞いを即座に継続的に分析することの重要性について説明した。これには、ビジネスとユーザのニーズを満たすサーバレス製品を構築するための利点が十分に文書化されているが、サーバレススケールにアーキテクチャを最適化するためにも極めて重要である。アプリケーションがデプロイされると、可観測性の実践は、システムのパフォーマンスを理解するための最も貴重なツールとなる。

生産に代わるものはない

1999年、バルセロナで行われたチャンピオンズリーグ決勝で、マンチェスター・ユナイテッドがバイエルン・ミュンヘンを2-1で下した。衝撃と不信の中、彼はこう言った：「サッカーだ。血まみれの地獄だ」。

試合は90分フルに行われ、プレーの中断を考慮して3分が追加された。ユナイテッドは開始1分と3分にゴールを決め、優勝カップを手にした。サー・アレックスがショックを受けたのも無理はない。欧州サッカー連盟（UEFA）のレナート・ヨハンソン会長も後にこう語っている：「信じられない。勝者は泣き、敗者は踊っている。"

しかし、1999年の決勝戦は、試合当日のスタジアムの環境を再現することは不可能であり、重要な試合の結果を正確に予測できることはほとんどないことを示している。スタンドの何千人ものファン、天候、照明、芝生など、変数が多すぎるのだ。サッカーはどの試合も同じ規則と制約の中で行われるが、結果は常に異なり、推測することは難しい。

マンチェスター・ユナイテッドとバイエルン・ミュンヘンは、あの試合を100回やっても、毎回違った結果を出すことができただろう。どちらのチームも、この試合の勝因となった終盤の2ゴールを想定することも、予測することもできなかったのは確かだ。 ...