Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

15.1

 発展的なアーキテクチャ

301

数週間を実験に使い、新しいクラウドプラットフォームでその部分を実行し、ツールを選択

した。そして、その部分を本番稼働に移し、まだデータセンターで実行されているプラット

フォームのほかの部分とそれをインテグレートした。

この方法によって、私たちはサービスのニーズに合うように新しいクラウドプロバイダと付

き合う方法を学んだ。たとえば、スケールアップ

/

ダウンをトリガリングするための最良の指

標として、私たちはアプリケーションが報告してくる取引のペースを使っていた。しかし、テ

レビコマーシャルなどのためにトラフィックに突然のサージが起きると、新しいインスタンス

が作られるまでのタイムラグが長過ぎることがわかった。そして、キャパシティバッファ（

2

つ

の追加インスタンス）があれば、遅い自動スケーリングの反応でも追いつけることがわかった。

また、最初のオートメーションツールとアプローチには、チームとして満足していたが、も

とのインフラストラクチャ定義ツールは完全に廃棄して新しいものに変えた。また、自動ス

ケーリングプロセスを高速化するために、サーバー構成ツールも破棄し、イミュータブルサー

バーアプローチを取ることにした。

私たちは、こういったテクノロジやプラクティスに「最終的な」形があるという幻想を持

たなかった。チームがほかのサービスもクラウドにマイグレートするようになると、別のアプ

ローチを取らなければならないものもあることがわかった。たとえば、ある新しいサービス

で、私たちがインス ...