こんにちは、さくらインターネットの大喜多です。

クラウドの出現により、これまでのインフラ設計と異なった視点が必要となります。今回はクラウドの特性を生かした設計のコツをご紹介します。

第1回 クラウドインフラのしくみ
第2回 クラウドを支える仮想化
第3回 Linuxコマンドを用いたボトルネック調査
第4回 インターネットを支える技術
第5回 ITインフラ監視入門~Zabbixインストール編~
第6回 ITインフラ監視入門~Zabbix活用編~
第7回 いまどきのインフラ設計のキモ
第8回 Design for FailureなWebシステムの構築

サービスを利用するか自前で構築するか

システム構築に際して、サービスを利用するか自前で構築するか、それぞれのメリット・デメリットを正しく理解して選択できるようになる必要があります。オンプレミスとクラウドを比較してクラウドを利用するのも、そのメリット・デメリットを理解してサービスを選択していることになりますし、クラウドの中でも仮想サーバーとアプリケーションサービスがそれぞれ用意されていて、これもまたメリット・デメリットを理解して選択していくことになります。

さくらインターネットが提供する「さくらのクラウド」では、伸縮性のある仮想サーバー、仮想ネットワークといった基本的価値をしっかりと提供しながら、アプライアンスやグローバルリソースと呼ばれるサービスも次々と拡充されています。仮想サーバーに自ら構築して運用すべきシステムと、すでに存在しているクラウドサービスを組み合わせて利用することで、アーキテクチャの最適化をはかっていくことができます。クラウドチーム 大井による、アプライアンス/グローバルリソースの連載もはじまりましたので、そちらも併せてご参照いただき、ご活用ください。

机上で考えているよりとにかく手を動かすこと

クラウドでは、瞬時にコンピューティングリソースを必要な分だけ調達し、いつでも減らしたりやめたりすることができます。この伸縮性を持っているインフラであるという特徴が、今までのオンプレミスにない点です。オンプレミスなシステムでは、利用ユーザー数・想定トラフィック・利用アプリケーションなどから慎重にサイジングを行う必要がありましたが、クラウドでは後から大きくしたり小さくしたりすることが容易にできますので、プロトタイプの段階で本番環境と同じインフラを使って実験してみるのがよいでしょう(そしてそのまま本番に移行することももちろん可能です)。

小さくはじめて大きく育てる

瞬時にコンピューティングリソースを必要な分だけ調達し、いつでも減らしたりやめたりすることができる伸縮性を持ったクラウドは、「小さくはじめて大きく育てる」「ビジネスにおいて仮説→検証→修正のプロセスを回す」ことに適しています。従来はサーバー・ネットワーク機器等の購入費用や保守費用やラック費用など初期投資に多額の費用がかかり、実験的な取り組みが難しいなどの障壁がありましたが、クラウドはITコストを固定費から変動費に変えました。大きな初期投資を必要とせず簡単にはじめて簡単にやめることができるため、サービスの成長とともに規模も大きくしていければいいですし、うまくいかなければサービスを終了してその経験を次のチャレンジに生かすことも容易になりました。

故障のための設計(Design For Failure)

クラウドでは故障を見越したインフラ設計が容易にできるようになっています。複数のデータセンターにサーバーを用意し、データセンターを跨がるトラフィックをロードバランサーによって分散し、SPOF(single point of failure、単一障害点)のないITインフラを構築するためのパーツが揃っています。


故障を見越したインフラ設計の例

最初だけでなく継続的な改善

システムが完成し本番運用に入ったあとも、アーキテクチャの見直しの必要は往々にして訪れます。クラウドであれば、サーバーのスペック、ストレージのサイズ、ネットワーク構成などをいつでも変更することができます。例えばシステム構築時点には存在しなかった新サービスがリリースされても、容易に乗り換えることができます。

まとめ

ITインフラを所有から利用へ大きく変えたクラウドは、インフラエンジニアやアプリケーションエンジニアに求められるスキルも大きく変えることになりました。次回以降は「故障のための設計(Design For Failure)」を実現する具体的な手法を解説してまいります。