エンタープライズのクラウドシステム構築を大きく前進させた要素の1つに、クラウドデザインパターンの進展がある。2014年1月には、米マイクロソフトがWindows Azureに対応した「Cloud Design Patterns」の正式版を公開して注目を集めている。一般社団法人Azure Council Experts（ACE）会員企業として活動するFIXERとネクストスケープのセッションでは、前後編の形で、エンタープライズクラウドシステム構築におけるクラウドデザインパターン活用の基本スタンスと実践事例が語られた。
ACEは、Microsoft Azureクラウドプラットフォームの普及や技術者の育成、ノウハウの共有などの活動を展開するパートナーコンソーシアムである。FIXERとネクストスケープのセッションでは、正式公開されたAzure対応Cloud Design Patternsの活用の指針が示された。
復元力のあるシステムを実現する“アーキテクト・トリニティ”とは
FIXER 技術本部長の谷口有近氏が担ったのは、デザインパターンの基本を理解するための“前編”セッションだ。「2000年頃までは性能・負荷を事前に定義した“壊れないシステム”が指向され、2006年頃からは、構成変更しやすい基盤構成で負荷バランスをノード間で変える“柔軟なシステム”が指向された」と同氏はシステム設計における潮流遷移を可用性の観点から説明。そして現在の潮流が、運用の自動化や分散処理系の設計開発手法の導入によりただちに変えられ戻すことのできる、“復元力のあるシステム”にあるとした。
復元力が指向される背景には、今日多用される安価なハードウェアの信頼面での限界や、バックアップや復元が不可能なほどに扱うデータ量が増大したことがある。谷口氏は、パブリッククラウドや構成・運用自動化技術の普及、そしてCloud Design Patternsのリリースによって、復元力を実現しやすい環境が整ってきたと指摘。その際のキーファクターとして、ビジネス、インフラ、ソフトウェアの“アーキテクト・トリニティ（三位一体）”を提唱し、各々の価値と役割を以下のように説明した。
ビジネスストラクチャ・アーキテクトは、ビジネスを技術に落とし込む“アタリ”をつける力量が問われる。具体的には機能単位・サービス単位でのSLAを定義してサービスの復元を設計し、非機能要件を業務へと反映させるのが役目だという。また、インフラストラクチャ・アーキテクトは、“変えられる力”をもってクラウド時代の運用設計を構築・実践するロールだ。変えられる力とはすなわち、コードを理解して構成を組み、非機能要件を要件にする力のことである。ただし、谷口氏は「今は過渡期で、このロールが必須だが、将来的にはモデリングのロールと入れ替わっていく」と指摘した。
そして、コードストラクチャ・アーキテクトには、チームの力量に合わせたコードストラクチャを実現すべく、クラウドデザインパターンをアルゴリズムとして理解する能力が求められる。「分散システムアーキテクチャを理解し、“情報を復元しやすい設計”を行えることと、コードストラクチャが持つ運用や業務での復元力の正確な理解が前提となる」（谷口氏）という。
クラウドデザインパターンを用いた大量データ処理実装の勘所
“後編”セッションには、ネクストスケープ アーキテクトの上坂貴志氏が登壇。実践編として、Azure対応Cloud Design Patternsを活用した大量データ処理の実装にまつわるノウハウを同社の事例を基に解説した。
披露された事例は、Azureクラウド上で、100万曲を超える楽曲データをインターネット配信可能なフォーマットに加工する処理アーキテクチャ実装の取り組みだ。Azureでは、Webの管理画面から手動でインスタンス数を増減することでスケーリングが可能なうえ、CPU負荷や参照するメッセージキュー数、スケジュールによるオートスケールの設定が行える。「今回紹介する事例の勘所は、PaaSを活用してスケーリングを自動化するところ」と上坂氏。事例では、並列処理と並列処理のつなぎにキューを用いて、その数を基にしたオートスケール設定からスケールアウト型でPaaSの数を増減させたと説明した。
上坂氏は、「パブリッククラウドを用いたシステム構築で怖いのは、処理によっては予想を超えてコストが跳ね上がること」と指摘。対策として同社が試みたのは、楽曲データのエンコードからトランスコード、暗号化、アップロードに至る処理タスクの統合だ。「エンコードは最大に負荷がかかるが、トランスコード処理と暗号化はたいしたことがない。そこで、この3つのタスクを統合し、インスタンス数を抑えた」と同氏は述べ、このようなコスト対策を事前に検討することが不可欠だと説いた。
事例ではCloud Design Patternsから3種のパターンが活用された。1つ目は「競合する消費者（Competing Consumers）パターン」で、スループット、スケーラビリティ、可用性の向上と、作業負荷を最適化するために同時に複数のメッセージ処理を可能にするものだ。2つ目は、「パイプとフィルター（Pipes and Filters）パターン」で、タスク要素のデプロイとスケーリング処理を別々に実行することであり、パフォーマンス、スケーラビリティ、再利用性の向上につなげた。3つ目は「リソース統合計算（Compute Resource Consolidation）パターン」で、計算リソースの使用率を高め、クラウドでホストされるアプリケーションの処理の実行に関連するコストと管理オーバーヘッドを削減させている。
「クラウドの時代になり、サーバーやストレージ、ネットワークなどのプラットフォーム部分について、どんなスペックのものを用意しなければならないのか、とエンジニアが苦悩することは無くなりつつあります。これは今から20年ほど前に汎用機で設計・開発をしていた時代とよく似ています。すると不思議なことにクラウド上で稼働するアプリケーションの設計技法もどこか昔の時代に似てくるということに気がつくのです。もちろんそのままの設計技法では通用しませんが、今回ご紹介したようなクラウド上で使用するデザインパターンはどこか懐かしく、長らくシステムに携わってきた人には違和感なく理解できるはずです。Cloud Design Patternsを活用して、ビジネス効果を最大化させるようなアーキテクチャの実装を目指していただければと思う」と上坂氏は語り、セッションを締めくくった。