Middleware チャンネル


10月20日(金)に東京恵比寿で開催された「Red Hat Forum 2017」のブレークアウトセッションにおいて、『変化に適応していくためのアプリケーション基盤』というタイトルで講演させて頂いた、レッドハット テクニカルセールス本部 シニアソリューションアーキテクトの杉本です。今回のコラムでは、その時にお伝えした内容をあらためてご紹介したいと思います。

 

講演では特にインテグレーションにフォーカスをし、どのようにすればアジャイルなインテグレーションを実現できるのか、そしてそのためのアプリケーション基盤のリファレンスアーキテクチャはどうあるべきなのか、についてデモを交えてご紹介しました。

テクノロジーが変化し、その変化のペースも年々速くなり、そして異業種からのディスラプターが突然現れてくるような現在のビジネス状況において、アジリティは最も重要な要素の1つとなっています。システムをインテグレーションする上でもアジリティが求められ、複雑化する社内システムを連携したり、社内システムとパブリッククラウドやSaaSアプリケーションを連携したり、あるいはデジタルマーケティングの観点から既存のIT資産や蓄積したデータを活用してモバイルやIoTなどのオムニチャネルへ対応していく、といったこともアジャイルに行うことが必要とされています。そういった変化やニーズに迅速に対応していくためには変化に柔軟に対応できるアプリケーション基盤が必要であり、それによりデジタル変革を推進し、企業の競争力を強化することにもつながります。

アジャイルAPIインテグレーション

アジャイルAPIインテグレーション(あるいはアジャイルインテグレーションと言うこともあります)というのはRed Hatが作ったキーワードですが、アプリケーション基盤に柔軟性をもたらすためのアプローチです。あえて定義をすると

異なるシステムやサービスにまたがるアプリケーションや
データをより早く柔軟に連携できるように、
アジャイル開発の方法論とテクノロジーを組み合わせて
柔軟なアプリケーション基盤のアーキテクチャを
設計するためのアプローチ

と定義することができます。

そのアジャイルAPIインテグレーションを実現するための技術要素 として、具体的には以下の図のように「分散インテグレーション」「コンテナ」「API」の3つの柱 があります。

3 pillars of Agile API Integration

もちろんこれら3つの技術要素に加えて、アジリティを実現するためにはDevOpsのような開発アプローチを取り入れることも重要ですが、ここでは3つの柱についてご紹介したいと思います。

分散インテグレーション

分散インテグレーションというのは、従来のESBのように真ん中に置かれた大きな1つのバス経由で連携させるのではなく、マイクロサービスをベースとしたより軽量なインテグレーションのやり方を実現するものです。

少し遡って、従来のインテグレーションのアプローチを考えてみましょう。10年ほど前、SOAの考え方が出てくる以前の企業内のアプリケーションを連携する方法としては、基本的にはPoint-to-Pointでアプリケーション同士を直接連携させるのが一般的でした。ただそれでは連携のために開発コストがかかったり、再利用性がなかったり、連携が可視化できない、といった点が問題となり、それを解決するための手段として出てきたのがESBです。

 

すべてESBを経由して連携させるというアプローチで、SOAPのWebサービスを使い、データやプロトコルの変換を行い、場合によってはBPELのようなステートフルなビジネスプロセスの管理を行うということも行われていました。ただその結果、ESBが重厚長大なモノリシックなシステムとなり、インテグレーションから柔軟性やアジリティが失われてしまったというのが現実です。

そういった背景もあり、ESBやSOAPベースのWebサービスで連携させるのではなく、アプリケーションはマイクロサービスとして実装し、そのマイクロサービスをより軽量なREST APIで連携させるという方式が広まってきています。動画配信のNetflixは自社内のシステムをマイクロサービスベースでアーキテクチャの設計を行うことによってアジリティを実現しており、その成果をオープンソースとして公開しています。ただ、マイクロサービスをベースとしてアーキテクチャ設計を行う場合も連携のやり方には注意が必要です。先程のSOA以前と同じようなアプローチで、マイクロサービス同士をPoint-to-Pointで直接連携させていってしまうと、何と何がつながっているのかが分からなくなり、再利用性や柔軟性が失われることになってしまいます。

Integrating microservices

その課題に対するソリューションとして出てきたのがAPIゲートウェイであり、マイクロサービスのアーキテクチャパターンとしてもよく使われている方式です。ただこのAPIゲートウェイの使い方も注意が必要であり、製品に機能があるからといって、APIゲートウェイでビジネスロジックに関わるようなルーティングやデータ変換のような処理を行ってしまうと、APIゲートウェイがESBと同じにようにモノリシックで重厚長大なシステムになってしまい、それがボトルネックとなりアジリティや柔軟性が失われることになってしまいます。

API Gateway Pattern

ですので、アプリケーション基盤全体を見渡した上で、APIゲートウェイもその使い方・役割を考える必要があります。

アジャイルAPIインテグレーションの1つ目の柱である分散インテグレーションは、そのようなESBの時に出てきた課題を教訓として考えられているアプローチです。マイクロサービスをベースとし、基本的にはREST APIによるステートレスでシンプルな連携を前提としており、システムの関連性を可視化することやパフォーマンスとスケーラビリティを向上させるためにイベントベースで疎結合な連携パターンを組み合わせることを重視しています。また、SOAでは企業全体での標準データモデル(カノニカルデータモデル)を定義しようとして上手くいかないケースが多くありましたが、アジャイルAPIインテグレーションのアプローチでは、マイクロサービスを適切な粒度で実装していくためにも、ドメイン駆動設計のアプローチで、業務を抽象化したドメインモデルを用いて開発することが効果的であると考えています。

コンテナ

2つ目の柱であるコンテナについては、あらためて説明するまでもないかもしれませんが、依存関係のあるモジュールも含めて、アプリケーションに必要なものをコンテナとしてパッケージングでき、環境に依存せず、軽量かつデプロイも極めて簡単にできるようになったという点が特徴として挙げられます。分散インテグレーションの機能もマイクロサービスとして実装し、コンテナとしてパッケージングすることでそれぞれが独立してデプロイ可能になります。

そしてそのコンテナを管理するためのプラットフォームは、スケーラビリティや高可用性を担保するという重要な役割を持っています。またそれだけではなく、CI/CDのパイプラインを実行し、DevOpsを実践するためのプラットフォームとしての重要な役割も担っています。開発環境から本番環境まで、テスト済みのコンテナイメージを展開する”Immutable Delivery”を実現することができ、より効率的にDevOpsを実践ができるようになります。

 

Immutable Delivery

インテグレーションの観点で見ると、従来ESBで連携しようとすると専門のチームが連携ロジックを開発してデプロイすることが必要でしたが、アジャイルAPIインテグレーションのアプローチでは、分散インテグレーションのためのマイクロサービスをコンテナ化し、各環境にデプロイするプロセスをCI/CDのパイプラインに組み込んで、各チームでアジャイルに開発ができるようになるという点もESBによる連携とは異なります。

また、コンテナ管理プラットフォームを使うことにより、本番環境へのデプロイメントも柔軟に行えるようになります。例えば、ブルーグリーン デプロイメントという方式では2つの環境を用意してデプロイが完了したら新しい環境にスイッチすることで、ダウンタイムを短縮し、トラブル発生のリスクを回避することができるようになり、仮に問題が見つかってもすぐにロールバックできるため、安全に新しいバージョンに切り替えられるようになります。

Blue-Green Deployment

さらに、A/Bテストあるいはカナリアリリースのデプロイメント方式を使い、何か新機能を試す時にいきなり全ユーザーに公開するのではなく、一部のユーザーにのみ新機能を利用してもらい、テストを実施して新バージョンで問題ないと判断できた時点で100%新バージョンに切り替える、といったデプロイメントを行うことも可能です。

A/B Testing (Canary Release)

このような柔軟性も、コンテナという技術要素があるからこそ簡単に実現できるのです。

API

アジャイルAPIインテグレーションの3つ目の柱はAPIです。マイクロサービスとして実装し、それをAPIでアクセス可能にしていきます。その時に重要となってくるのが、Open API Specification(Swagger)のように広く使われているAPI記述言語を使用してAPIの仕様を公開し、その利用者にAPIの仕様や使い方などの情報を提供していくことです。マイクロサービスもAPIも作って終わりではなく、利用してもらうことによって初めて価値が生まれます。またAPIの再利用が促進されることによって開発生産性を上げ、アプリケーションの開発コスト削減だけでなく、より早いリリースサイクルの実現が可能となります。マイクロサービスとして実装された社内のシステムをAPIで連携させることでインテグレーションのアジリティが向上し、さらにそのAPIをパートナーや外部のデベロッパーに公開してエコシステムができれば、企業としてより競争力を高めることにも繋がります。そういう意味で、APIの開発というのは言ってみれば氷山の一角であり、作ったAPIをどう管理・活用していくか、という点が重要になるのです。

API Management

APIを管理するという観点では、そもそもどういったAPIを提供していくべきか?そのAPIをどうセキュアにするのか?あるいは、APIが使いやすいようにデベロッパーにどう情報を提供していくのか?そしてそのAPIを誰がどれくらい使っているのか、どのようにモニタリングをして、分析していくのか?どう課金していくのか?といったことをAPI管理として考えていく必要があり、それを効率的に実現するためにはAPI管理基盤が必要になってきます。

 

Red Hatでは、このアジャイルAPIインテグレーションの3つの柱それぞれに対応した製品として、”Red Hat JBoss Fuse”、“Red Hat OpenShift Container Platform”、”Red Hat 3scale API Management Platform”を提供しています。

 

Red Hat Products for Agile API Integration

 

Red Hat JBoss FuseはApache CamelとActiveMQをベースとしており、軽量コンテナで容易にREST APIを構築することができ、150種類以上の接続アダプターとエンタープライズ統合パターンを組み合わせて柔軟な分散インテグレーションのためのマイクロサービスを実装することができます。

Red Hat OpenShfit Container Platformは、DockerとKubernetesをベースとしたコンテナ管理のためのプラットフォームであり、スケーラビリティと可用性だけでなく、CI/CDのパイプラインを実行し、DevOpsを実践するためのプラットフォームです。

3scale API Management PlatformはNGINXをベースとしたAPI管理プラットフォームであり、セキュリティや流量制限、デベロッパーポータルなどのAPI管理に必要な機能を網羅し、パフォーマンスとスケーラビリティにも非常に優れた製品です。

 

これらの製品を使うことで、アジャイルAPIインテグレーションに求められる機能を実現できるようになります。

次回は、アジャイルAPIインテグレーションのリファレンスアーキテクチャについてご紹介していきたいと思います。

 

レッドハット・エバンジェリスト・プロフィール

RED HAT JBOSS MIDDLEWARE

Red Hat JBoss Middleware エバンジェリストチーム

レッドハットを代表するRed Hat JBoss Middlewareの精鋭エバンジェリストたちが、JBossの魅力を余すところなくご紹介します。
詳細はこちら »