Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / APIゲートウェイをやさしく解説：マイクロサービスのルーティング・セキュリティ・レート制限、本当に必要？（AI吹き替え）

Transcript

APIゲートウェイをやさしく解説：マイクロサービスのルーティング・セキュリティ・レート制限、本当に必要？（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々が集う10日間への準備はいいですか?
0:07
この1月、M365コンがさらにパワーアップして帰ってきます。
0:12
世界中のMVPや業界エキスパートによるライブセッション、実演でも実践的な知識を体験しましょう。
0:18
ありきたりなスライドや、終わりのない専門用語の羅列はありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化といった現実の課題に取り組みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーなど、あらゆる方に向けたセッションを用意しています。
0:35
10日間の充実した期間で、多様な技術を学び、グローバルなコミュニティとつながることができます。
0:40
ライブで視聴し、実践的な知見を組織に持ち帰りましょう。
0:44
2027年1月、10日間、一つのマイクロソフトコミュニティ。
0:49
現在、登録受付中です。
0:51
m365コン.NETにアクセスして、今すぐ参加枠を確保してください。
0:56
URLはm365コン.NETです。
0:59
m365コン.NETから今すぐ登録を、1月のライブでお会いしましょう。
1:05
アプリを構築し、サービスを追加していくうちに、トラフィックの管理が悪夢のように複雑になっていませんか?
1:10
では、APIゲートウェイとは何か、そして本当にそれが必要なのでしょうか?
1:14
このエピソードの終わりには、APIゲートウェイの役割、管理の混乱を解決する理由、そして必要性の判断基準が理解できます。
1:22
まずは問題点から始め、次に構成要素、そしてそれらがどう組み合わさるのかを見ていきましょう。
1:27
問題は、入り口が多すぎること、です。
1:29
急成長している会社を経営していると想像してください。
1:32
3階には営業チーム地下には経理、裏の胸にはIT部門があります。
1:37
ここで、各部署に独自の玄関と電話番号があり、互いに連携しない警備員が配置されていると考えてください。
1:43
あなたが荷物を届けに来た訪問者だとしたら、かなり大変なはずです。
1:46
どのドアを使い、どの警備員に話しかけ、休憩中にはどうすればいいのかを正確に把握しなければなりません。
1:50
アプリが複数のバックエンドサービスを持ち、各クライアントがそれぞれに直接呼び出しを行うと、まさに同じことが起こります。
1:56
クライアントは、モバイルアプリであれウェブサイトであれ、全サービスの場所、認証方法、障害時の対応を知っておく必要があります。
2:04
各サービスがそれぞれセキュリティ、レート制限、エラーハンドリングを個別に対処しなければなりません。
2:09
これは重複作業であり、一貫性が失われやすくなります。
2:12
銀行を例に挙げてみましょう。
2:14
口座支払い、ローン、不正検知のためにそれぞれ独立したサービスが存在します。
2:17
従来の方法では、各サービスが直接公開されていました。
2:19
モバイルアプリは、4つの異なるURL、4つの認証方法、そして4つのエラー処理方法を知っておく必要があります。
2:25
これは複雑さが4倍、問題が起こる可能性も4倍になるということであり、APIゲートウェイはそのような混乱を解決するために設計されています。
2:32
では、解決策は何でしょうか?
2:33
APIゲートウェイとは何でしょうか?
2:35
APIゲートウェイをホテルのフロントデスクのように考えてみてください。
2:38
ホテルに入るとき、清掃係がどの階にいるか、キッチンがどこにあるか、メンテナンスチームへの連絡方法を知る必要はありません。
2:44
ただフロントデスクに行き、必要なことを伝えれば、あとはすべて彼らが対応してくれます。
2:48
彼らはあなたの要求を適切な担当者に回し、滞在が許可されているかを確認し、基本的な要求なら自分たちで処理することさえあります。
2:54
APIゲートウェイはソフトウェアに対しても同じことを行います。
2:57
それは、クライアントとバックエンドサービスの間に位置する単一の入り口です。
3:01
すべての要求は、まずゲートウェイを通ります。
3:03
ゲートウェイは、要求をどこへ送るか、許可するかどうか、そして何を返すかを判断します。
3:07
これは新しい考え方ではありません。
3:09
リバースプロ機種は何十年も前から存在していますが、マイクロサービスにおいてAPIゲートウェイは不可欠なものとなりました。
3:14
アプリを多数の小さなサービスに分割すると、突然多くの扉ができることになります。
3:17
ゲートウェイは、そのための正面玄関を一つ用意してくれます。
3:19
Azureの世界では、Azureアピマネジメントが完全なプラットフォームであり、ゲートウェイはそのトラフィックを処理する中核コンポーネントです。
3:24
しかし、このパターンはどこでも共通です。
3:26
単一の入り口、一元化された制御です。
3:29
すべての要求がここに入ってきます。
3:30
ゲートウェイが要求を確認し、ルーティングし、応答を返します。
3:33
クライアントがバックエンドサービスと直接通信することはありません。
3:35
クライアントはゲートウェイとだけ通信します。
3:37
具体的にどういうことか、詳しく見ていきましょう。
3:39
最も基本的な役割であるルーティングから始めます。
3:42
パート1 トラフィックのルーティングです。
3:44
APIゲートウェイの最も単純な仕事はルーティングで、各要求を適切なサービスに誘導することです。
3:49
ウェブサイトの仕組みについて考えてみてください。
3:50
リンクをクリックすると、ブラウザが要求を送信します。
3:53
その要求にはパスが含まれています。
3:54
パスがユーザーズなら、ゲートウェイはそれをユーザーサービスに送るべきだと判断します。
3:57
オーダーズなら、注文サービスに送ります。
4:00
ゲートウェイはパスを読み取り、送信先を特定して転送します。
4:03
ゲートウェイがなければ、クライアントはすべてのサービスのURLを知っておかなければなりません。
4:07
モバイルアプリには、ユーザーサービス、注文サービス、決済サービス、カタログサービスの住所が必要です。
4:11
それでは管理すべきURLが多すぎます。
4:13
もしそれらのアドレスのいずれかが変更されれば、すべてのクライアントを更新しなければなりません。
4:17
ゲートウェイがあれば、クライアントはURLを一つ知るだけで済みます。
4:19
ゲートウェイのアドレスです。
4:20
クライアントはサービスがどこにあるかを気にする必要はありません。
4:23
ゲートウェイにリクエストを送るだけで、残りはすべてゲートウェイが処理します。
4:26
これはAPIゲートウェイの最も一般的なユースケースの一つ、リソースベースのルーティングです。
4:30
Apache APIsIXの研究でも、これが明確に挙げられています。
4:33
パスやHTTPメソッド、ヘッダー、さらにはクライアントの地理的位置情報に基づいてルーティングします。
4:37
ヨーロッパからのリクエストであれば、ヨーロッパのデータセンターへ振り分けることができます。
4:41
米国からのリクエストであれば、米国のデータセンターへ送られます。
4:44
クライアントは、こうした処理が行われていることを一切知りません。
4:46
ただ迅速なレスポンスを受け取るだけです。
4:47
ルーティングはバージョニングの管理にも役立ちます。
4:49
例えば、ユーザーサービスの新しいバージョンを作成したとしましょう。
4:51
古いクライアントは引き続き、V1、ユーザーズを使い、新しいクライアントは、V2、ユーザーズを使います。
4:56
ゲートウェイはこれらを異なるバックエンドへと振り分けます。
4:58
新しいバージョンを導入する間も、古いクライアントは動作し続けます。
5:01
クライアントに影響を与えずにバックエンドを変更できるのです。
5:04
これは実際のユーザーを抱えるライブアプリケーションを管理する上で非常に重要です。
5:07
eコマースプラットフォームを例に考えてみましょう。
5:09
カタログ、ショッピングカート、チェックアウト、ユーザーアカウントの各サービスが個別に存在します。
5:13
ゲートウェイがなければ、モバイルアプリは4つの異なるURLを把握しなければなりません。
5:17
ゲートウェイがあれば、URLは1つで済みます。
5:19
ゲートウェイはパス、カタログ、カート、チェックアウト、アカウント、お読み取り、各リクエストを適切なサービスへ送ります。
5:24
単純なルーティングは簡単な部分です。
5:26
次の役割こそが、真の有用性を発揮する部分です。
5:29
パート2、フロントドアにおけるセキュリティです。
5:31
すべてのAPI呼び出しをチェックする必要があります。
5:33
誰がこのリクエストを行っているのか、適切な権限を持っているのか、
5:36
ゲートウェイがない場合、各サービスがそれぞれ認証を処理しなければなりません。
5:39
それは作業の重複を意味し、ミスも起こりやすくなります。
5:42
あるサービスはトークンを適切に確認しても、別のサービスは手順を省略したり、
5:54
処理するからです。
5:55
チェックする場所も、強制する場所も、ポリシー変更時に更新する場所も一箇所にまとまります。
5:59
これは主要なセキュリティベストプラクティスです。
6:01
ゲートウェイはすべてのリクエストにおいて、APIキー、JWT、オーストークン、または証明書を検証します。
6:07
すべてのリクエストが同じチェックを通ります。
6:09
例外はありません。
6:10
ゲートウェイはルールを適用することも可能です。
6:12
このAPIキーは読み取り用エンドポイントのみ呼び出せる、といった設定が可能です。
6:15
あるいは、このクライアントはカタログサービスにはアクセスできるが、決済サービスにはアクセスできない、といった制御も可能です。
6:19
ゲートウェイレベルで細かな権限を定義すれば、それらが自動的に適用されます。
6:23
バックエンドサービスは、認証を気にする必要がありません。
6:26
リクエストを処理してデータを返すだけです。
6:28
ここが重要なポイントです。
6:30
ゲートウェイは、問題が発生した際にアクセス権を取り消す唯一の場所となります。
6:33
クライアントのAPIキーが漏えいした場合、ゲートウェイで無効化します。
6:36
変更は一度だけ、これで完了です。
6:38
すべてのサービスを更新したり、再起動したりする必要はありません。
6:40
そのキーからの次のリクエストは即座に拒否されます。
6:43
具体的な例を挙げましょう。
6:44
銀行には決済サービスと請求サービスがあります。
6:46
請求システムへの書き込み権限が必要なのは、決済サービスだけです。
6:49
ゲートウェイがそれを強制します。
6:51
クライアントが誤ったエンドポイントから請求システムへ書き込もうとすると、ゲートウェイがブロックします。
6:55
請求サービスは、そのリクエストを検知すらしません。
6:58
ゲートウェイは相互TLSやWAF統合をサポートし、より強固な保護も可能です。
7:02
しかし本質的には、これが最初の防御ラインとなります。
7:04
セキュリティは重要ですが、一度に大量のリクエストが来た場合はどうでしょうか。
7:08
パート3 トラフィック管理です。
7:10
1万人のユーザーが同時にアプリにアクセスしたらどうなるでしょう?
7:13
プラッシュセールや製品の爆発的なヒット、あるいはただの火曜日に全員が一斉にログインしたのかもしれません。
7:20
ゲートウェイがなければ、バックエンドサービスは直接攻撃を受け、クラッシュする可能性があります。
7:24
ゆっくりではなく、一気にです。
7:26
そこでトラフィック管理の出番です。
7:28
ゲートウェイは、各クライアントのリクエスト数を制限できます。
7:32
レート制限やスロットリングは標準的な機能です。
7:34
ゲートウェイでルールを設定すれば、それが適用されます。
7:37
バックエンドサービスが急激な負荷を感じることはありません。
7:39
ユーザーごと、APIキーごと、あるいはIPアドレスごとにコータを設定できます。
7:42
例えば、APIに無料プランがあるとします。
7:44
無料ユーザーには1時間あたり100リクエストを許可します。
7:47
プレミアムユーザーには1万リクエストを許可します。
7:49
ゲートウェイはすべてのリクエストを追跡し、入り口でその制限を適用します。
7:52
無料ユーザーが上限に達すると、ゲートウェイは丁寧な再試行メッセージを返します。
7:56
バックエンドサービスは、リクエストがあったことすら知りません。
7:59
有料顧客へのサービス提供を快適に継続できます。
8:02
ゲートウェイは負荷分散も行います。
8:04
同じサービスを複数インスタンスで実行している場合、ゲートウェイがリクエストを分散させます。
8:09
最初のインスタンスにリクエスト、次は2番目、その次は3番目という具合です。
8:12
これは自動的に行われます。
8:14
また、あるインスタンスが停止してもゲートウェイが別へルーティングします。
8:16
クライアントは気づきません。
8:17
彼らはただレスポンスを受け取るだけです。
8:19
ヘルスチェックを伴う負荷分散が円滑な運用を支えます。
8:22
ゲートウェイは各インスタンスにピンを打ち、稼働を確認します。
8:25
停止していれば、そこへのトラフィックを停止します。
8:27
これは高トラフィックなAPIにとって特に重要です。
8:30
ゲートウェイがないと、急激なトラフィック増はサービスに直接影響します。
8:33
ゲートウェイがあれば、スパイクはまずゲートウェイに当たり、そこで吸収、分散されるため、サービスがパンクするのを防げます。
8:40
では、届いたデータが想定と違う場合はどうでしょうか。
8:44
パート4 データ変換です。
8:46
クライアントが送るデータが、バックエンドの期待するものと一致しないことがあります。
8:49
例えば、クライアントはJSONで送るのに、バックエンドはXMLしか理解できない場合などです。
8:53
あるいは、フィールド名が一致しない場合もあります。
8:55
クライアントは、ファーストネームを使っているのに、バックエンドは、ファーストアンダーバーネームを期待しているようなケースです。
8:59
こうした不一致はシステムを壊してしまいます。
9:01
従来の方法では、すべてのクライアントを修正するか、バックエンドを書き直す必要がありました。
9:04
あまり良い方法ではありません。
9:05
ゲートウェイを使えば、バックエンドに届く前にデータを変換できます。
9:08
翻訳者のようなものだと考えてください。
9:10
中央に配置され、行きと帰りのデータ、あるいはその両方を変更できます。
9:13
これがリクエストおよびレスポンス変換の要点です。
9:15
実際の例を挙げましょう。
9:17
XMLを期待するレガシーシステムがあるとします。
9:19
15年も稼働し続けています。
9:21
問題なく動作しています。
9:22
しかし、新しいモバイルアプリを作ることになり、モバイルアプリはJSONを扱います。
9:25
ゲートウェイがないと、レガシーシステムを書き換えるか、モバイルアプリに無理やりXMLを送らせる必要があります。
9:29
ゲートウェイがあれば、そのどちらも不要です。
9:31
モバイルアプリはJSONを送信します。
9:33
ゲートウェイがそれをXMLに変換します。
9:35
システムは想定通りのデータを受け取ります。
9:36
モバイルアプリは、JSON形式のレスポンスを受け取ります。
9:38
誰も何も書き直す必要はありません。
9:40
これこそが、その素晴らしさです。
9:42
ゲートウェイはヘッダーの追加や削除、URLの変更、機密データのマスクも可能です。
9:45
レスポンスにクレジットカード番号が含まれていると想像してください。
9:48
それをクライアントに返したくはありませんよね。
9:50
ゲートウェイなら、レスポンスを返す前にそれを取り除くか、マスクされたバージョンに置換できます。
9:54
バックエンドは一切変更する必要がありません。
9:56
ゲートウェイが処理してくれるからです。
9:57
これは古いシステムのモダナイゼーションを行う際に特に便利です。
9:59
バックエンドを書き直す必要はありません。
10:01
クライアントに強制的な変更を求める必要もありません。
10:03
ゲートウェイの設定を変えるだけです。
10:05
国際会議の翻訳者のようなものです。
10:06
全員が自分の言語で話しますが、翻訳者が全員の理解を保証します。
10:10
ゲートウェイはあなたのソフトウェアにとってのその翻訳者なのです。
10:12
ルーティング、セキュリティ、スロットリング、変換、やることが多いですね。
10:15
しかし、これらは4つの別々のことではありません。
10:17
どのように関連しているかお見せしましょう。
10:18
全てがどう繋がっているのか。
10:20
重要なのはここです。
10:21
これら4つの仕事は切り離せません。
10:23
リクエストが来るたびに、全てのリクエストに対してこれらが連携して動作します。
10:26
ゲートウェイは認証を確認します。
10:28
レート制限を検証します。
10:29
正しいサービスへとルーティングします。
10:31
必要に応じてデータを変換します。
10:33
レスポンスを受け取ります。
10:34
必要であればそれも変換します。
10:36
そして、全てをクライアントに送り返します。
10:37
1つのパイプラインです。
10:39
各サービスが意識することなく、全てのステップが自動的に順序通り実行されます。
10:42
真の力は単一の機能にあるのではありません。
10:44
それは統合にあります。
10:46
ルーティングに触れることなく、新しいセキュリティポリシーを追加できます。
10:49
クライアントを変更せずに、バックエンドサービスも変更できます。
10:52
何も再デプロイすることなく、デート制限を更新できます。
10:54
各パーツは独立していますが、全て同じパイプラインで動作します。
10:58
全てが一箇所を通るため、何が起きているのかを完全に可視化できます。
11:01
ログ、メトリクス、分析、全てが一箇所に集約されます。
11:05
リクエスト数、失敗したリクエスト、定則だったリクエスト、どのクライアントがリソースを最も消費しているかを確認できます。
11:10
ゲートウェイがなければ、各サービスから個別にデータを収集しなければなりません。
11:13
ゲートウェイがあれば、全てがそこに揃っています。
11:15
それが重要な洞察です。
11:16
ゲートウェイは単なるルーターではありません。
11:18
APIプラットフォーム全体の完成センターなのです。
11:20
全てのリクエスト、レスポンス、エラーが一箇所を通ります。
11:23
何が起きているのかを全て把握できる、単一の管理画面を手に入れるのです。
11:26
では、これを実際にどう活用すれば良いのでしょうか。
11:28
今すぐできることについてお話ししましょう。
11:30
実践的なヒントです。
11:31
現実的に考えましょう。
11:32
サービスが一つか二つなら、まだAPIゲートウェイは必要ないかもしれません。
11:35
ルーティングは自分で処理し、認証も各サービスで管理できます。
11:38
洗練されてはいませんが、機能はします。
11:40
しかし、サービスが三つになるか、外部クライアントにAPIを公開するようになれば、複雑さは急速に増します。
11:45
ゲートウェイはすぐに元が取れます。
11:47
では、最初のステップは何が最適でしょうか。
11:49
認証をゲートウェイに集約することです。
11:50
何よりもまずそれを行ってください。
11:52
サービスを一つ選び、その認証チェックをゲートウェイに移行します。
11:54
サービスのコードがすぐに綺麗になることに気づくはずです。
11:57
トークン検証のロジックが至るところに散らばることもなくなります。
12:00
すべてのサービスで同じ実装ができているか悩む必要もありません。
12:03
ゲートウェイが一度処理すれば、すべてのサービスが恩恵を受けられます。
12:06
次のステップは、レート制限です。
12:08
単純な制限であっても、バックエンドの過負荷を防ぐことができます。
12:11
まずは1クライアントあたり毎分100リクエストといった基本的なものから始めましょう。
12:14
これにより、暴走するクライアントがサービスを停止させるのを防げます。
12:16
お話しできるのは、