アジャイル・インテグレーションの リファレンス・アーキテクチャー
この投稿はあくまでも著者による個人の意見であり、Red Hatによる見解ではありません。
現在のインテグレーションは、今までとは異る形で存在しています。 近代的なインテグレーションとはどういったものでしょうか？ 従来のウォータフォール開発が、どのように スクラム開発(アジャイル)へ置き換わったのかを考えてみると、短期リリースサイクルの実現や、フィードバックの早期反映、変更への柔軟な対応を可能にする為であったと言えます。 同じように従来のインテグレーションは、アジャイルへ置き換わるべきだと私は信じます。従来の ESB を分散型のマイクロサービスへ解体する事で、アジャイルを実現します。
アジャイル・インテグレーションに必要な要素を簡単におさらいします:
- 分散型・インテグレーション
- 軽量で、分散配備に対応
- パターンベースのインテグレーション
- 再利用可能なコネクター
- マイクロサービス
- コンテナ
- クラウド・ネイティブ
- リーンな成果物であり、個別に配備可能
- コンテナベースでスケーリングや高可用性に対応
- API
- よく定義され再利用可能であり、よく管理されたエンドポイント
- エコシステムの活用
そう、これが アジャイル・インテグレーションのリファレンス・アーキテクチャーです! ソフトウェア プロジェクトの設計段階では、リファレンス・アーキテクチャがしばしば必要になります。リファレンス・アーキテクチャーは、ソフトウェア プロジェクトの構造とバックボーンを提供します。一旦それら設計フェーズの終了が意味するものは、切り戻しできない完全なコミットであったりします。アーキテクチャ上の変更は困難であり、悲惨な結果をもたらす可能性があるからです。私たちは皆、「ソフトウェア開発において、変わらない事は、いつまでたっても変わらない」ことを知っています。おそらく、規制要件、市場要求、または、よりビジネス ドメインに関する学習に、ウェイトを置いている為かもしれません。そこで私は、変化に対して柔軟性のあるアーキテクチャを構築し、必要に応じてプロジェクトの要求に適応することができるかを考え始めました。これは、前述したコンセプトに基づいた、アジャイル・インテグレーションのリファレンス・アーキテクチャーです。即ち、多面的な柔軟性を可能にする先進的なインテグレーション・アプリケーション開発のアーキテクチャーです。
PaaS - 自動化されたプロビジョニングを可能にするだけでなく、開発者に対してセルフサービスを可能にすることで、迅速なソフトウェア開発を提供するインフラ基盤です。また、システム環境全体が DevOps 対応になるので、運用効率を向上させます。
セキュリティ/アイデンティティ管理(IAM) - アプリケーション・インターフェースとプラットフォームの、基本的な認証/認可を処理します。
自動化 - アプリケーションのビルド処理に関するプロセスと、アップグレードの為のローリング・デプロイメント戦略の両方を自動化します。CIツール(継続的インテグレーションツール)とあわせて、アプリケーション・ソフトウェアの継続的な提供が可能になります。
ログとトレース - モノシリックな世界では簡単なものが、分散マイクロサービスアーキテクチャにおける課題の1つになっています。どのように処理されているか一元的に把握することが難しくなった為です。ログ全体を確認できる手段や、様々なアクティビティをトレースできる機能を提供することが重要です。
コンテナ化されたパッケージ - コンテナ技術は、プログラム言語に依存しない、不変のポータブルな軽量アプリケーションパッケージを構築することを可能にします。このビルドパッケージと設定は独立しているので、同じパッケージを複数の異る環境に素早く配備することができます。
コンテナ管理 - 大規模システムでは、アプリケーションを実行するすべてのコンテナを管理するための、便利な管理プラットフォームが不可欠です。実行中のコンテナに対して、監視、検出、回復、フェイルオーバーを実行します。
マイクロサービス - 大規模なアプリケーション/サービスを、メンテナンスの用意なピースに分割します。個々のピースはそれぞれ独立して開発され、分散環境に配備されます。それぞれのピースは、障害を考慮して構築される必要があります。
ロードバランス/サービス・ディスカバリー/ネットワーク管理 - マイクロサービスは、柔軟性を考慮して構築されています。よって、システムの負荷に応じて、自動的に負荷をそれぞれ稼働中のインスタンスへ分散する必要があります。すべてのサービスは登録され、複雑な設定をせずにシステム内で確認できる必要があります。外部ユーザーから配備の複雑さを隠蔽する為に、プロキシーエンドポイントであることが理想的です。
階層化アーキテクチャー - マイクロサービスを論理的に、複数レイヤー層で構成してみます。それぞれのレイヤーは、他のレイヤーと重複しない独自の責務を持つようデザインし、後々個々のレイヤーで変更しやすくしています。結果、4つのレイヤーになりました:
- ゲートウェイ レイヤー - バージョン管理などの簡単なゲートウェイ・ルーティング機能を提供し、様々なプラットフォームデバイスに対応可能です。
- コンポジット レイヤー - 複数マイクロサービス群を処理する重要な中間層です。中間層では、コンテンツのデータ自体の処理からより複雑なルーティングを行い、時にはデータの集約や正規化を実施します。
- ベース レイヤー - 名前の意味するように、システムの基本的なコンポーネントを示します。データ検索や、ビジネスロジックを処理します。
- 腐敗防止レイヤー - このレイヤーは、レガシーアプリケーションや、俊敏性で柔軟性のあるマイクロサービスの原理に反する処理へのインターフェースを提供します。このレイヤーは、防御壁としてあなたのシステムに組み込まれています。実装の非常に異る2つのシステム間で、ジョブの変換や翻訳を実施します。
API 管理 - 強化されたアクセスポリシーの利用や、使用状況の統計情報を収集し、APIを管理します。また、API開発者とユーザーの間に、健全なエコシステムを構築します。さらに、APIの使用自体を収入源にすることが可能になります。
今日の技術では、完全に柔軟なアーキテクチャを実現するうえで、いくつかの制限があります。しかし、このモデルを使うことで、システムに変更が発生した時でも、大きな影響を与えない柔軟性をもたらすことができると私は信じています。詳細については、今後の記事で紹介します。
"Red Hat Developer Program"(無料)に参加し、関連するチートシートや、書籍、製品ダウンロードサイトにアクセスしてください。
Red Hat OpenShiftおよびその他の関連トピックについては、OpenShift、OpenShift Onlineをご参照してください。
原文: Reference Architecture for Agile Integration By Christina Lin July 27, 2017
0 件のコメント:
コメントを投稿