APIゲートウェイという戦略
APIとマイクロサービスをまとめて管理する方法
APIとマイクロサービスは一緒に管理することができるのだろうか。本稿では、APIとマイクロサービスは個別よりも一緒に管理する方が良い理由と、その方法を解説する。
ソフトウェアの世界では、ほぼ全てのものに関連があると考えられている。ただし、残念ながら新しいソフトウェアの概念の大半は、それに逆らう形で開発されているのが実情だ。現在、マイクロサービスとその管理は注目を集めている。そして、APIの仲介と管理にも関心が寄せられている。だが、この2つを同時に考慮して、これらの管理ソリューションを関連付けることはできるのだろうか。
それは可能だ。そのためには、まずAPIとマイクロサービスの両方の管理について明確に定義する必要がある。そして、APIとマイクロサービスの管理目標を調和させるAPIゲートウェイモデルを作成し、APIとマイクロサービスの両方のメリットが確保できるようリスクを管理しなければならない。
併せて読みたいお薦め記事
マイクロサービスで失敗しないために
マイクロサービスを活用する
APIとマイクロサービスの管理を定義する
ソフトウェアアーキテクトや開発チームは、20年以上にわたって、アプリケーションを分散型サービスの集合体と見なしてきた。そして、この視点から生まれた全ての技法とアーキテクチャは、「コンポーネント化」と「バインド」という2つの問題を内包している。ここで言うコンポーネント化とは、ソフトウェアをどのように組み立てるのかという概念だ。一方のバインドは、個別のソフトウェアをどのように検出して関連付けるかを示す概念である。
ソフトウェアをコンポーネント化すると、コードの再利用が進む。また、クラウド時代においては、アプリケーションのスケーラビリティと回復性も向上する。サービス指向アーキテクチャ(SOA)は、分散可能なコンポーネントの青写真として誕生した。だが、ソフトウェア設計の慣習では、SOAの原則の多くが時代遅れになっている。これがソフトウェアの専門家の間で一致している見解だ。このSOAに取って代わるのが、マイクロサービスだ。
SOAでは、サービスはディレクトリ経由で検出され、構造化されたAPI経由でアクセスされる。構造化されたAPIには、セキュリティやアクセス権の管理などの機能が盛り込まれている。SOAは、本質的に細かいサービスではないのが一般的だ。つまり、SOAサービスでは、比較的複雑なタスクが実行され、APIの管理プロセスに付随するオーバーヘッドは問題と見なされていなかったことになる。
一方、マイクロサービスは非常に細かいサービスだ。一般的にマイクロサービスは、特定のビジネス機能を実行するコンポーネントと見なされる。そして多くの開発チームは、マイクロサービスを作成するために、ビジネス機能を実用上のステップに分割しているのが実情だ。マイクロサービスは、シンプルなRESTful API経由でアクセスされることが多い。また、各マイクロサービスへのアクセスではネットワークとのやりとりが生じるため、時間がかかる。そのためマイクロサービスアプリケーションは、細かくなり過ぎないように留意して、パフォーマンスに影響を及ぼさないようにするだけでなく、セキュリティとコンプライアンスも管理しなければならない。これがマイクロサービスの管理だ。
マイクロサービスで使用されるシンプルなAPIには、SOAのAPIに付随していたような機能はない。そして、大半のアプリケーションは、多くのマイクロサービスで構成されている。つまり、これまで単一のSOAサービスだったものが、6個以上のマイクロサービスで構成される可能性があるということだ。クライアント端末は、マイクロサービスごとにサービス呼び出しを行い、結果を組み立てる必要があるのだろうか。クライアント端末は、マイクロソフトサービスの所在や各マイクロサービスにどのようにアクセスするかを把握しているのだろうか。データの不正使用や傍受は、どのように防止するのだろうか。これに対処するのがAPIの管理だ。
APIゲートウェイの戦略
「APIゲートウェイ」の人気が急上昇している。これは、APIとマイクロサービスの両方を管理しながら、両者のメリットを維持するフレームワークとして誕生したものだ。APIゲートウェイは、ファサードデザインパターンの実装である。APIのアップストリームをユーザーまたはクライアント端末に渡して、ダウンストリームのAPIをマイクロサービス側で呼び出す。APIゲートウェイは、APIとマイクロサービスの管理を調和させる経路を提供している。
まずAPIゲートウェイは、単一のAPIをクライアント端末に提供する。このAPIの目的は、マイクロサービスにアクセスするための一連の複雑なプロセスをクライアント端末から隠すことにある。この処理により、クライアント端末はマイクロサービスを組み立てるという作業から解放され、輻輳(ふくそう)状態に陥りがちなクライアント端末のリンクからマイクロサービスのトラフィックを除外できる。そしてマイクロサービスをファイアウォールの背後に配置して、アクセスのセキュリティとコンプライアンスのリスクを軽減できる。APIゲートウェイで単一のAPIが公開されている状況に変わりはないが、APIのセキュリティはマイクロサービスよりも簡単に確保できる。
ただしAPIゲートウェイ戦略には3つのリスクが伴う。1つ目は、APIゲートウェイが事実上マイクロサービスを利用するアプリケーションであることだ。そのためAPIゲートウェイのコンポーネントを失うと、APIゲートウェイが窓口となっているマイクロサービスにアクセスできなくなる。2つ目は、APIゲートウェイに危害が加えられると、その影響が全てのマイクロサービスに及ぶことだ。そして3つ目は、APIゲートウェイでパフォーマンスの問題が発生すると、アプリケーションのQoE(Quality of Experience)が低下するというリスクだ。これらのリスクには共通点がある。それは、完全なスケーラビリティと回復性を備えたマイクロサービスとしてAPIゲートウェイを実装して、QoEを制限する機能をAPIゲートウェイに盛り込み過ぎないことを支持しているという事実だ。
リスクを管理する
APIゲートウェイ実装のベストプラクティスでは、状態イベントの構造を考慮することを推奨している。というのも、ユーザーによるフロントエンドのAPI呼び出しはバックエンドの呼び出しとは非同期に行われ、さらにバックエンドのAPI呼び出しも非同期に行われ、相互に依存する可能性があるからだ。このことから、単一のAPIゲートウェイの要求を満たすことが、どれほど複雑になるか想像に難くないだろう。ユーザーからの各要求は、個別の多面的な活動と見なさなければならない。つまり、状態イベントの構造によって表されるか、受動的なプログラミング設計パターンを使用して開発される必要がある。
APIゲートウェイは、クライアント端末の種類やワーカーの役割ごとに一意なファサードを作成するのに使用可能だ。各ファサードは、特定のユーザーがアプリケーションを起動したときに使用するマイクロサービスを制御することでアプリケーションの機能を制限できる。これは、セキュリティとコンプライアンス、それからAPIの管理全般において強力なツールになる。
APIゲートウェイには、必要になるAPIとマイクロサービスの数が急増するという側面もある。APIゲートウェイ自体は、1つ以上のAPIで構成されている。ソフトウェアチームがクライアント端末や役割ごとのファサードを開発するように推奨されたら、収拾が付かなくなり、管理できない数のAPIを作成しかねない。また、現在、マイクロサービスは、APIゲートウェイの陰に隠れ、ユーザーやアプリケーション概要レベルのデザイナーの目に触れないようになっている。この事実は、マイクロサービスの過剰なコンポーネント化を促進し、パフォーマンスに影響を与え、ロジックや作業の重複というリスクを引き起こす恐れがある。
APIの管理とマイクロサービスの管理の目標には重複する部分があるものの、完全に一致しているわけではない。どちらかの目標を犠牲にして、もう一方の目標を最適化しなければならないことに留意してほしい。マイクロサービスの管理ではパフォーマンスとコンポーネント化のバランス、APIの管理ではセキュリティとコンプライアンスのバランスを取る必要がある。両者が抱える問題を総体的に見れば、適切に対応できるはずだ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
6
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー