「apps gateway」はひとことで言うと「取次窓口」
最初にお断りしておくと、apps gatewayという言葉は、製品によって指すものが少しずつ違います。ただ共通しているのは、複数のアプリと外側の世界のあいだに立って、やりとりを一か所にまとめる仕組みという点です。「ゲートウェイ(gateway)」は英語で「門」「出入口」のこと。つまり「アプリ群への出入口」ですね。
身近な例えで言うと、大きなオフィスビルの受付カウンターがいちばん近いと思います。ビルの中には何十社ものテナント(=アプリ)が入っていますが、訪問者は各社の部屋を直接ノックして回るわけではありません。まず1階の受付に行って、「○○社の△△さんに会いに来ました」と伝える。受付は身分証を確認し、入館証を発行し、適切なフロアへ案内してくれます。
この受付がやっていることを分解すると、だいたいこうなります。
- 入口を一つにする — 訪問者はビルの住所さえ知っていればいい
- 本人確認をする — 怪しい人を中に入れない
- 取り次ぐ — 用件に応じて正しいテナントに回す
- 記録を残す — 誰がいつ来たかを台帳に書く
ソフトウェアの世界の「apps gateway」も、やっていることはほぼ同じです。外部からのリクエストを一手に受け、認証をして、裏側にある各アプリへ振り分ける。
なぜわざわざ窓口を置くのか
「アプリに直接つなげばいいじゃないか」と思うかもしれません。正直、アプリが1つか2つのうちはその通りです。面倒が増えるだけなので、無理に窓口を作る必要はありません。
問題は数が増えてきたときです。アプリが10個あって、それぞれが独自に「ログイン画面」「アクセス権のチェック」「ログの記録」を実装していたら、どうなるか。
窓口なし(直接つなぐ)
アプリごとに接続先が違う。認証の仕組みも10個分バラバラ。1つのアプリでセキュリティ上の修正が必要になったら、残り9個も同じ漏れがないか全部点検することになります。
窓口あり(gateway経由)
利用側は窓口の場所だけ知っていればいい。認証やログは窓口が一括で担当。直すときも窓口を直せば全体に効きます。
ビルの受付が1階にまとまっているから、セキュリティ方針を変えたいときに受付のルールだけ変えればいい、という話とまったく同じ構図ですね。
リクエストが流れていく順番
利用者から見た流れを図にすると、こんな感じになります。
ポイントは、利用者は裏側に何個のアプリがあるかを意識しなくていいということ。アプリが増えても減っても、窓口の住所は変わりません。引っ越しが起きても受付が新しいフロアを案内してくれるので、訪問者は何も知らずに済む。これがゲートウェイのありがたさです。
つまずきやすいところ
便利な一方で、初めて触るときに引っかかりやすい点がいくつかあります。
ひとつは、うまくつながらないときに原因の切り分けが面倒になること。「アプリが落ちている」のか「ゲートウェイの振り分け設定が間違っている」のか「認証ではじかれている」のか、エラーメッセージだけだと判別しづらい場面があります。層が1枚増えたぶん、疑う場所も1つ増えるわけです。
もうひとつは、窓口が止まると全部止まるという点。ビルの受付が閉まっていたら、どのテナントにも入れませんよね。一か所にまとめるメリットの裏返しとして、そこが弱点にもなります。
とはいえ、これらは「気をつけて設計すれば済む」話で、アプリの数が増えてきたときの管理のしやすさを考えると、窓口を置くメリットのほうが大きくなる場面が多いです。
覚えておきたいこと
専門用語としての厳密な定義を暗記するより、「アプリ群の前に立って、受け付けて、確認して、取り次ぐ役」というイメージを持っておくほうが実用的です。実際に目の前の製品でapps gatewayという名前を見かけたら、「ああ、ここが入口なんだな」と当たりをつけて、そのドキュメントで具体的に何を担当しているかを確認すればいい。言葉の役割さえ掴んでおけば、細部は読めば分かります。
このページは役に立ちましたか?