Azureのアーキテクチャ

1.はじめに

「アーキテクチャ」という言葉は元々は建築学でいう「構造」や「構成」などといった「基本的設計概念」「設計思想」を持った言葉になります。
ことIT分野においてもソフトウェア、ハードウェア、システムの「設計」を建築物を組んでいく観点から用いられるようになりました。こと「Azure」で用いられる「アーキテクチャ」は顧客エンゲージメントで得たプラクティスに基づき、高可用性あるアプリケーションの設計を体系化させるための方法として示しています。
当記事では「Azure」でアーキテクチャの設計から導入、どのようなスタイルがあるのかについて説明していきます。

2.アーキテクチャの設定するための構造化

1.アーキテクチャの設計

「アーキテクチャ」の設計という工程を行う前に、どのようなアーキテクチャを構築していくのかという要件定義の明確化を行わなければなりません。ここがまずアーキテクチャすべての基盤となる上、明確化しないと設計はおろか実装目前にして要件の見落としで、大きくふり出しに戻るということがありえます。
設計の手順は以下の通りとなります。

• 1.アーキテクチャスタイルの選択
• 2.コンピューティング、データストア用のテクノロジを選択
• 3.Azureアプリケーションの設計(10の原則)
• 4.ソフトウェアの品質(5つの柱)
• 5.クラウド設計パターンの適用

2.アーキテクチャスタイル

以下はアーキテクチャスタイルの各概要と依存関係の管理についてです。

上段の表でまとめた「アーキテクチャスタイル」を選択することで、「制約」がもたらされ、それぞれのスタイルには、「個々で固有の課題」があります。課題と制約は「イコールの関係」にあり、それをクリアしたとき、そのアーキテクチャスタイルは大きな利点を見出し、最適なアーキテクチャという形あるものとなります。

2.テクノロジの選択

構築するアーキテクチャスタイルを知った後は、アーキテクチャの主軸となる「テクノロジ」を選んでいきます。

• コンピューティング

アプリケーションをその場で実行する「コンピューティングリソース」のホスティングモデルを言います。ホスティングモデルはクラウドサービスである「PaaS」「IaaS」「FaaS(SaaS)」の3つのカテゴリーに分類し、それぞれの特徴に該当するものを選択します。

• データストア

「データストア」は、データの構造やサポートする操作の種類によって分類され、要件に沿ったものを選択することが望ましいです。また、特定のカテゴリーのすべてのストアが同一の機能セットを提供しているとは限らず、ほとんどの場合が、データをクエリし処理するサーバー側の機能を有し提供しています。

• メッセージング

システムコンポーネント間の、非同期メッセージを有効にすることができます。また、情報をブローカーを通して分散させることで、個々の負荷を分散させられるだけでなく、ワークフローの調整できるなどあらゆるメリットがあります。

これら3つのテクノロジが、大半のクラアドアプリケーションの「中核」を成しているため、これによって設計の側面が決まります。

3.アプリケーションの設計

以下は「Azure アプリケーション」を設計していく上での原則となります。

• 自動修復機能の設計

分散システムを採用した場合、稀に障害が発生して後のシステムに影響を及ぼしかねません。そのため、障害発生時に素早く対応できる自動修復機能をアプリケーションに備えて設計していきます。

• すべての要素を冗長にする

単一の障害をなくすため、アプリケーションに冗長性を組んでいきます。

• 最小限の調整

スケーラビリティ実現のために、アプリケーションのサービス間の調整は必ず最小限にする。

• スケールアウトが可能とする設計

水平方向にアプリケーションを拡張できるように、需要に応じて新規インスタンスの追加実装、削除をしてアプリケーションを設計していきます。

• 制限に対応できるようにパーティション化

パーティション化によって、データベース、ネットワーク、コンピューティングの制限に対処します。

• 操作に合わせて設計

運用チームが作業時に必要とする適切なツールを選択できるように設計します。

• 管理対象サービスを使用

サービスとしては可能な限り、インフラストラクチャである「IaaS」を採用するのではなく、プラットフォーム「PaaS」を使用します。

• ジョブに適したデータストアの選択

活用するデータに適したストレージ技術と使用方法を選びます。

• あらゆる展開を見越して設計していく

成功するアプリケーションの大半が時間を経るごとに変化していくため、事前に「改良」を見越したうえで設計していくと継続的なイノベーションに繋がります。

• ビジネスニーズに合わせて構築していく

基本的な設計の方針は、「ビジネス要件」に適しているかを前提にしていることが重要となります。

4.品質

以下はソフトウェアを設計していく中で、大切となる「品質」における重要な5つになります。

• コストの最適化

クラウドソリューションにおける設計に、もたらす価値そのものは早期生成時に集中します。原則として「Build-Measure-Learn」という考え方を基として市場に投入するまでの期間を短くする一方で資本集約型ソリューションの回避ができます。
従量課金制の戦略をアーキテクチャに採用することで、初期時に多額な投資をすることなく、スケールアウトな投資を実現できます。これで機械コストと先発者の優位性、そしてファストフォローのバランスを考慮することができる上、最終的に予算、コスト制限のポリシー、コントロールの確立へとなります。

• オペレーショナルエクセレンス

運用する環境下で継続的に稼働させるための運用プロセスになります。「オペレーショナルエクセレンス」の規範となる要素は、「DevOpsの原則を考慮してのワークロードの設計等の方法を提供する「アプリケーションの設計」」、「アプリケーションパフォーマンスの可用性の「監視と診断」の管理」、「アプリケーションが実行されるプラットフォームをデプロイするためのプロクティス」などの6つからなります。

• パフォーマンスの効率

利用者の要求に対応し、より効率的なワークロードのスケーリングを実施することです。実施するには、スケーリングが組まれているプラットフォーム「PaaS」を実装することで可能としています。
スケーリングの方法は2パターン存在し、1つが垂直スケーリング(スケールアップ)というVMの拡張、リソース容量の増設を行うもの、そして水平スケーリング(スケールアウト)というVMやデータベースレプリカなどのリソースをインスタンスに追加することで、その処理性能を向上させます。

• 信頼性

「信頼性」の高いワークロードは、障害から回復して動作を継続させるシステム能力である「回復性」と、ユーザーが必要に応じてワークロードにアクセスできるようにする「可用性」の両方を備えたものになります。

• セキュリティー面

Azureプラットフォームでは、外部ネットワークからの侵攻やDDoS攻撃などのあらゆる脅威に対する保護が低起用されていますが、ことワークロードの保護には、利用者からの協力が必要不可欠です。しかし、だからといってAzureのセキュリティがかえって脆弱というわけではありません。「セキュリティ」そのものはAzureの「すべての要素」に統合されています。それゆえに安全かつ堅牢なセキュリティをモノとして提供しています。

5.設計パターン

「設計パターン」は、今現在までに起きた「特定の問題」を解決するため、あるいは問題を発生にくくするために、幾度と繰り返し実証された設計パターンになります。
オンプレミス環境とは違い、クラウド環境では、本来起きてはならない「問題の発生」を前提に「課題」としてそれらを考え、対処していく必要があります。そもそもAzureを含めたクラウドサービスに関わらず「分散システム」が課題となる「分野パターン」に関連しています。
設計パターンとしての課題は「可用性」「データ管理」「設計と実装」「メッセージング」「管理と監視」「パフォーマンスとスケーラビリティ」「回復性」「セキュリティ」の8分野になります。

3.アーキテクチャの一例 【ビッグデータアーキテクチャ】

1.ビッグデータアーキテクチャ

「ビッグデータアーキテクチャ」とは、従来のデータベースシステムでは大ずるデータ、あるいは複雑なデータの「インジェスト、処理、分析」を扱うために設計されたアーキテクチャになります。主に、ビッグデータソースのバッチ処理やリアルタイム処理、予測分析などのケースで使用されます。

2.コンポーネント

「ビッグデータアーキテクチャ」の大部分のコンポーネントとして、以下のモノが組み込まれています。

• データソース

「すべて」のビッグデータソリューションは、1つ以上のデータソースから成り立ちます。たとえば、「リレーショナルデータベース(RDB)」などのアプリケーションデータストアや、「Webサーバーログファイル」等の静的ファイルなどがあります。

• データストレージ

「データレイク」と呼ばれる、バッチ処理操作のためのデータを大量に保持できる「分散ファイルストア」ストレージです。実装するためには、「Azure Data Lake Stoa」もしくは「Azure Storage」内の「BLOBコンテナー」を選択します。また、あらゆる形式の大規模ファイルを大量に保持できるだけの容量を有しています。

• バッチ処理

ビッグデータソリューションの多くの場合、取り扱うデータセットが大きいために、実行時間の長いバッチジョブの使用から、ファイルの処理、処理したファイルデータを分析を行う専用のデータをあらかじめ備えておく必要があります。デフォルトとしてこれらのジョブには、ソースファイルの読み取りから処理、新規ファイルへの出力の書き込みが含まれます。

• リアルタイムメッセージ取り込み

ソリューションに、リアルタイムソースが含まれている場合、ストリーム処理のために、リアルタイムメッセージの取得・保存の方法がアーキテクチャに組まれていることが必須となります。これは受信メッセージを処理用のファイルにドロップできる、データストアでも同様な事はできます。しかし、多くのソリューションでは、メッセージのためのバッファーとして機能するだけでなく、スケールアウト処理、信頼性のある配信などをサポートする「メッセージインジェストストア」が必要となります。

• ストリーム処理

リアルタイムメッセージ取得後に、データを分析用にフィルターにかけ、集計、分析処理にかけて、最終的に処理されたストリームデータは出力シンクに書き込まれます。「ストリーム処理」は従来の一度データベースなどに保持する「一括処理」とは違い、データ発生時に決まったクエリに従ってデータ処理を行う「差分処理」を行います。そのため、大量のデータを高速かつリアルタイに近い形で処理できます。

• 分析データストア

ビッグデータアーキテクチャの要ともいえる「分析ストア」は、アクセス頻度の高く使用率も高いデータである「ホットパスデータ」と逆にアクセス頻度も使用頻度も低い「コールドパスデータ」のクエリ処理ができるうえ、処理済みのデータを取り扱うことも可能です。

• 分析とレポート

ビッグデータソリューションの多くの目的意義としては、「分析とレポート」によるデータ情報の実用的提供にあります。
Power BIやExcel内のモデリングテクノロジや視覚化テクノロジを活用して、セルフBIのサポートができる上、「Azure Analysis Services」という利用者によるデータ分析支援プラットフォームによる多次元OLAPキューブなどをアーキテクチャに組むことができます。

• オーケストレーション

「オーケストレーションテクノロジ」として、ビッグデータソリューションでは、「Azure Data Factory」や「Sqoop」などが使用できます。このテクノロジを用いることで、ソースデータの変換や複数データソースとシンク間でのデータ移行、処理したデータを分析データストアに読み込ませるなどの、ワークフローを「自動化」することができます。

3.Lambdaアーキテクチャー

分析用のデータ基盤には、「大容量のデータを迅速に処理する」ことが求められます。その目的として用いられる設計概念が「Lambdaアーキテクチャー」と呼ばれるものです。
「Lambdaアーキテクチャー」は、2012年Apache Storm の作者であるNathan Marz氏が提唱したもので「バッチレイヤー」「スピードレイヤー」「サービスレイヤー」の3層構造から成り立つデータ基盤の拡張性や保守性を実現する設計概念になります。
構造の軸となる各レイヤーに関しては以下の通りとなっています。

• バッチレイヤー

主に過去のデータを取り扱うことが多く、生データの保持からデータの加工やデータの集計処理などを実行します。この処理の結果を「バッチビュー」として保存します。

• サービスレイヤー

バッチレイヤーで処理された処理結果の「バッチビュー」をクライアント先に提供します。このビューは「BIツール」「SQL」で参照することが可能なデータとなります。

• スピードレイヤー

リアルタイムで送信されてくるデータを一時的に保持したり、リアルタイムでデータ分析を行います。リアルタイムで処理・分析を行うため、精度と引き換えに待機時間の短縮を目的として設計され、直近数秒、数分、数十分のイベントの「ストリーミングデータ」を扱います。

「スピードレイヤー」が扱う「ストリーミングデータ」とは、急速に生成され絶えずに流れ出る特徴を持っているデータを言います。身近な例でいうならば、「Twitter」や「Facebook」などSNSのデータです。これらはタイムライン上に絶えず流れ出る「ツイート」や「リツイート」などがストリーミングデータです。
このようなストリーミングデータと従来のデータ基盤を得意とする「バッチ処理」の組み合わせた分析方法ができるのが「Lambdaアーキテクチャー」です。
一方で「Lambdaアーキテクチャー」は一見便利そうに見えますが、その構造は「複雑」なモノです。処理ロジックは異なるフレームワークを使用して2つの異なる場所に出現します。その結果、計算ロジックが重複を起こして両方のアーキテクチャー管理が「複雑」ゆえに「欠点」となります。

4.Kappaアーキテクチャ

「Kappaアーキテクチャー」とは、基本的な目標は「Lambdaアーキテクチャー」と同じですが、大きな違いとなるのは「ストリーム処理システムを使用して、すべてのデータが単一のパスを経由する」点が「Lambdaアーキテクチャー」と「Kappaアーキテクチャー」の大きな違いです。
「Kappaアーキテクチャー」の利用目的としては、リアルタイムのデータ処理と連続的な再処理の両方を単一のストリーム処理エンジンで対応すること、つまりは「再処理=ストリームからの発生」となります。そのため、受信データイトリームを丸ごと、或いは特定の一から再生することが必要となります。
仮にコードの変更があった場合、2番目のストリームプロセスが最新のリアルタイムエンジンを介して、以前のデータすべてを再生して、サービングレイヤーに格納されているデータを書き換えます。

4.まとめ

クラウドサービスが現代ビジネスに浸透していく中で、アプリケーションの設計から実装、セキュリティ保護の方法とあらゆる面でオンプレミス環境とは異なるため、変化し続けいます。
「アーキテクチャ」は、アプリケーションを「設計」していく中で、どのような用途に合わせて作成していくかの「構造化されたアプローチ」になります。作成は、スタイル、テクノロジ、設計、ソフトウェアの品質、設計パターンの順にいきますが、スタイルを決める前に、「要件の明確化」をしておかなければ、後になって一からリスタートすることになりますので、ご注意ください。