API Gatewayとは？基本概念をわかりやすく解説

API Gatewayの基本概念

API Gateway（エーピーアイ・ゲートウェイ）と聞いて、最初は「なんだか難しそう」と身構えてしまうかもしれません。実は僕も最初はそうでした。でも、一度核心を押さえてしまえば、「あ、確かにそういうものが必要だよね」とすんなり理解できる仕組みです。

一言で表すなら、API Gatewayは「クライアントとバックエンドサービスの間に立つ、入り口を一本化する受付係」です。

クライアントとバックエンドの「入口」を一本化する仕組み

具体的な例を考えてみましょう。あなたがECサイトを作っているとします。ユーザーが商品を買うには、「商品情報を取得するAPI」「在庫を確認するAPI」「決済を処理するAPI」など、様々なバックエンドサービスと通信する必要があります。

API Gatewayがない場合、スマホアプリやWebブラウザ（クライアント）は、これらすべてのサービスのURLを直接知っておかなければなりません。例えば、https://api.example.com/products や https://api.example.com/payments のように、目的に応じてリクエスト先を切り替える必要があります。サービスが3つならまだ良いですが、これが10個、20個と増えていくと、クライアント側の管理はすぐに限界を迎えてしまいます。

ここでAPI Gatewayを導入するとどうなるでしょうか。 クライアントは、たった1つのURL（例：https://api.example.com）にリクエストを送るだけになります。後はAPI Gatewayが、送られてきたリクエストの内容を見て「これは商品に関する問い合わせだから、商品サービスに回そう」「これは決済だから、決済サービスに回そう」と、適切なバックエンドへ振り分けてくれます。

このように、内部の複雑な構成をクライアントから隠蔽し、シンプルなアクセス方法を提供するのがAPI Gatewayの基本的な役割です。

なぜAPI Gatewayが注目されているのか（歴史的背景と課題）

「API Gateway」という言葉を最近よく耳にするようになりましたよね。クラウドやマイクロサービスの文脈で必ずと言っていいほど登場するのですが、なぜこれほどまでに注目を集めているのでしょうか。それを理解するには、システムアーキテクチャがたどってきた歴史を少し遡ってみるのが一番わかりやすいんです。

ここでは、API Gatewayが生まれる前のシステムが抱えていた「壁」と、マイクロサービス化によって生じた新たな課題についてお話しします。

モノリシックアーキテクチャの限界とスケーリングの壁

かつて、ほとんどのシステムは「モノリシックアーキテクチャ」と呼ばれる構成で作られていました。モノリスとは「一枚岩」という意味で、ユーザー管理、商品検索、決済、通知といったすべての機能が、ひとつの大きなプログラムとしてまとまっている状態のことです。

システムを作りたての頃は、この一枚岩の構成はとても扱いやすいです。開発メンバーも少なければ、動作確認もデプロイ（プログラムを実際のサーバーに反映させる作業）もシンプルで済みます。しかし、サービスが成長して機能が増えてくると、大きな壁にぶつかるようになります。

例えば、ECサイトを運営していて「商品検索のちょっとしたバグを直したい」としましょう。モノリス構成だと、商品検索の部分だけをピンポイントで直して公開するのが難しくなります。決済やユーザー管理など、関係のない他の機能も含めて、システム全体を一度に再起動してデプロイしなければなりません。せっかく直した検索機能が、万が一決済機能の再起動に失敗して影響を受けるかもしれません。これが、「一部の変更が全体のデプロイに影響を及ぼす」という課題です。

もう一つ深刻なのが「スケーリングの壁」です。スケーリングとは、アクセスが増えたときに処理能力を上げることを指します。年末のセールで「決済機能」だけアクセスが集中したとします。本来なら決済機能のサーバーだけ増やせばいいのですが、モノリスではすべての機能がくっついているため、使われていない商品検索や通知機能のサーバーまで丸ごと増やさないといけません。結果的に、余分なサーバー費用がかかってしまい、リソースの無駄遣いになってしまうんです。

クライアントとサーバーが直接通信する設計のデメリット

モノリスの限界を乗り越えるために、システムをマイクロサービスに分割したとします。すると今度は、別の問題が顔を出します。それは「クライアント（スマホアプリやWebブラウザ）と、バックエンドの各サービスが直接通信すること」自体がとても大変だということです。

モノリスの頃は、クライアントは「https://api.example.com」というたった1つの入口（URL）にリクエストを送るだけでよかったです。しかし、マイクロサービスに分割すると、「https://api.example.com/user（ユーザー情報）」「https://api.example.com/product（商品情報）」「https://api.example.com/payment（決済）」のように、URLがバラバラになります。

ここで新しく「ポイント機能」というサービスが追加されたらどうなるでしょうか。スマホアプリ側のプログラムを修正して、新しいURLを追加しなければなりません。サービスが増えたり、URLのデザインルールが変わったりするたびに、アプリのアップデートをユーザーに強いることになってしまいます。これは運用面で大きなデメリットです。

さらに厄介なのが「セキュリティ」の問題です。たとえば「この人は正しくログインしているかな？」「この人は決済をする権限があるかな？」といった認証・認可のチェックは、すべてのサービスで必要です。直接通信の設計だと、ユーザーサービスでも商品サービスでも、それぞれが個別に同じような認証処理を実装しなければなりません。10個のサービスがあったら10回同じコードを書いて、10回テストをする。これは非常に非効率ですし、どこかの実装を忘れてセキュリティホールになるリスクも高まります。

このように、システムを成長させるための分割が、今度は別の複雑さを生み出してしまいました。API Gatewayは、この「分割されたサービスの複雑さ」をクライアントから隠し、スマートに繋ぐための解決策として、現在非常に強く求められているのです。

API Gatewayが担う具体的な役割と仕組み

前のセクションでは、API Gatewayがなぜ生まれてきたのかという背景をお話ししました。ここからは少し具体的に、「この門番さんは実際に何をしてくれているのか」を解説していきます。

API Gatewayの役割は、単に「リクエストを別のサーバーに渡すだけ」ではありません。いくつかの重要な仕事をまとめて担ってくれています。

リクエストのルーティングと負荷分散

API Gatewayの最も基本的かつ重要な役割が、ルーティングです。

クライアントから送られてきたリクエストは、ただの一つの塊に見えますが、実はそれぞれ異なる目的地を持っています。例えば、ユーザー情報が欲しいのか、商品一覧が欲しいのか、決済をしたいのかといった違いです。

API Gatewayは、リクエストの「URLのパス」や「HTTPメソッド（GETやPOSTなどの通信の種類）」を見て、それをどのバックエンドサービスに渡せばいいかを判断します。

具体的な例で見てみましょう。

• https://api.example.com/users にGETリクエストが来たら → ユーザー管理サービスへ
• https://api.example.com/orders にPOSTリクエストが来たら → 注文処理サービスへ
• https://api.example.com/products にGETリクエストが来たら → 商品管理サービスへ

このように振り分けることで、フロントエンド（スマホアプリやWebブラウザ）の開発者は、バックエンドの構成がどうなっているかをほとんど気にしなくて済むようになります。例えば、後から「商品管理サービスのサーバーを新しいものに切り替えたからドメインが変わった」というようなバックエンド側の都合による変更があっても、API Gateway側の設定だけを変えれば済むため、フロントエンドの修正は不要になります。

認証・認可の共通化とセキュリティの強化

Webサービスにおいて、「この人は本当に正規のユーザーなのか」「この人にこのデータを見せる権限はあるのか」を確認する作業（これを認証・認可と呼びます）は必須です。

もしAPI Gatewayがなかったら、バックエンドにある「ユーザー管理サービス」「注文サービス」「決済サービス」など、すべてのマイクロサービスが個別に認証機能を実装しなければなりません。これは開発者の大きな負担になるだけでなく、「一つのサービスで認証の実装にバグがあった」となれば、システム全体のセキュリティが崩れるリスクに直結します。

そこでAPI Gatewayの出番です。 認証・認可のチェックはすべてAPI Gatewayの段階で行うようにします。ログイン時に発行されたトークン（暗号化されたIDカードのようなもの）が正しいかどうかを、バックエンドにリクエストを渡す前に確認し、問題がなければ初めてバックエンドサービスへリクエストを通します。

これにより、バックエンドの各サービスは「来たリクエストはすでに正しい人からのものだ」と前提して処理に専念できるようになります。

レートリミットとトラフィックの制御

突然ですが、「1秒間に1万回のリクエストを送ってくるようなアクセス」があなたの作ったサービスに来たら、どうなるでしょうか？バックエンドのサーバーは処理しきれずにパンク（ダウン）してしまう可能性が高いです。

これは、悪意のある攻撃（DDoS攻撃など）によって引き起こされることもありますし、単にサービスがテレビで紹介されて予想外のアクセス集中（いわゆるバズ）が起きたことによるものかもしれません。

API Gatewayは、このような異常なトラフィックからシステムを守るための「流量調整弁」の役割を持ちます。これをレートリミットと呼びます。

例えば、「1つのユーザーIDにつき、1分間に100回までアクセスを許可する」といったルールを設定しておきます。100回を超えたリクエストに対しては、エラーメッセージを返してバックエンドには届かないようにブロックします。

データ変換（リクエスト/レスポンスの変換）とキャッシング

最後に紹介するのが、データの変換とキャッシングという機能です。

データ変換 クライアントが送ってくるデータの形式と、バックエンドのサービスが処理しやすいデータの形式が一致しないケースは意外と多いです。例えば、クライアントは「名前」と「苗字」を別々に送ってきたけれど、バックエンドの古いシステムは「フルネーム」で受け取りたい、といった場合です。API Gatewayが中間でデータの形を整えてからバックエンドに渡すことで、双方の都合に合わせる手間を省けます。

キャッシング 都道府県の一覧や、商品のカテゴリ一覧など、頻繁にアクセスされるけれど内容がなかなか変わらないデータがあります。こうしたデータをわざわざ毎回バックエンドのデータベースに取りに行くのは非効率です。

API Gatewayは、一度バックエンドから受け取ったデータを一時的に自分のメモリ内に保存（キャッシュ）しておくことができます。次に同じリクエストが来たら、バックエンドには問い合わせずに保存しておいたデータを即座に返却します。

これにより、バックエンドの負荷を下げるだけでなく、ユーザーが感じるレスポンスのスピードも劇的に向上させることができます。数値で言うと、データベースへの問い合わせに50ミリ秒かかっていたものが、キャッシュから返すことで5ミリ秒以下になるようなケースも珍しくありません。

API Gatewayを導入する3つの代表的なメリット

ここまでAPI Gatewayがどんな役割を担っているのかを見てきましたが、「結局のところ、導入すると現場のどんな悩みが解決されるの？」という点が一番気になりますよね。私自身、実際のプロジェクトでAPI Gatewayを導入してみて、「面倒ごとがぐっと減った」と実感したメリットがいくつかあります。その中でも特に大きかった3つのメリットについて、できるだけ具体的にお話しします。

フロントエンドとバックエンドの結合度を下げる

システム設計の世界では「疎結合（そけつごう）」という言葉がよく使われます。これは、部品同士の依存関係を薄くして、一方が変わっても另一方に影響が及ばないようにする考え方です。API Gatewayは、まさにこの疎結合を実現するための強力な盾になってくれます。

例えば、ECサイトを作っているとします。ユーザー情報を管理するサービスと、商品を管理するサービスがあったとき、Gatewayを使わない場合はフロントエンドからそれぞれのURL（https://api.example.com/users/... や https://api.example.com/products/...）を直接叩くことになります。

ここで、後から「商品管理は別のサーバーに移動して、URLを変えたい」となったらどうなるでしょうか。フロントエンドのプログラムを探し出して、URLを書き換えて、テストして、デプロイする……という手間が発生します。

しかし、API Gatewayを間に挟んでおけば、フロントエンドは常に「https://api.example.com/v1/products/...」というGatewayのURLだけを見ていればよくなります。裏側で商品サービスのURLがどう変わろうと、Gatewayの設定を書き換えるだけで済むのです。バックエンドがサービスを追加したり、分割したり、削除したりしても、フロントエンド側の設定変更は最小限で済みます。これが、システム全体の保守性と拡張性を大きく向上させるわけです。

横断的な処理を一元管理し開発を迅速化する

「横断的関心事（おうだんてきかんしんじ）」と聞くと難しく感じますが、要するに「どの機能を作るにしても、必ず別途必要になる共通の作業」のことです。具体的には、アクセスログの記録、通信の暗号化、認証チェック、エラーのフォーマット整備などがこれに当たります。

マイクロサービスの構成で、これらがどれほど大変か想像してみてください。もし10個のマイクロサービスがあった場合、ログの出力形式や認証の仕組みを「各サービスで個別に実装・設定」しなければなりません。「あ、こっちのサービスだけログの形式が違う」「新しいサービス作ったけど認証の設定忘れてた」といったミスも起きやすくなります。

API Gatewayを導入すると、これらの共通処理をGatewayの1箇所に集約できます。ログの設定を変えたければGatewayだけ直せばいいし、新しいマイクロサービスを追加したとしても、Gatewayのルーティング設定を追加するだけで自動的にログや認証が適用されます。

障害の影響範囲を局所化しシステムを安定させる

複数のサービスが連携するシステムにおいて、一番恐ろしいのは「一つのサービスのトラブルが、システム全体を連鎖的にダウンさせる」ことです。

たとえば、商品一覧を表示する画面で「商品データ」と「レビューデータ」を別々のサービスから取得しているとします。ここでレビューサービスのサーバーがダウンしてしまった場合、Gatewayを使っていなければ、画面が真っ白なエラー画面になってしまい、ユーザーは商品すら見られなくなってしまいます。

API Gatewayを導入していると、Gateway側で「レビューサービスからの応答が3秒なかったら、エラーにせず空のデータを返す」といった柔軟なエラーハンドリング（障害時の回避処理）を設定できます。これにより、「レビュー欄だけ『現在取得できません』と表示されるが、商品自体は問題なく買える」という状態を保つことができます。

このように、API Gatewayは単なる「通り道」ではなく、システム全体の安定性をコントロールする防波堤としての役割も果たしてくれます。

BFF（Backend For Frontend）とAPI Gatewayの明確な違い

ここまでAPI Gatewayがシステム全体を支える強力な「入口」であることを説明してきましたが、設計の文脈を調べていると、必ずと言っていいほど「BFF（Backend For Frontend）」という言葉にぶつかります。「結局、API GatewayとBFFは何が違うの？」と混乱されてしまう方も多いのですが、実はこの2つは明確に役割が異なります。

「システムの入口」と「フロントエンド専用の仲介役」の違い

一言で表すと、API Gatewayは「システム全体の汎用的な門番」であり、BFFは「特定の画面（フロントエンド）のためだけに用意された専属の仲介役」です。

API Gatewayは、Webブラウザであれ、スマホアプリであれ、外部の業務システムであれ、どんなクライアントが来ても同じように対応します。役割はあくまで「認証」「ルーティング」「通信制限」といったシステム全体の共通ルールの適用です。クライアントの種類によってレスポンスの中身を大きく変えたりはしません。

一方でBFFは、特定のフロントエンドに徹底的に最適化されたバックエンド層です。例えば、ECサイトの「商品一覧画面」を想像してみてください。PCの大きな画面では、商品画像、詳細なスペック、レビュー一覧、関連商品などを一度に表示したいですよね。でも、スマホアプリなら通信量を抑えるために、商品名、価格、サムネイル画像の3点だけで十分なことが多いです。

このように、同じ「商品を見る」という動作でも、クライアントによって必要なデータの量や形式が全く異なります。BFFは「スマホ用BFF」「PC用BFF」のようにフロントエンドごとに用意され、裏側にある複数のマイクロサービスから必要なデータだけを集め、その画面に最適な形に整形して返す役割を持ちます。

BFFパターンの基礎とAPI Gatewayとの共存アプローチ

では、この2つはどちらか片方を選んで使うものなのでしょうか？実は現場では、両者を組み合わせて使うアーキテクチャが主流になっています。

具体的な配置のイメージは以下のようになります。

[スマホアプリ] ──┐                 ┌──▶ [スマホ用BFF] ──┐
               │                 │                    │
[PCブラウザ]  ──┼─▶ [API Gateway] ─┼──▶ [PC用BFF]     ──┼──▶ [マイクロサービス群]
               │                 │                    │     ├─ 商品サービス
[外部システム]──┘                 └──────────────────┘     ├─ ユーザーサービス
                                      (BFFをバイパス)       └─ 注文サービス

このように「API Gatewayの後ろにBFFを配置する」のが基本的な共存アプローチです。なお、UIを持たない外部システムなどは、BFFをバイパスしてAPI Gatewayから直接マイクロサービスへルーティングされるのが一般的です。

なぜこんな面倒なことをするのかというと、役割を綺麗に分離できるからです。API Gatewayには「システム全体を守るセキュリティやトラフィック制御」だけを任せます。その後ろにいるBFFは、認証などはAPI Gatewayが済ませてくれている前提で、「どのマイクロサービスからデータを取って、どうまとめて返すか」というフロントエンドに寄り添った仕事だけに専念できます。

先ほどのECサイトの例で言うと、スマホ用BFFは「商品サービス」と「在庫サービス」の2つだけを呼び出して最小限のデータをまとめますが、PC用BFFはそれに加えて「レビューサービス」も呼び出して、すべてを1つのJSONにまとめて返す、といった柔軟な設計が可能になります。

このように、API GatewayとBFFは競合するものではなく、「システム全体を守る盾（API Gateway）」と「画面ごとの最適なパーソナルトレーナー（BFF）」として、それぞれの強みを活かして共存しているんです。

マイクロサービスアーキテクチャにおけるAPI Gatewayの活用

ここまでAPI Gatewayの基本的な役割や、BFFとの違いについて見てきました。それでは、実際にマイクロサービスアーキテクチャを採用しているシステムの中で、API Gatewayはどのように使われているのでしょうか。このセクションでは、より実践的な視点から、API Gatewayが「ハブ」として機能する様子と、システム移行時の強力な味方となる理由について解説します。

クライアントと複数のマイクロサービスを繋ぐハブとしての働き

マイクロサービスアーキテクチャでは、システムを構成する機能が細かく分割されているのが特徴です。そのため、ユーザーが画面上でたった1回ボタンをクリックしただけでも、裏側では複数のサービスが連携して動くことがごく一般的になります。

例えば、ECサイトで「注文する」ボタンを押した場面を想像してみてください。この1回の操作の裏側で、「注文サービス」に注文データを登録し、「在庫サービス」から商品を引き当て、「決済サービス」で課金処理を行い、「ポイントサービス」に加算処理を依頼する……といった具合に、複数のAPIが同時に呼び出されることになります。

もしAPI Gatewayがない場合、スマホアプリやWebブラウザは、これら4つのサービスのURLをすべて知っておき、正しい順番でリクエストを送らなければなりません。サービスの数が増えれば増えるほど、クライアント側の実装は複雑化していきます。

ここでAPI Gatewayを「ハブ（交差点）」として配置すると、状況は一気にスッキリします。クライアントは「/api/orders」という単一のURLにリクエストを送るだけです。受け取ったAPI Gatewayが、内部のルーティング設定に従って適切なマイクロサービスへと通信を振り分けます。

この仕組みによって、クライアントから見れば「1つの巨大なAPI」を叩いているように見えます。裏側でマイクロサービスがどれだけ増えたり、URLが変わったりしても、クライアント側のプログラムを修正する必要がなくなるのです。

APIのバージョン管理と段階的なシステム移行

「新しいアーキテクチャに移行したいけれど、今動いているシステムを止めるわけにはいかない」――これは現場のエンジニアが直面する最もリアルな悩みのひとつです。システムを一気に作り変えるのはリスクが高く、現実的ではありません。API Gatewayは、この段階的な移行を支援する強力な機能を持っています。

具体的には、リクエストのURLやヘッダー（通信に添付される追加情報）の内容を見て、「古いシステム（モノリス）」と「新しいシステム（マイクロサービス）」のどちらにリクエストを流すかを動的に切り替えることができます。

例えば、URLのパスが /api/v1/users で始まるリクエストは従来のモノリスに、/api/v2/users で始まるリクエストは新しく作ったマイクロサービスにルーティングする、といった設定が可能です。このとき、クライアントからは「どちらのシステムが処理しているか」が見えません。これを「透過的なルーティング」と呼びます。

これを利用すると、まずは影響の少ない機能から少しずつマイクロサービスに切り出し、安定性を確認しながら徐々に移行範囲を広げていくという戦略がとれます。ユーザーはシステムが裏側で移行中であることにも気づきません。

このように、API Gatewayは単なる「入口」にとどまらず、システムの進化を安全に、かつスムーズに進めるためのインフラとしての側面も持っているのです。次のセクションでは、そんな便利なAPI Gatewayを導入する際に気をつけるべき設計のポイントについてお話しします。

API Gatewayを設計・導入する際のポイントと注意点

ここまでAPI Gatewayの便利さや役割についてお話ししてきましたが、実際に設計に落とし込む段階になると、いくつか気をつけなければならない落とし穴があります。最後のセクションでは、API Gatewayを導入する際に私がいつも心がけている2つの重要なポイントを共有します。

単一障害点（SPOF）にならないための設計思想

API Gatewayは、文字通りシステム全体への「入口」です。そのため、設計を誤ると単一障害点（SPOF：Single Point of Failure）になってしまいます。SPOFとは、その1箇所が停止するとシステム全体が連鎖的にダウンしてしまう弱点のことです。

例えるなら、巨大なショッピングモールのメイン入り口が1つしかなく、そこの自動ドアが故障してしまったら誰も中に入れない状態と同じです。バックエンドのマイクロサービスがどれだけ健全に動いていても、API Gatewayが落ちたらユーザーには何のサービスも提供できなくなります。

このリスクを防ぐための具体的なアプローチは主に2つあります。

1つ目は、クラウドのマネージドサービスを活用することです。AWS API GatewayやGoogle Cloud API Gatewayなどのマネージドサービスは、クラウド事業者側で複数のサーバーを自動的に用意し、障害が起きても別のサーバーに切り替える仕組みが最初から組み込まれています。私たちはサーバーの死活監視や切り替え処理を自前で実装する必要がありません。

2つ目は、マルチAZ（複数のデータセンター）での冗長化です。もし自前でAPI Gatewayを構築する（KongやAPISIXなどのオープンソースソフトウェアを利用するなど）場合は、1台のサーバーで稼働させるのではなく、複数のゾーンに分散させてトラフィックを振り分けるロードバランサーを前に配置します。これにより、特定のデータセンターが障害を起こしても、別のゾーンがシームレスにリクエストを引き継ぐことができます。

責務の持ちすぎを防ぎ、ロジックを含めない工夫

もう一つ、現場で非常によく見かける失敗が「API Gatewayに色々詰め込みすぎる」ことです。

API Gatewayは多機能なので、「ルーティングだけじゃなく、AサービスとBサービスのデータをくっつけて返す処理もここでやっちゃおう」「ちょっとした金額の計算もここで済ませよう」という誘惑に駆られがちです。しかし、これは非常に危険なアプローチです。

API Gatewayにビジネスロジック（「会員ランクがゴールドなら割引率を10%にする」といった業務ルール）や、複数サービスからのデータ集約処理を詰め込んでしまうと、どうなるでしょうか。結果として、Gateway自身がどんどん肥大化し、ほんの小さな仕様変更をするたびにGatewayの設定変更やデプロイが必要になります。

これは、マイクロサービス化して「個別にデプロイできるようにした」という本来の目的を完全に失ってしまいます。せっかく機能ごとに分割したのに、Gatewayが新たな巨大なモノリス（単一の巨大な塊）に成り下がってしまうのです。

例えば、「ユーザー情報」と「注文履歴」を結合してフロントエンドに返したい場合、API Gateway内で結合ロジックを書くのは避けるべきです。その場合は、前のセクションで触れたBFF（Backend For Frontend）のような別のバックエンド層を用意して、そこでデータを集約させるのが正しいアプローチです。

API Gatewayの設定ファイル（YAMLやJSONなど）の中に、if文やループ処理が何重にもネストされていたら、それは「責務を持ちすぎているサイン」だと思ってください。設定はシンプルに、複雑なロジックはバックエンドサービスに任せる。このメリハリをつけることが、長く持たせて保守しやすいシステム設計のコツだと私は考えています。

まとめ

この記事では、API Gatewayの基本的な役割から、マイクロサービスアーキテクチャにおける重要性、設計時のポイントまでを解説しました。

API Gatewayは、単なる通信の入り口としての役割にとどまらず、認証やトラフィック制御によるセキュリティと安定性の向上、システムの疎結合化による開発効率の向上など、現代の複雑なシステム運用において不可欠な存在です。また、BFF（Backend For Frontend）と組み合わせることで、バックエンドの複雑さを隠蔽しつつ、多様なクライアントに最適なデータを提供する柔軟なアーキテクチャを実現できます。

システムが成長し、マイクロサービス化を進める上でAPI Gatewayの導用はほぼ必須と言えます。導入を検討する際は、「単一障害点（SPOF）を作らないこと」と「Gatewayにビジネスロジックを持たせすぎないこと」の2点に注意して設計を行ってみてください。この記事が、皆さんのシステム設計の参考になれば幸いです。