Middleware チャンネル


前回はデジタル変革におけるアジャイル・インテグレーションという考え方の重要性をお伝えしました。

多くの技術書やブログでは、APIやマイクロサービスについてのパターン化や考え方について技術的観点で述べられていますが、今回はビジネスニーズからくる実際の適用シナリオの観点で整理してみたいと思います。今回は以下のように6つのシナリオに分けてみました。

シナリオA:アプリケーションのマイクロサービス化

これまでの多くのアプリケーションは、ビジネスロジックとユーザーインターフェース(画面)がセットで開発されていたため、ビジネスロジックを別の用途で再利用しようという発想に基づいた設計はされていませんでした。PCやタブレット上のブラウザだけで使う時代は良かったのですが、最近ではAmazon Echoのような非接触型のデバイスとつなげたり、他社アプリケーションからつなぎたいなどニーズは多様化しています。

このようにオムニチャネル化のニーズに対応するためには、ユーザーインターフェースとビジネスロジックを分離し、ビジネスロジックをマイクロサービスとして再利用可能にすることが求められます。その際、中間にAPIを作ることで、ユーザーインターフェースに対応した柔軟な連携が可能になります。(この考え方は、Backend For Frontend(BFF)パターンとも呼ばれています。)

シナリオB:レガシー機能のマイクロサービス化

レガシーシステムはますます硬直化し、パフォーマンスが悪い、機能拡張できないなどのクレームは日常的なものになっています。しかし重要なデータはレガシーシステムにあるので、業務プロセスを改善したり、顧客サービスを向上させるためには、これらを有効活用した新しいアプリケーションを作る必要があります。レガシーシステムは長年かけて成長しており、一朝一夕には刷新できません。そこで考えられるのが段階的なマイクロサービス化です。

初めはレガシー機能をそのまま利用しつつ、汎用的なAPIを作ることで外部アプリケーションから利用しやすくします(下図のAPI-A, API-Bのイメージ)。次に、切り出しやすい共通機能はマイクロサービスとして外出しにします(下図のAPI-Cのイメージ)。例えば認証機能や通知機能などは、外出しにするマイクロサービスとしては取り掛かりやすい機能です。(これらの考え方は、マイクロサービスの世界では、ストラングラーパターンと呼ばれています。)

シナリオC:リアルタイムサービス化

顧客向けのサービスは高度化が進んでおり、タイムリーに気持ち良くサービスが受けられないと、顧客はすぐに離れて別のサービスを選んでしまいます。アプリケーションはよりリアルタイム性が重要視され、かつ顧客の嗜好に合わせたパーソナル化も必要となってきています。例えば、顧客の選択した商品の在庫をリアルタイムにチェックし、かつ人気のある商品も合わせてレコメンドするような仕組みを柔軟に作ることが求められるのです。このようなアプリケーションは機能ごとにマイクロサービス化し、内部API同士をつなぎ合わせて機能を提供する方式が適しています。下図のAPI-GWのように、個別APIをまとめるAPIゲートウェイを作ることでアプリ開発を効率化する手法も取られます。

シナリオD:メッセージングによるデータ連携

業務プロセスで発生するデータは、限りなくリアルタイムに見られることが望ましいのは言うまでもありませんが、ITの制約により実現できていない企業は多くあります。例えばファイルに1日分のデータをためて販売情報を本社DBに送信するという業務プロセスでは、現時点での正確な販売状況を把握することはできません。そのようなシステムでは、購入したお客様の希望に応じて受け取り先や時間を指定するといった、きめ細やかなサービスなどは実現できません。

メッセージングの仕組みを使った、(半)リアルタイム連携は古くから用いられる手法ですが、サービス間のデータをメッセージとして連携することで、サービスの依存関係を疎結合にしながら柔軟に接続することが可能になります。

シナリオE外部サービス機能の統合化

インターネットが成熟した今では、外部サービスのネットワーク的な場所の違いは全く感じることがないぐらい、スムーズに繋げるられようになりました。  コンシューマー系では、地図情報サービス等がありとあらゆるアプリケーションに浸透していますが、最近では企業向けでも、 経費精算サービス、名刺管理サービスなど外部サービスを自社の業務プロセスに取り込む動きが活発になっています。この場合も、内部サービスと外部サービスの連携にAPIゲートウェイを設けることで、プロトコルやデータフォーマットの変換を行いながら連携し、ユーザーに継ぎ目を意識させないアプリケーションを構築することができます。

シナリオF社内システム連携のAPI

企業が成長するにつれ、社内システムの連携は混沌としてきます。ファイル渡しでバッチ的にデータを交換したり、データベースを直接参照し合っていたり、特殊なプロトコルで連携したりするため、依存関係を把握することも至難の技となっています。

そこで各システムの機能をAPIとして公開し、システム連携はAPIを通じてのみ許可するというルールを作ることで、企業システムをより強固にし、ビジネスの変化にも俊敏に対応していくシステムアーキテクチャを検討する必要が出てきます。(シナリオAとシナリオBの発展系と捉えることもできるでしょう。)

アマゾンがいち早くこのAPI戦略を取り入れ、API以外のシステム連携を徹底して排除した話は有名です。それによりアマゾンの商品管理、在庫管理、物流管理などのコアビジネスが強化され、その後どのように成功していったかは、ここで伝えるまでもありません。

シナリオG自社機能のオープンAPI

ここまで述べた取り組みが進んでいくと、自社機能を外部サービスにすることで、新しいビジネスモデルを開拓したいという要求が出てくるのは間違いありません。これまでもSaaSという形でサービス化する流れはありましたが、これからはビジネス機能をAPIとして公開することで、IoTデバイスやアプリケーションでも簡単に接続できるような新しい連携が生まれ始めています。

また、これまで培ったコアビジネスのノウハウはデータ分析サービスとして新たなビジネスチャンスとなっています。これらのAPIを公開することでさらにさまざまなチャネルからのデータが集まり、より優位性のあるノウハウサービスを生み出せる可能性も秘めています。

いかがでしたでしょうか?

このように整理してみると、自社のビジネスニーズとマッチしたシステム連携のあり方が見えてくるのではないでしょうか?

次回からは、いよいよ本題のAPIやマイクロサービスやコンテナについて掘り下げていきたいと思います。

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

RED HAT JBOSS MIDDLEWARE

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

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