システム変更にアジリティを求めたい
ハードウェアの場合、見通しの難しい予測をしながらスプレッドシートで必要な機器の概算金額を積み上げ、ようやく社内稟議を通して待ち受けているのはサーバなどの調達だ。ラックやスイッチ、無停電電源装置（UPS）の空きも現地調達しなければならない。何度も見積りを取り直した後、さらに購買部の価格交渉が待っている。
発注するまで2週間、その後、納入されるまでさらに2週間から1カ月。良くも悪くも納入されてから構築に入るまで、1～2カ月の期間があることが多い。もちろん期間があるといっても、サーバ以外のファシリティにまで調達が及ぶ場合は、その設計に相応の時間をとられることもある。サーバ周りの設計やレビューでこの期間はあっという間に過ぎていく。従来のオンプレミスのやり方は概ねこのような流れだろう。
では、これがAWSならどうだろうか。利用するリソースごとに料金表が決まっており、「SIMPLE MONTHLY CALCULATOR」を利用すれば、30分程度で金額を算定できる。ご存知のとおり調達期間は皆無といっても過言ではない。実際、数クリックで環境が立ち上げる。
しかし、サーバ周りの設計やレビューという行為自体はなくならないので、それにかかる期間は、これまでのように調達期間と並行にはならず、プロジェクトのスケジュールにそのままのしかかる。この期間をいかに短縮化し、品質を確保しながら速やかに環境を準備するか、プロセスの転換が必要になるだろう。
サーバ投資を抑えてコストを削減
クラウドでは、平時に合わせてリソースを用意し、ピーク時にシステムを拡張すればよい。クラウドだから、いつでも必要なだけ拡張できるので、これまで悩まされていたリソース不足から開放される、夢のような話だ。
しかしながら、この夢のような話を実現するためには、柔軟に拡張、縮小できる環境や、運用の作り込みが必要だ。
フロントエンドのウェブサーバであれば、台数を増減して負荷に対応するケースが多いが、単にサーバイメージをコピーして台数を増やすだけでは済まないことも少なくない。増設したウェブサーバに最新のコンテンツを配信するための仕組みや、ログを保全する仕組みも必要になる。
バックエンドのデータベースサーバであれば、リードレプリカ機能を利用し、参照系のトランザクションをリードレプリカサーバに逃して、負荷をさばくことがセオリーだ（MemcachedやRedisのような分散型キャッシュシステムを利用する手もある）。一方、フロントエンドのサーバから複数台のリードレプリカサーバへのトランザクションを、なるべく均等になるように分散させるための仕組みも必要になる。
なお、これらの作業を必要な時に手動で実施するのはなるべく避けたい。人的ミスが発生しやすく、発生した際の影響が大きくなるからだ。こういった作業は自動化しておこう。
また、想定できるピークにはあらかじめ検討し、対策の準備をしておきたい。企画、コンテンツ、インフラのそれぞれを担う担当が違う場合、システムという側面では横の連携が弱く、ピーク時の対策が後手に回ることが少なくない。リソースを適正化してコストを削減するならば、各ファンクションの横の連携を強くすることをおすすめする。
