AWSクラウドサービスデザインパターン(3)

機械学習技術人工知能技術デジタルトランスフォーメーション技 ICTインフラ技術クラウド技術本ブログのナビ

サマリー

Amazon Web Serviceクラウドデザインパターン設計ガイドより。

クラウドコンピューティングが普及するにつれて、コンピューターリソースの調達と運用に大きな変化が起こっている。クラウドにより、必要なときに必要なだけ、多岐にわたるITリソースを、安価かつ瞬時に調達することが可能となり、ITの新しい世界の幕開けとなった。

特に、2006年からクラウドサービスを提供しているAmazon Web Service(以下AWS)の進化は目覚ましく、仮想サーバー、ストレージ、ロードバランサー、データベース、分散キュー、NoSQLサービスなどの多種にわたるインフラストラクチャサービスを、初期費用の無い安価な従量課金モデルで提供している。利用者は、これらの非常にスケーラビリティの高いサービスを、必要な時に必要なだけ瞬時に調達して利用でき、また、必要なくなったときは、すぐに廃棄でき、その瞬間から利用料はかからなくなる。

これらのクラウドサービスにはすべてAPIが備わり公開されているので、Web上のツールからコントールできるだけでなく、ユーザーはプログラマブルにインフラストラクチャをコントロールできる。もはやインフラストラクチャは物理的に硬くて融通の効かないものではなく、非常に柔軟で変更ができるソフトウェア的なものになったといえる。

このようなインフラストラクチャを使いこなせば、これまでの常識では考えられないほど素早く安価に、耐久性が高くスケーラビリティがあり柔軟性の高いシステムやアプリケーションを構築できるようになる。こうした「インターネット時代の新しいサービスコンポーネント(=クラウド)」が用意された時代においては、システムのアーキテクチャ設計に携わる人には、新しい心構え、新しい発想、新しい標準が必要となる。つまり、新しいITの世界は、クラウド時代の新しいノウハウを身につけたアーキテクトを欲している。

日本にも2011年3月にAWSのデータセンター群が開設され、すでに数千の企業やディベロッパーが、AWSを活用してシステム作りをしている。顧客は、趣味でインフラを用いる個人のディベロッパーから、新しいビジネスを素早く立ち上げるスタートアップ、コスト削減の波にクラウドで抗おうとする中小企業、クラウドのメリットを見逃せない大企業、そして官公庁や自治体、教育機関に至るまで非常に幅広い。

クラウドを利用するユースケースとしても、典型的なWebサイト・Webアプリケーションのクラウドホスティングから、既存の社内ITインフラの置き換え、バッチ処理、ビッグデータ処理や化学計算、それから、バックアップやディザスターリカバリーまであり、汎用的なインフラとして利用されている。

クラウドの特徴を活かすことで、これまで考えられなかったようなビジネスやアプリケーションを実現し、新規事業、新規ビジネス、新規サービスとして成功を収めた例や、既存システムを移行してTCOを削減した例もすでに存在している。

しかしながら、クラウドを使おうとして挫けてしまった例はいまだに耳にするし、クラウドを最大限に活用したアーキテクティングを実施できているのは残念ながらいまだ多く無い、というのが現状となる。特にクラウド特有のメリットを活かした設計、例えばスケーラビリティ(Scalability)を活かすための設計や、システム全体で耐障害性を高める設計(Design for Failure)、コストメリットを考慮した設計などが十分にできているケースは未だ少ない。

ここではそれらのクラウドを用いた新しいアーキテクティングのパターンを整理したもの、Cloud Design Pattern(CDP)について述べる。

CDPは、クラウドを利用したシステムのアーキテクチャ設計時に起こる、典型的な問題とそれに対する解決策を、その本質を抽象化して再利用できるように整理・分類したものとなり、これまでアーキテクトが発見してきた、もしくは編み出してきた設計・運用のノウハウを、再利用が可能なデザインパターンという形式で、暗黙知から形式知に変換したものといえる。

CDPを用いることで、下記が可能となる。

既存ノウハウを活かすことで、クラウドを用いたシステムのより良いアーキテクチャ設計が可能となる。
アーキテクト同士で共通の言葉を使って会話できるようになる。
クラウドがより理解しやすくなる。

以下にCDPのパターンのうち、前回は「データアップロードのパターン」「リレーショナルデータベースのパターン」「非同期処理/バッチ処理のパターン」について述べた。今回は「運用保守のパターン」「ネットワークのパターン」について述べる。

運用保守のパターン

Bootstrap: マシンイメージからサーバーを作成する方法、すなわちStampパターンの適用に際し、どの程度の頻度でマシンイメージを取得するかは運用効率に対する課題となる。Stampパターンでは、ミドルウェアからアプリケーションまですべてが設定済みで、立ち上げるだけでそのまま動くマシンイメージも作成することができる。この場合、仮想サーバーの起動は非常に早いが、ミドルウェアの一つをバージョンアップしなければならなくなった場合や、アプリケーションの設定に変更があった場合、マシンイメージを再度作り直す必要が出てくる。この課題に対して、クラウドではマシンイメージの作成が容易にできるだけでなく、起動時にパラメータを設定できる機能を持つものがあり、この機能を利用してサーバー構成に必要なパラメータを渡すことで、サーバーを起動する際に必要な設定をサーバー自ら取得し、インストール、起動、設定までを実施するマシンイメージを作成する。

Cloud DI: 規模の大きなシステムでは、アクセス数などの増加とともに多数のサーバーを増設することとなる。その場合、サーバー構築に必要なインストールや設定を一つ一つ手作業で行うのは非常に手間となり、期間内で終わらせることも難しくなる。サーバー構築の自動化を行う方法としてシステム管理ツールを利用する方法もあるが、そこにはコストの問題がある。特に外出ししておきたい情報(DB接続先IPアドレス、サーバー名、認識番号等)が多くある場合は、Cloud DIパターンを用いることで柔軟にサーバー初期化ができるようになる。

Stack Development: システム開発や運用保守においては、テスト環境やステージング環境を準備するのが一般的となる。これらの環境は常時利用するものではないので、本番環境と同じ台数のサーバーを用意するのはコスト効率が悪い。そこで仮想サーバーの利用となるが、システムが複雑で仮想サーバー数が多い場合、その環境の構築や、関連する仮想サーバーの起動・停止などの作業は煩雑となり時間がかかってミスも多くなってしまう。そこでサーバー群の立ち上げに関するテンプレートを用意し、それに従い一気に自動で起動する方法を利用する。構築したい環境で必要なクラウドコンポーネントをテンプレートに記載しておき、そのテンプレートに従い環境構築を行うことで、複雑なシステムをミスなく容易に準備することができる。

Server Swapping: サーバーが故障すると復旧に追われる。故障の原因は多種多様だが、ディスクは問題ない場合も少なくない。そのような場合、問題のないディスクを別のサーバーに移し替えると早急に復旧できるが、データセンターでの作業や代替サーバーの手配、ディスクの差し替えなどで時間がかかる。これに対して、仮想サーバーで付け替え可能な仮想ディスクほ利用し、仮想サーバーに障害が起きた場合に、障害が起きた仮想サーバーのディスクを別の仮想サーバーに付け替えて障害復旧を行うことができる。

Monitoring Integration: システムの運用作業ではモニタリング(サービス/リソースの監視など)は必須で、クラウとではモニタリングサービスが提供されている。しかし、クラウドのモニタリングサービースは仮想サーバー内(OS/ミドルウェア/アプリケーションなど)の監視はできないので、独自のモニタリングが必要となるが、そうすると利用するモニタリングシステムが複数となり運用が煩雑化する。これに対して、仮想サーバーではクラウドのモニタリングサービスで監視し、OS/ミドルウェア/アプリケーションなどは自前の仕組みで監視する。クラウドのモニタリングサービスはAPIを提供しているので、自前のモニタリングサービスで、クラウドのモニタリングサービスからAPIを介して情報を取得し、クラウド側を含めた一元管理が可能となる。

Weighted Transtion: システム全体をある地域から異なる地域へ移行したいというケース、例えばオンプレミスのデータセンターから、クラウドへシステムを移行する場合、もしくはクラウドのある地域から異なる地域へ移行したい場合が考えられる。この際に、システムのドメイン名を変えることなく、なおかつシステムを停止することなしにスムーズに移行したい。ドメイン名を変えることなくシステム全部を移行させるには、DNSサーバーにおいて重み付ラウンドピンという機能を用い、名前解決する前に既存システムから新システムに切り替える手法がある。最初は新システムに少しだけ振り分け、問題がなければ、新システムへの配分を徐々に増やしていくことができる。

Log Aggregation: APサーバーの台数が多いシステムでは、アクセスログなどが各サーバーに分散している場合、ログの収集や分析、トラブルシュートの際、分散したログを収集する必要があり、時間がかかる。また、オートスケーリングする環境では、スケールインでサーバーが自動的にシャットダウンされてしまうため、サーバー上のログが消去されてしまう。このような問題に対応するため、ログの収集先としてインターネットストレージを使い、大量のログを安価かつ高い耐久性で保存する。これはAPサーバーなどにログ収集エージェントを常駐させ、集約対象のログをインターネットストレージに送るようにすることで実現できる。

Ondemand Activation: システムをセキュアにするための、サーバーに対する外部からのアクセス(インバウンド)は通常、最低限必要なものに制限されている。また、メンテナンスなどで各サーバーへのログインを行う際は、ログイン元を制限するために踏み台サーバー(Bastin)を経由する場合が多い。さらに、外部への情報流出を防ぐために、サーバーから外部へのアクセス(アウトバウンド)を禁止するケースもある。それらの施策を行いセキュリティ性を上げると、メンテナンスが容易ではなくなる。クラウドでは仮想サーバーの起動・停止、ファイアウォールの設定変更など、従来であれば人手を解する必要がある設定変更をAPI経由で行うことができる。そのため、踏み台サーバーは外部からアクセスする必要がある時のみ、NATはOSパッケージのアップデートなどのメンテナンス時だけ起動するようなしくみを作り、セキュリティ性をあげつつメンテナンス性を上げることができる。同時にファイアウォールも任意のタイミングで変更可能なため、通信が必要な場合のみ通信を強化するといった柔軟な対応が可能となる。

ネットワークのパターン

Backnet: インターネットに公開し、不特定多数のユーザーからアクセスされるサーバー(例えばWebサーバー)は、管理目的でのアクセスも同じネットワークインターフェースを通して行われる場合が多い。しかし高いセキュリティレベルが要求される場合、信頼できるアクセスとできないアクセスが同じネットワークインターフェースを利用するのは避けるべき課題となる。この課題に対応するため、公開目的のWebサーバーに複数のネットワークインターフェースを設置し、管理用のネットワークインターフェース(バックネットと呼ばれる)と公開用のネットワークインターフェースに分ける。

Functional Firewall: ファイアウォールを利用した階層的なアクセス制限は従来のシステムでも通常行われてきたセキュリティ対策である。しかしアクセス制限のルールが多くなると、ファイアウォールの設定も多く煩雑となり、それにともない運用コストが高くなってしまう。従来、ファイアウォールは専用機器を利用し、グループ化せずにルールを管理することが多かった。またグループ化できたとしても、サーバー単位で容易に適用することは困難でもあった。クラウドではファイアウォールも仮想化されており、より柔軟に設定することが可能で、ルールをグループ化し、グループ単位での設定や各サーバーへの適用を行うことができる。

Operational Firewall: 規模の大きいシステムになると、開発保守を行う組織が複数存在する。例えばシステム開発を行う会社、ログ解析や運用監視を行う会社などに分かれるケースなどが該当する。ファイアウォールのルールを機能ごとのグループで定義した場合、アクセス元が変更になったり、アクセス自体を不要にしたい場合、その都度、機能ごとにグループ化されたルールを変更する必要があり、手間がかかるほか、それぞれの組織がどのサーバーにアクセスできるかを一元的に管理できない。この課題に対して、クラウドでの仮想化されたファイアウォールを用いて、ルールをグループ化する際に、グループという単位を組織にすることで、組織に関する設定を一元管理できる。

Multi Load Balancer: Webアプリケーションをマルチデバイス(PCや携帯、スマートフォン)に対応させる際、EC2インスタンスにアクセスデバイスごとのSSIや接心振り分けなどの設定を行うと、サーバー台数が増加した時に設定変更が面倒となる課題に対して、Webアプリケーションをホストしている仮想サーバーに、設定が異なる複数の仮想ロードバランサーを割り当てることで、サーバーに手を入れることなく、ネットワークアクセスに対する挙動を仮想ロードバランサー経由で変更することが可能となる(セッションやヘルスチェック、HTTPSなどの設定)

WAF Proxy: Eコマースなどの重要な個人情報(クレジットカード情報など)を扱うWebサイトは、セキュリティを高めるためにWAP(Web Application Firewall)を導入することが多い。しかしクラウド上のシステムではスモールスタートしたシステムが多く、ほとんどの場合WAFの導入は検討されていない。それらの課題に対応するため、クラウドシステムでは、上流にAWFのみが機能するプロキシサーバーを構築することで、少ないライセンス数のみで運用できるようになる。

CloudHub: 複数拠点間でのVPN(仮想プライベートネットワーク)接続をフルメッシュ型で構築すると、拠点が増えるに従って各拠点のVPNルーターへの設定も煩雑になり、メンテナンスコストが増大する。この問題を解決するためにスター型でVPNを非有地区すると、各拠点のVPNルーターはVPNハブに接続するだけでよくなる。しかしVPNハブに障害が起こると、すべてのVPN接続に影響を与えてしまうので、VPNハブの可用性が重要な課題となる。従来のVPNハブは、可用性を高めるためにVPNに利用する通信機器を冗長構成にするなど、高額な初期投資を必要としてきた。これに対して、クラウドにはVPN機器を提供するものもあり、VPNハブとして利用することができる。

Sorry Page: プログラムコードの不具合や、サーバー/ネットワークの過負荷/障害などが原因でWebサイトにアクセスできない場合がある。また、大規模なシステム改修時やセキュリティインシデント発生時に、一時的にWebサイトを閉鎖したい場合がある。このような場合、サイト訪問者がWebサイトにアクセスできなくなると顧客体験の悪化につながるため、代替となるコンテンツを表示させたい。この課題に対して、クラウドでは低コストで信頼性の高いインターネットストレージを用いて静的サイトをホストできるので、Sorry Pageや静的ページだけで構成されたバックアップサイトのホスティングを実現することができる。

Self Registration: サーバーを起動/停止する場合、それに伴うモニタリングやバックアップなどの設定も変更する必要がある。サーバーの数や頻度が少ない場合は、人の手で実施する場合が多いが、多くなってくるとオペレーションミスや、そもそもの設定にかかる時間が現実的ではなくなってしまうので、自動化する仕組みが必要となる。これに対して、クラウドの仮想サーバーを用いることで、負荷や処理量に応じて仮想サーバーを増減する。その中で、仮想データベースに自分(仮想サーバー)の情報を起動時に登録する形にしておき、定期的にモニタリングしたりバックアップの対象情報を最小さたりすることで、仮想サーバーの増減への追従が容易となる。

RDP Proxy: EC2のWindowsインスタンスにリモートデスクトッププロトコル(RDP)で接続する場合、デフォルトでTCP-3389番を使用するため、社内ファイアウォール経由などで接続する際に、このポートをオープンしていく必要がある。しかしながら、社内のセキュリティポリシー上、RDPのオープンが許可されていなかったり、RDP自体にセキュリティの脆弱性が発見されたりして安全に使用できない場合がある。またVPC内のインスタンスに接続するためにはインスタンスにEIP(Elastic IP)を付与する必要がある。Windowsの標準機能であるリモートデスクトップゲートウェイ(RDゲートウェイ)を使うことで、SSL(HTTPS)を使用してインターネット経由でもよりセキュアにWindowsインスタンスに接続できるようになる。

Floating Gateway: システム開発の際には、開発環境やテスト環境、ステージング環境などいくつかの環境を構築するのが、各環境間ではシステム構成に差異がないのが好ましい。また、既存システムがアップグレードするような場合には、既存環境に手を入れずに新しい環境を構築するほうがリスクが抑えられる。クラウドを利用することでこれらを容易に実現できるが、新たに構築した環境のIPアドレスレンジが既存のものと変わってしまうと、システム設定などの変更の必要が出てくる。これに対して、クラウドでは、仮想的なネットワーク環境を瞬時に調達できるため、開発やテスト、システム環境アップグレードの際に、同一の設定を持った仮想ネットワークを複数作成でき、同一設定の仮想ネットワークであればIPアドレスやルーティングを同一にできるため、設定ファイルやステージごとのシステム環境差異の影響を少なくできる。

Shared Service: ログ収集サーバー、監視システムのホストサーバー、WAFやウィルス定義配布サーバーなどは、複数のシステムに対して提供される共通なサービスだが、こういったサービスをシステムごとに作り込むと、システムのコストや運用/メンテナンスの工数が大きくなる。これに対して、個別のシステムは、そのシステムごとに独立したネットワーク内に構築し、共通で使いたいサービスは共通サービス用の独立ネットワーク内に構築する。共通システムと個別システムは、クラウド内のネットワーク接続機能を用いて論理接続を行う。これにより、各個別システムから、共通サービスネットワーク内のシステムを利用できるようになる。

High Availability NAT: システム構成をセキュアにするため、インターネットに公開する必要がないサーバーは、インターネットとの直接的な通信ができないネットワークセグメント(プライベートサブネット)に配置する構成にする場合が多い。この場合、プライベートサブネットから外部へのアウトバウンド通信はNATサーバーやプロキシサーバーを経由するが、このサーバーに障害が発生すると、プライベートサブネットのサーバーからアウトバウンド通信が行えなくなり、システム全体の障害につながる。これに対して、クラウド仮想サーバーを用いて、NATサーバー/プロキシサーバーの冗長化を行う。