信頼性の高いAPIを構築するためのベストプラクティス
August 18, 2022
APIがスケールするにつれ、それらを信頼性が高く堅牢にする必要性が増します。
この記事では、APIゲートウェイと呼ばれる特別な種類のリバースプロキシを導入することで、信頼性の高いAPIを構築するためのベストプラクティスについて説明します。
以下について見ていきます：
- 従来のAPI設計の問題点
- APIゲートウェイとは何か
- APIゲートウェイがAPIをどのように改善するか
- APIゲートウェイを使用したパターンと例
しかしまず、「信頼性の高い」APIとは何でしょうか？
信頼性の高いAPIとは何か？
サービスプロバイダーとして、顧客との間でサービスレベル契約（SLA）を結んでいるかもしれません。通常、これは稼働時間（サービスがオンラインで動作していることが保証される時間）で表されます。
稼働時間は信頼性の一面に過ぎません。信頼性とは何かを理解するためには、稼働時間に影響を与える要因を見る必要があります。これらの要因を理解すれば、信頼性の高いサービスを構築するためのより良い立場に立つことができます。
これらの要因とそれらが提起する質問を見てみましょう：
- レイテンシ: APIはリクエストにどれくらい速く応答しますか？
- セキュリティ: 誰がAPIにアクセスできますか？それは安全ですか？
- ダウンタイムの頻度: APIはどれくらい頻繁にダウンしますか？
- 一貫性: APIエンドポイントは一定ですか？消費者は頻繁にコードを変更する必要がありますか？
- 監視とレポート: APIの問題や障害を観察できますか？それらを消費者に報告していますか？
組織がクラウドネイティブアーキテクチャに移行するにつれ、開発チームが各サービスでこれらの要因を考慮することが難しくなります。そして、これらのシステムがスケールするにつれ、これらの責任を単一の別システムに委任することがはるかに簡単になります。APIゲートウェイに挨拶しましょう！
APIゲートウェイ、統一されたエントリーポイント
APIゲートウェイは、クライアントとAPIの間の仲介役として機能します。リバースプロキシのようにすべてのトラフィック（API呼び出し）を受け入れ、バックエンドの必要なサービスにリクエストを転送し、必要な結果を返します。
APIゲートウェイは、すべての認証、セキュリティ、トラフィック制御、監視の懸念を処理する中心点となり、API開発者がビジネスニーズに集中し、信頼性を向上させやすくします。
多くのオープンソースおよびマネージドAPIゲートウェイの提供があります。この記事では、Apache APISIXを使用します。
次のセクションでは、APIゲートウェイを使用してAPIを信頼性の高いものにするためのいくつかのベストプラクティスについて説明します。
APIゲートウェイを使用した信頼性のベストプラクティス
実際の実装はAPIゲートウェイの選択に基づいて異なる可能性があるため、パターンの下にあるものに焦点を当てます。
これらのパターンを3つのカテゴリに分けます：
- 認証とセキュリティ
- 監視と可観測性
- バージョン管理とゼロダウンタイム
以下で各カテゴリを詳しく見ていきます。
認証とセキュリティ
ユーザー認証
APIゲートウェイを使用した認証済みリクエストは、クライアントとAPIの相互作用を保護します。クライアントが認証した後、APIゲートウェイは取得したクライアントの詳細を使用して細かい制御を行うことができます。
APISIXは、key-authやjwt-authなどのプラグインを通じて直接認証を処理します。APISIXはまた、OAuth認証やopenid-connectやwolf-rbacなどのプラグインを通じてロールベースのアクセス制御システムをサポートしています。
レートリミット
意図的（DoS攻撃）または意図的でない（クライアントが過剰なリクエストを行う）トラフィックスパイクは、APIをカードの家のように崩壊させる可能性があります。レートリミットを設定することで、そのようなシナリオを処理するシステムの信頼性を向上させることができます。
APIゲートウェイにレートリミットを設定し、リクエスト数が閾値を超えた場合、APIゲートウェイは超過したリクエストを遅延または拒否することができます。
APISIXでは、リクエスト数、クライアントごとの同時リクエスト数、およびカウントに基づいてレートリミットを設定するために、3つのプラグインのいずれかを使用できます（limit-req、limit-conn、limit-count）。
監視と可観測性
APIの信頼性と監視設定は密接に関連しています。APIゲートウェイに監視を設定することで、信頼性メトリクスを監視できます。
APIログとトレースは、API呼び出しに関する詳細な情報を提供します。この情報は、APIが失敗したかエラーが発生したかをできるだけ早く知るのに役立ちます。サイレントな失敗は、将来問題を引き起こす可能性のある未修正のエラーにつながります。
いくつかの設定を行うことで、将来のトラフィックを予測し、信頼性を持ってスケールすることができます。
APISIXには、ロギング（Apache SkyWalking、RocketMQ）、メトリクス（Prometheus、Datadog）、およびトレーシング（OpenTelemetry、Zipkin）プラットフォーム/仕様と統合するプラグインがあります。APISIXプラグインを使用したAPI可観測性について詳しく読むことができます。
バージョン管理とゼロダウンタイム
カナリアリリース
APIの新しいバージョンに切り替える際、トラフィックを落とさないようにする必要があります。クライアントは引き続きAPIにリクエストを送信し、正しい応答を得ることができる必要があります。
APIゲートウェイを使用すると、カナリアリリースを設定できます。これにより、移行中もAPIが機能し続け、問題がある場合は古いバージョンにロールバックすることもできます。
最初に、APIゲートウェイはすべてのトラフィックをAPIの古いバージョンにルーティングします。
新しいバージョンがある場合、APIゲートウェイを設定して、トラフィックの一部をこの新しいバージョンにルーティングすることができます。新しいサービスへのトラフィックの割合を増やし続け、すべてが期待通りに動作しているかどうかを確認できます。
最後に、すべてのトラフィックを新しいAPIにルーティングできます。
APISIXは、サービスへのトラフィックを制御するtraffic-splitプラグインを使用します。これを使用して、カナリアリリースまたはカスタムリリース設定を設定できます。
サーキットブレーカー
アップストリームサービスの1つが利用できないか、高いレイテンシを経験している場合、システムから切り離す必要があります。そうしないと、クライアントはリクエストを再試行し続け、リソースの枯渇を引き起こす可能性があります。この失敗はシステム内の他のサービスに波及し、それらをダウンさせる可能性があります。
電気のサーキットブレーカーが回路から故障したコンポーネントを切り離すように、APIゲートウェイには、システムを健全に保つために故障したサービスを切断するサーキットブレーカー機能があります。これらのサービスへのトラフィックは、サービスが健全になるまで再ルーティングまたは遅延されます。
APISIXには、このパターンを実装するapi-breakerプラグインがあります。
リダイレクト
APIを更新する際、そのエンドポイントが変更されることがあります。従来、これはクライアントアプリケーションが/old-api-endpointではなく/new-api-endpointにリクエストを送信する必要があることを意味し、消費者はこのAPIエンドポイントへの各呼び出しを手動で変更する必要があります。
予期せぬ場合、これはクライアントアプリケーションを壊す可能性があります。
APIゲートウェイを使用すると、抽象化レイヤーを提供し、クライアントがリクエストを変更することなく/new-api-endpointにリクエストをリダイレクトできます。適切なリダイレクトステータスコードとメッセージを使用して、消費者がダウンタイムを経験することなく/old-api-endpointを段階的に廃止できます。
APISIXでは、redirectプラグインを使用してリダイレクトを設定できます。
結論
信頼性が主要な懸念事項になると、より多くの組織がモノリスをマイクロサービスに分割し、クラウドネイティブアーキテクチャに移行するにつれ、APIゲートウェイが必要であることが明らかです。
ただし、これはAPIゲートウェイがすべての人に適しているという意味ではありません。APIのサイズと使用状況に応じて、APIゲートウェイは過剰であり、基本的なルーティングとロードバランシング機能を備えたリバースプロキシを使用することで済む場合があります。
ここで言及したユースケースは、APIゲートウェイの能力の表面をなぞったに過ぎません。APIゲートウェイとApache APISIXについて詳しくは、apisix.apache.orgで学ぶことができます。