いまさら聞けない「クラウドの基礎」〜クラウドファースト時代の常識・非常識〜：クラウド時代のアジャイルシステムインテグレーション（1）（3/3 ページ）

クラウドの可能性や適用領域を評価する時代は過ぎ去り、クラウド利用を前提に考える「クラウドファースト」時代に突入している。本連載ではクラウドを使ったSIに豊富な知見を持つ、TISのITアーキテクト 松井暢之氏が、クラウド時代のシステムインテグレーションの在り方を基礎から分かりやすく解説する。

[松井暢之，TIS株式会社]

クラウドを前提としたシステムインテグレーションの価値

　このような従来のシステムインテグレーションを引きずったままでは、仮想化によるサーバー集約の効果以上に「クラウドならではの価値」を得ることはできません。

　クラウドの価値を引き出すポイントは、「自社ビジネスを差別化する収益の源泉となり、価値を生み出す機能」以外の部分をクラウドで賄うことです。すなわち、できる限りシステムを標準化して再利用するとともに、自動化によってシステムを維持運営するための手間を極小化することで、初めて「クラウドだからこそ実現できるアジャイルなシステムインテグレーション」が可能となるのです。

　このアジャイルなシステムインテグレーションを実現するためにはさまざまな変革が必要になりますが、インフラ運用の観点からは以下のようなポイントが挙げられます。

1.マネージドサービスの活用

　社外のクラウドサービスプロバイダーが提供するマネージドサービスを活用することで、そのサービスを構成する下位レイヤーの運用を考慮する必要がなくなります。例えばIaaSを利用することで、サーバーやストレージなどのハードウェア障害対応やリソース計画を考える必要がなくなります。また、クラウドがマネージドサービスとして提供しているRDBMSを用いれば、パフォーマンスチューニングや障害時の待機系切り替え運用に煩わされることもなくなります。

　マネージドサービスが提供する機能と限界点を十分に理解し、システムが必要とするSLAが担保できる範囲内で、できる限りマネージドサービスを利用することが、「ビジネスの価値を生み出す部分以外」に掛けられていた運用管理コストを削減することにつながります。

2.インフラ運用設計の標準化・資産化

　とはいえ、マネージドサービスを組み合わせるだけでビジネスを安定運用できるなら良いのですが、通常はそれほど簡単にはいきません。例えば「マネージドサービスのRDBMSのパフォーマンスや障害時の切り替え時間に満足できない場合」、あるいは「ビジネスに特化した自作のミドルウェアを、障害発生時に待機系へ切り替える場合」など、複数のサーバーとミドルウェア、マネージドサービスを組み合わせて、システムが必要とするSLAを担保できる運用設計を、しっかりと作り込まなければならない場合も多いものです。

　しかしそうした場合でも、システムごとに場当たり的に設計してしまうのではなく、インフラ運用設計を標準化することがポイントです。具体的には、「ビジネスモデルと、その重要度に応じたSLA」を設定し、それに対応した「専用のインフラ運用パターン」を複数用意し、再利用可能とすることで、同じようなインフラ運用設計を何度も作る無駄を省くことができるのです。

3.インフラ構築の機械化・自「働」化

　ただ、インフラの運用設計を標準化し、ビジネスモデルとSLAに対応させてパターン化したとしても、それらを従来のような「設計書」としてまとめてしまっては意味が半減してしまいます。

　「プログラム的に構成可能なリソースを、必要に応じて簡単に素早く調達できる」のがクラウドの特徴ですから、この「パターン化されたインフラ運用設計」を、「指定されたインフラが機械的に構築され、かつ正しく構築されたことを自分自身で機械的に検証できるプログラム」としてコード化しておけば、設計書を元に手作業でインフラ運用を構築し、正しく構築されたことを目視確認する必要がなくなります。つまり、インフラ運用設計のプログラムをクラウドに与えれば、望んだインフラ運用が自“働”的に構築されるのです。

　「自働化」とはトヨタ生産方式で使われる言葉で、作られたものが良品であれ不良品であれ、ただ単に機械的に動き続けることを意味する「自動化」とは異なり、「不都合を検知して停止」する行為をも自律的に行えることを意味しています。つまり「自働化」とは、少なくとも「検知可能な不都合が起きていないこと」が保証される仕組み、という考え方なのです。

　このような考え方は、「Infrastructure as Code」と呼ばれています。インフラ運用設計をプログラム化し、構築・検証を機械化・自働化することで、インフラ運用を構築するリードタイムを短縮してコストを圧縮できるだけではなく、同じ品質のインフラ運用を何度でも再生できるようになるのです。

図3　インフラ運用の構築方法《クリックで拡大》

4.システム運用の自律化

　クラウドでは、必要なリソースをプログラム的に構成して調達できるのですから、システムが自分自身の状態を監視し、必要に応じて自力でリソースを調達して適切に構成し、自分自身へ組み込んでもよいはずです。

　例えば、サーバーのCPU利用率やレスポンスタイムなどを監視し、事前に設定した閾値を超えた場合にはシステムが能動的にサーバーを立ち上げて負荷をロードバランスする「オートスケーリング」があります。これは今日のクラウド上のシステムでは、ごく一般的に利用されている自律的な運用機能の一例です。あるいは、システム障害を検知した場合に、別のクラウドにシステムを構築し直してデータをリストアし、業務を継続させるといった自律的な災害対策運用を組み上げることも可能でしょう。このようなシステム運用の自律化も、「ビジネスの価値を生み出す部分以外」に掛けられていた運用コストの削減につながります。

5.「システム更新」の排除

　Infrastructure as Codeが実現されており、必要なリソースをいつでも必要なだけ調達し、スピーディにシステムを構築できる環境を前提とするなら、「一度構築したシステムには二度と手を加えない」「不要になったら廃棄する」「アプリケーションやミドルウェアのバージョンアップなどシステムを更新する際には、システム一式を新規に作り直し、システムへのエントリポイントを付け替える」という運用が可能となります。このような考え方は「Immutable Infrastructure」と呼ばれており、システムをImmutable（不変）に保つことで、次のような効果が見込まれます。

1. 稼働中のシステムはそのままに、複製した環境でシステム更新ができるため、システム更新作業がシンプルになる
2. 何らかの障害が発生したとしても、可動実績のある元のシステムへ容易に切り戻すことができる
3. システムを表現するプログラムからシステムを一方通行で構築するため、設計書（パターン）と実際の環境の乖離がなく、システムのブラックボックス化が抑制できる

図4　システムの更新方法《クリックで拡大》

　ただしImmutable Infrastructureを実現するためには、システム全体のアーキテクチャを「容易にシステムを乗り換えられるように設計」する必要があります。 例えば「特定のサーバーのメモリ上にしかセッション情報が存在しないようなアーキテクチャ」を採った場合、そのサーバーを安全に停止させるためには複雑な手順が必要となります。また、旧システムから新システムへ必要なデータを機械的に漏れなく移行する仕組みがないと、新システムへデータを移行する手間がかかるなど、必要なシステムを瞬時に作る／廃棄するImmutable Infrastructureの実現は難しくなるのです。

クラウド時代のシステムインテグレーション

　以上のような、クラウドならではのアジャイルなシステムインテグレーションへの転換は、着実に企業に浸透し始めています。例えば、みずほ銀行はプライベートクラウドを活用してインフラ運用の標準化とパターン化を押し進め、設計標準を満たした「構成済みのシステム基盤」を自動的にクラウド上で配布する仕組みを整えることで、2カ月を要していたシステム基盤構築を2〜3日にまで短縮しました。これにより、インフラ運用の構築コストを6割削減したそうです。

　クラウド時代のアジャイルなシステムインテグレーションへの転換は、先進的なサービサーだけではなく、従来型企業のエンタープライズシステムでも着実に進みつつあるのです。

◇

　次回は、クラウド時代のアジャイルなシステムインテグレーションを支えるクラウド関連技術について詳しく見ていきます。

著者プロフィール

松井 暢之（まつい のぶゆき）

TIS株式会社

コーポレート本部 戦略技術センター所属

アーキテクチャ設計やデータモデル策定、フレームワーク構築などバックエンド側のアーキテクトとしてプロジェクトに従事。その後、現部門に異動し、戦略技術の検証、新規サービスの事業企画に携わる。また、インフラ・運用のパターン化、自動化を実現するクラウドオーケストレーションツール「CloudConductor」開発とOSS化をリードしている。