マイクロサービスとKubernetes：OpenAPIで機能的および運用上の一貫性を実現

2022年5月24日

OpenAPIでマイクロサービスとKubernetesの課題を克服

APIが現代の組織を支える。

今日のテクノロジーに精通した消費者のデジタルニーズに応えるため、APIファースト開発戦略が増加しています。なぜでしょうか？組織は市場の変化に迅速に対応する必要があるからです。よりアジャイルになるために、多くの組織はより消費しやすいアーキテクチャアプローチへと移行しています。

マイクロサービスアーキテクチャは、明確に定義されたインターフェースを持つ単一機能モジュールに焦点を当てたソフトウェア開発手法であり、より小さな消費可能な機能を提供するためのアジャイルで分散型のワークフローをサポートします。

これと並行して、コンテナベースの技術がマイクロサービスのデプロイとホスティングに広く採用されています。Kubernetesというコンテナオーケストレーションシステムは、マイクロサービスの管理、スケーリング、デプロイに対処するための人気のある選択肢です。

しかし、これらのパターンやテクノロジーを採用しても、API戦略の成功が保証されるわけではありません。一貫した品質を提供しながら十分な規模を達成することは容易ではありません。投資が実を結ぶまでに時間がかかることもあります。SoundCloudのモノリシックアーキテクチャからストランギュラーパターンを使用した8年間の移行ジャーニーを参照してください。

とはいえ、あなたの運命をコントロールする上で最善の立場に立つためのいくつかの側面について見ていきましょう。

API、マイクロサービス、Kubernetesに関する課題

API提供への断片的なアプローチは、APIの混乱を引き起こし、デジタルの進化を麻痺させます。

多くの組織における共通のテーマは、システム統合を支えるドキュメント化されていないAPIの蔓延です。これは、API品質の一貫性の欠如、開発者エクスペリエンスの低下、セキュリティ問題の可能性につながります。

KubernetesはAPIのスプロールを抑制しますが、それ自身の課題をもたらします。Kubernetes Ingressの宣言的な性質は、それが構成駆動型であることを意味します。Ingress仕様はこれらの構成を記述しますが、この仕様には、本番環境でAPIを自信を持って公開するために必要な多くの機能が欠けています。制限を克服するために、Kubernetesランドスケープ内の多くのコントローラーは、機能構成オプションを指定するための独自のアプローチを持っています。

これらの課題のため、組織は最適な開発者エクスペリエンスを提供し、API品質を維持し、Kubernetes構成の一貫性を制御下に置くことに苦労しています。一部の課題は、提供プロセスにおけるワークフローの競合やチーム構造によって引き起こされます。たとえば、Ingressコントローラーの運用構成は、Ops担当者によって実行されることが多いですが、APIの機能的な進化はDevによって行われます。調整のオーバーヘッドは、ボトルネックや本番環境の問題を引き起こす可能性があります。

OpenAPIによるデザインファーストな機能的および運用上の一貫性

デザインファーストのアプローチを適用することで、APIプログラムを改善できます。サービスの機能的側面と運用側面の両方を網羅し、OpenAPI仕様を活用することで、チームはデザインからデプロイまで、品質中心の協調的なAPIワークフローで進行できます。

このアプローチの利点に飛び込む前に、その用語を探ってみましょう。

OpenAPI とは？

以前はSwagger仕様として知られていたOpenAPI仕様（OAS）は、HTTPベースのAPIに対する標準的な言語に依存しないインターフェースを定義します。OASを使用すると、人間とコンピューターは、ソースコード、ドキュメント、またはネットワークトラフィック検査にアクセスすることなく、サービスの機能を理解できます。

OpenAPIのようなAPI仕様は、APIがどのように見えるかを文書化するだけではありません。消費者は、最小限の実装ロジックでリモートサービスを理解し、操作できます。APIのプロバイダー側でも同様で、関係者は、あらゆるサービスが提供する価値提案について、より効果的にコミュニケーションできます。

Figure 1 – OpenAPI driving the API Lifecycle

図1 – APIライフサイクルを推進するOpenAPI

API定義を使用すると、クライアントとサーバーのコード生成、API実装のモック、テスト自動化、APIのストーリーテリングなど、APIライフサイクルの多くのステップを自動化できます。この自動化の可能性により、APIのプロデューサー側とコンシューマー側の両方でDevOpsサイクルからの無駄が削減されます。

APIとマイクロサービス – 違いは何ですか？

これらの用語はしばしば互換的に使用されますが、同じではありません。

APIは*Application Program Interface*の略です。APIは、サービス、機能、またはデータへのインターフェースです。プログラム可能なインターフェースは、実装の詳細を隠しながら、ソフトウェアアプリケーションとコンポーネント間の接続と通信を容易にします。APIはソフトウェアの*言語*です。

マイクロサービスは実装に関するものです。マイクロサービスアーキテクチャは、自己完結型コンポーネントの提供を促進する実装パターンです。これらは個別に更新および進化できます。APIはマイクロサービスなしでも存在できます！ほとんどの組織はゼロから始める余裕がないため、API戦略には、API提供のためのモノリスからマイクロサービスへのアプローチの進化が含まれます。

Figure 2 – A typical Monolith to Microservices evolution approach

図2 – モノリスからマイクロサービスへの一般的な進化のアプローチ

マイクロサービスは、API数の増加の主要な触媒です。

Kubernetesとは？

Kubernetes、別名K8sは、コンテナ化されたワークフローとサービスを管理するための、ポータブルで拡張可能なオープンソースプラットフォームです。「ポッド」と「ラベル」の概念を使用して、アプリケーションを構成するコンテナを論理ユニットにグループ化し、管理と発見を容易にします。

Figure 3 – Kubernetes architecture (containers in grey, pods in color), © Google Inc

図3 – Kubernetesアーキテクチャ（灰色はコンテナ、カラーはポッド）、© Google Inc

KubernetesはGoogleによって開発され、Cloud Native Computing Foundation (CNCF)に寄贈されました。

APIゲートウェイとは？

APIゲートウェイは、API管理戦略の一部として使用されるコンポーネントです。API資産への玄関口として機能します。ゲートウェイは、クライアントとAPI間のリクエストおよびレスポンストラフィックを傍受し、多くの共通アクティビティを実行します。正確な機能は異なりますが、ルーティング、マッピング、レート制限、認証、変換、検証、分析、および課金がすべて可能です。

IngressとIngressコントローラーとは？

通常、サービスとポッドは、内部クラスターネットワークによってのみルーティング可能なIPを持っています。エッジルーターに到達するすべてのトラフィックは、ドロップされるか、他の場所に転送されます。

Kubernetes Ingressは、Kubernetesクラスター内で実行されているサービスへの受信トラフィック（通常はHTTPまたはHTTPS）の外部アクセスルーティングルールを記述するAPIオブジェクトです。Ingressは、外部クライアント（クラスターの外部に存在する）が、安定した外部アドレス可能なURLを介してクラスター内のアプリケーションに簡単にアクセスできるようにするために作成されました。

Figure 4 – Simple Ingress – ©Kubernetes.io

図4 – シンプルなIngress – ©Kubernetes.io

Ingressコントローラーは、実際のIngress実装を提供し、Ingressリソースが機能するには実行中のコントローラーが必要です。Ingressコントローラーは、クラスター内の他のアプリケーションと同様にポッドであり、他のポッドを見ることができます。コントローラーは、受信リクエストを検査し、Ingressマニフェストで指定されたルーティングなどの特定のルール履行を実行できます。IngressコントローラーはAPIゲートウェイに似ています。

クラウドがAPI標準を必要とし、複雑にする

業界調査によると、標準化、ガバナンス、セキュリティは大きな課題です。クラウドネイティブ環境の採用により、API製品の運用側面の標準化を強制することは、分散型組織全体で全体的な開発者エクスペリエンスを保証しながら監視を維持するために、機能要素と同様に重要です。これにより、分散型組織全体で監視を維持しながら、優れた開発者エクスペリエンスにつながる可能性があります。

SmartBearは最近、Kubeshopの友人と協力して、SwaggerHubとKuskを組み合わせることで、APIの*単一の真実の源*を促進する方法を紹介しました。

高速で協調的な、標準化されたAPI設計を可能にすることがSwaggerHubの最大の強みです。OpenAPIと組織のカスタムルール（またはスタイルガイド）への準拠をシンプルかつ直感的にします。SwaggerHubとKubeshopのx-kusk拡張機能を組み合わせることで、チームはKubernetesで実行されているAPIの操作とアクセス管理のための単一の真実の源を得ることができます。

x-kusk拡張機能は、選択されたクラスターテクノロジーに依存しない統一された方法で、OpenAPI定義と直接APIのさまざまなランタイム特性を宣言することをサポートしています。

以下の内容を定義と直接指定することが可能です。

タイムアウト/リトライ
CORS
パス/操作の無効化（例：外部公開前に管理パスを非表示にする）
モック
検証
クラスター固有のプロパティ

Figure 5 – Sample kusk extension for OpenAPI

図5 – OpenAPIのKusk拡張機能の例

同じSwaggerHub APIエディターを使用して、チームはIngressルートやその他の運用上の詳細を使い慣れたツール内で構成できます。さらに、SwaggerHubは設計中に運用構成に標準化を適用でき、検証、モック、ルートレベル設定などの機能の基盤を築きます。

APIがKuskゲートウェイへの公開準備が整うと、チームはランタイム設定が以前のフェーズで検証されたものと一致することを知っています。

典型的なSwaggerHubとKusk Gatewayのワークフローは次のとおりです。

関連するすべての利害関係者と共同でSwaggerHubでAPIを設計する
SwaggerHubの標準適用を使用して、x-kusk拡張機能が正しく配置されていることを確認する
SwaggerHubのGitHub統合を使用して、検証済み定義を同期/プッシュする（GitHubへ）
CI/CDを使用してAPI定義のKusk Gatewayへのデプロイを自動化し、実装が適切に行われていることを確認する
モバイル/Web/サードパーティアプリケーションからAPIを公開および消費する

組織全体で一貫性を確保するためにAPI標準を採用する

APIがソフトウェアの世界を消費し、マイクロサービスがモノリスの地を征服する中、APIおよびマイクロサービス資産の機能的および運用的側面を制御下に置くことは、かつてないほど重要になっています。

無料でご自身でお試しください：SwaggerHubを試して、標準を確立し、アジャイル戦略を推進しましょう。

なぜAPI標準が必要なのか？組織的メリット

機能的および運用的側面の一元的な表現（真実の源）
チーム全体（ビジネス、開発者、テスター、セキュリティ、運用）にわたる共同設計
マイクロサービスのためのアウトサイドインのアプローチ – 消費者体験と一貫性に焦点を当てる
標準化とガバナンス – 組織全体の発見可能性と一貫性を確保。サイクルの早い段階で運用側面を検証/アサートする能力
イテレーション開発の採用 – 設計からデプロイまでの自動化されたワークフローをサポート。ボトルネックの削減

さらに詳しく

オンデマンドウェビナー – KubeshopのCTOであり、元OpenAPI議長のOle Lensmar氏と、SmartBearのAPIテクニカルエバンジェリストであるFrank Kilcommins氏が、マイクロサービスとKubernetesでAPIプログラムを拡張する際の課題と、OpenAPIが混乱を鎮める上で果たす役割について探ります。
Kubeshopチームによるステップバイステップウォークスルーブログ – SwaggerHub、Kusk、およびOpenAPIを使用して、選択したKubernetesクラスターでAPIの設計ファーストから自動デプロイまでを実現します。