シンジです。クラウドクラウドAWSAWSゆーとりますけども、そもそもクラウドのインフラって何のことですか。AzureとかGCPとか固有のあれこれもあるけれど、特定のサービスに依存しないクラウドの本質を理解することで、オンプレとクラウドの違いだとか、クラウドに移行するときのポイントなど、クラウドをもっと知って、「クラウドよくわからない」を吹き飛ばしましょう。
プライベートクラウドとパブリッククラウドの違い
自動販売機の置き場所が違う
オフィス内にある自動販売機がプライベートクラウドで、街中にある自動販売機がパブリッククラウドです。
プライベートクラウドな自動販売機は、設置場所も場所代も電気代も利用者が負担しなければなりません。ただし、社内の自動販売機で売り上げを上げたいとは思いませんから、販売価格は安くなる傾向にあります。そして決定的なのは、社内の人間しか使えないと言うことです。
パブリッククラウドな自動販売機は、設置も場所代も電気代もクラウド提供者が負担しますが、ジュースの売り上げが欲しいので、適正価格で販売することが目的になります。そして決定的なのは、クラウド提供者が用意した自動販売機を、複数の人達が利用出来るということです。ただし、「マルチテナント」と言われる機能を使って、あたかも自分専用の自動販売機を利用しているように見せかけます。
コスト構造の違い
プライベートクラウドには、初期投資が必要です。パブリッククラウドには、初期投資がありません。必要なぶんを、その都度、必要なだけ用意したい、用意する総数が分からない、見積もりが難しい、そんな場合はパブリッククラウドの方が自由度が高くなります。
逆を言えば、オンプレ基幹系の移行など、ある程度のリソース活用が事前に見込めていて、かっちりハマりそうだなという場合は、プライベートクラウドのほうがコスト的に優位になるケースがあります。プライベートクラウドでは、一定のリソースを初期投資でドバッと用意するため、リソースを使い切るまでは、追加コストが発生しません。
パブリッククラウドの場合、リソース利用量の上下にコストも左右されるため、見積もりが難しくなるケースが多々あります。
クラウドの真のメリットとは
クラウドによる構築手順の標準化
さぁ、新たなサービスを始めよう！サーバーを調達しよう！そんなとき、物理的な機器をどこどこに発注して、どこどこが配線して、ラッキングして、、、これが当たり前でした。機器選定、1日で終わりますか？規模にもよるでしょうが、数千万円クラスのシステム発注の機器選定って、ベンダーとやりとりしたり、見積もり取ったりしますよね。で、3ヶ月くらい経過してたり。そしたら新型モデルのサーバー出てきたりなんて。
クラウドインフラにはこのような手順は一切必要ありません。
そして重要なのは、ネットワーク機器の標準化がされているということです。一度、クラウド上での仮想ネットワーク機器の使い方を覚えて、設計書や手順書を作ることで、自社が利用するクラウドサービスのインフラ全てに同じ手順を用いることが出来ます。クラウドサービス提供者は、物理機器の細かい違いを全部吸収して、標準化してくれます。
1度作ったシステムを、何度でも繰り返し作り直すことも出来ますから、過去の経験・ノウハウを最大限に活かしてシステム環境構築作業を効率化していくことが可能になります。
パブリッククラウドの場合は特に意識することもありませんが、プライベートの場合は、若干の意識が必要です。それはハードウェアのライフサイクルです。
プライベートクラウドの場合、初期で購入したインフラ機器が型落ちしたり老朽化したときに、新しい機器に移行したいと考えるようになります。そんなとき、最新ハードウェアをまた調達して、、、それはオンプレミスの考え方です。クラウドでは、ただ新しい環境を用意して、標準化された手順に則って、システムを移行してやるだけなのです。
物理機器の抽象化
ファイアウォール、買ってますか？クラウドでは何もしなくても標準で付いてきます。さらに、ファイアーウォールがどこにあるのかを気にせず利用出来るようになっています。例えばAWSを見てみましょう。「セキュリティグループ」という機能があります。ここにいくつかのルールを設定しておくことで、すぐさまパケットフィルタリングが実施されます。
サーバー本体はどうでしょうか。仮想マシンを利用する場合、割り当てるCPUのコア数、メモリ容量など、細かく設定していく必要があります。発注をかけるときにスペックを決める必要があるからですね。
クラウド上ではこのような細かな設定は行いません。事前に定義された、利用者の目的別に分かれている「インスタンスタイプ」を指定すると、スパッと起動してきます。
クラウドの利用者は、CPUが何コアだとか、メモリはどうだとか、細かい数字にこだわらず、あくまでも利用目的を重視してそこに合わせたインスタンスタイプを選択するという意識が必要です。
APIによる操作の自動化
同じ手順で繰り返し作業をしていると、これを自動化したいと考えるものです。OSの起動から初期セットアップ、各種プログラムのインストールからコンフィグ設定まで、構成管理ツールを用いることで全て自動化できるのです。ただしオンプレミスの場合、ネットワークケーブルを挿し直したり、サーバーを追加したり、HDDを抜き差ししたり、こんなことは自動化できるはずがありません。
クラウドならそれが可能なのです。
クラウド環境の全体像
クラウドを構成する大きな枠組みとして、
- テナント
- リージョン
- アベイラビリティゾーン
があります。
テナント
自動販売機のくだりでもありましたが、テナントを使うことであたかも自分専用のクラウドインフラを構築可能です。それを活用して、システムごとにテナントを別けたり、逆にまとめたいサービスを単一のテナント内で構成したり、高い自由度で構成出来ます。
リージョン
地理的に大きく離れた世界各国にリージョンとしてデータセンターを設けており、そこがクラウドインフラの心臓部となります。この心臓は冗長化することも可能で、東京リージョンが落ちた場合はシンガポールリージョンでサービスを再開するなんていうことも出来ます。
アベイラビリティゾーン
リージョンの場合は地理的に大きく離れていますが、アベイラビリティゾーンはリージョンごとに独立したクラウドインフラが用意されていることを意味しています。AWSで例えるなら、東京リージョンには、2つのアベイラビリティゾーンがあり、「データセンターA」と「データセンターB」のように見えます。クラウドインフラを構成する時に、アベイラビリティゾーンを活用して冗長構成を取ることで、データセンター単位での耐障害性を高めることが出来ます。
クラウドで仮想化されるリソース
ルーター、スイッチ（サブネットワーク）、グローバルIPアドレス、ファイアーウォール（セキュリティグループ）、などのネットワークリソースはもちろんのこと、サーバーリソースも仮想化された状態で提供されます。
テンプレートイメージ
仮想マシンを起動するには、事前にOSがインストールされた「テンプレートイメージ」を選択します。これはクラウド事業者によって様々で、どんなOSで、どんな機能があるのか事前に確認すべき重要なポイントとなるでしょう。またこのイメージは、自分自身で作り込んだプライベートイメージとして登録しておくこともできますし、このプライベートイメージを公開して、パブリックイメージにすることもできます。
インスタンスタイプ
仮想CPUの個数、仮想メモリーの容量、起動ディスクのサイズなど、予め用意されたスペックから利用者が選択して起動します。プライベートクラウドの場合はここが固定化されますが、パブリッククラウドの場合は必要なサイズを必要な時に必要なだけ利用することが出来ます。
ブロックストレージ
仮想ストレージは、仮想マシンを停止・破棄しても内容が失われない、永続的なディスク領域です。ボリューム作成後の容量変更や、スナップショットの取得など、一般的な高機能ストレージ装置が提供する機能と同等の管理機能が提供されます。ここはいわゆるHDD/SSDの部分ですが、クラウド事業者によってパフォーマンスや課金方法が大きく変わりますので調査が必要です。
例えばAzureの場合、確保したストレージ量ではなく、利用しているストレージ量によって課金されます。AWSの場合は、確保した時点でRAID1が構成されている状態が標準として提供されます。また、後ろのRAIDのフェールオーバーをユーザーが意識することはありません。
クラウドの醍醐味「API」
まるでプログラムを動作させるように、インフラを自由自在に操ることができるのが、クラウドインフラの魅力です。API制御は「認証」「対象」「操作」の3つの要素で構成されます。
APIとは
アプリケーションプログラムインターフェースの略で、とあるソフトウェアから他のソフトウェアを制御するインターフェースの事です。APIを利用すると、ソフトウェアの内部構造を知らなくても、APIを介してソフトウェアに接続して制御出来ます。
クラウドの本質はAPIにあります。どんなAPIが提供されているかによって、そのクラウド事業者の質を見極める材料にもなります。
CLI、SDK、Console
API以外にも、コマンドラインインターフェース、ソフトウェアデベロップメントキット、GUIなコンソールが提供されています。これらも合わせて確認しましょう。
サーバー構築に必要な作業
よし、サーバーを立ち上げよう！と思ったとき、物理環境の場合とクラウド環境の場合では、どのように違いがあるのでしょうか。
- 搬入作業
- ラッキング
- ケーブル配線
これらの作業はクラウド環境では不要となります。ただし、
- 仮想サーバーのリソース構成
- 配置先の決定
- 設計と手順書の作成
これらの作業はどのクラウド事業者を選んだかによっても大きく変わりますし、クラウド事業者独特の、流用が難しい部分となるのは間違いありません。クラウド化をしたからといって、サーバー構築に必要な作業が大幅に目減りすることは期待せずに、どのように効率化されるのかに注目して考えるべきです。
より実践的な構築作業
どのようにしてスペックを選定すべきか、どのようにしてクラウド化によってもたらされる効率化を得ることができるのか、他にも、
- サーバーリソース制御の仕組み
- ブロックストレージリソース制御の仕組み
- ネットワークリソース制御の仕組み
これらを理解することでよりクラウド化によってもたらされる効率化によるコスト削減について理解出来ます。
他にも、
- オーケストレーション（Infrastructure as Code）
- 認証とセキュリティ
- オブジェクトストレージ制御の仕組み
- マルチクラウド構成
- システムのライフサイクル（Immutable Infrastructure）
この辺も抑えておきたい重要なポイントですね。
というわけで宣伝っぽくなりますが
実はシンジはこの本を読んで、この記事を書いています。石田さん経由で本を頂きました。あざます！
特定のクラウド事業者に依存せず、クラウドインフラの仕組みを理解することで、単純にクラウド化すれば金額が安くなるとか、そういう端的な話では無くて、どうやって効率化しようとか、ライフサイクルの考え方を変えようとか、様々な視点でクラウドを評価することが出来ます。そういった意味で、この書籍は大変参考になりましたし、社内でクラウド化を推し進めたい方や、稟議を通すのに苦労されている方などにはもちろんのこと、技術者としてオンプレとクラウドの違いをしっかり理解したい方や、Open Stackに興味のある方などにもお勧め出来る一冊です。
