キーポイント
- An API gateway began by performing the routing functionality that was originally in the monolith, creating a common facade for the entire application.
- API gateways evolved further to meet the needs of microservices by incorporating traffic management and real-time service discovery.
- The cloud-native era requires API gateways to participate in release automation and expose metrics to full cycle development teams.
インターネットはこの数十年間で、私たちの生活のあらゆる場所に存在するようになりました。拡大を続けるオンラインサービスは、より高度なWebアプリケーションを開発する原動力となっています。このようなWebアプリケーションの進化が、データセンタエッジの進化を促しているのです -- データセンタエッジは、これらWebアプリケーションをインターネットに接続するハードウェアとソフトウェアのスタックであり、ユーザが企業のビジネスサービスと最初に対話する場所です。エッジは単純なハードウェアロードバランサとして始まり、APIゲートウェイやコンテンツ配信ネットワーク、ロードバランサを構成する、ハードウェアとソフトウェアプロキシのフルスタックへと進化しました。今回の記事では、アプリケーションアーキテクチャとワークフローの進化をもとに、データセンタエッジの進化の軌跡を追ってみたいと思います。
インターネット初期
1990年代中頃、Webアプリケーションアーキテクチャは初期段階にありました。Ruby on RailsやDjangoといったWebフレームワークはまだ開発されておらず、Apache StrutsやJ2EEといったテクノロジが勢いを得ていた時代です。
データベース層、アプリケーション層、プレゼンテーション層で構成される古典的なN層アーキテクチャが、当時のアプリケーションアーキテクチャのデファクトでした。N層アーキテクチャは水平スケーラブルです。すなわち、トラフィックの増加に対して、アプリケーションアーキテクチャとプレゼンテーション層のインスタンスを追加することで対応が可能です。(データベースの問題が別にありますが。)
アプリケーションとプレゼンテーション層の複数のインスタンスをインターネットに接続する必要から、データセンタエッジの最初のイテレーションであるロードバランサが生まれました。
この時代のロードバランサの責務は、アプリケーションのインスタンス間にトラフィックをルーティングして、高可用性とスケーラビリティを実現することでした。一般的にはハードウェアアプライアンスでしたが、2001年にHAProxyがリリースされると、ソフトウェアロードバランサというコンセプトが一般に広がり始めました。
Web 2.0
Darcy DiNucci氏は1999年、それまでの一方向のメディアから、Webサイトを通じてユーザが参加する双方向のメディアへというインターネットの進化を表現するために、Web 2.0ということばを生み出しました。コンテンツの受け身なコンシューマではなく、Web 2.0では、ユーザが相互に積極的な貢献と関与を行います。
AJAX(Asynchronous JavaScript and XML)開発技術が広く普及したのはこの頃です。データ交換をプレゼンテーションから分離することによってAJAXは、はるかにリッチなユーザエクスペリエンスをエンドユーザのために作り出しました。このアーキテクチャはまた、クライアントがWebアプリケーションと常時データの送受信を行うという、"よりチャット"なクライアントも誕生させました。
Eコマースが立ち上がり始めたのもこの時代です。クレジットカード情報の安全な送信が大きな懸念となったのは、この時が始めてでした。クライアントとサーバ間のセキュアなコネクションを保証するため、NetscapeがSSL(Secure Socket Layer) -- 後にTLS(Transport Layer Security)へと進化しました -- を導入しました。
このようなネットワークの動向 -- 暗号化された通知と、長時間持続するコネクションによる多数のリクエスト -- がエッジを、それまでの標準的なハードウェア/ソフトウェアロードバランサから、より特化されたアプリケーションデリバリコントロール(ADC)へと進化させたのです。ADCにはSSLオフロードやキャッシュや圧縮など、いわゆるアプリケーションアクセラレーション(Application Acceleration)のためのさまざまな機能が含まれています。この機能向上は同時に、設定の複雑さも増加させました。VCLやSSIのような、プロプライエタリな標準がたくさん現れました。ロードバランサはもはや、単なるロードバランスを行うものではなくなったのです！
Webスケールの時代
2010年代の初めには、数多くのクラウド中心の企業が、ユーザベースの指数級数的な成長を経験しました。これらの企業を舞台裏で支えるソフトウェアは、当初はモノリシックなWebアプリケーションとしてアーキテクトされていて、Ruby on RailsやDjangoといった使い勝手のよいWebフレームワークが使用されました。その後、ユーザベースが天文学的な数字にまで膨れ上がるにつれて、Webスケールの問題が新たなタイプの課題としてこれらの企業に持ち上がり、それまでとは違うアーキテクチャの必要を迫ったのです。Twitterの悪名高いクジラの画面(fail whale)はおそらく、当時の企業が直面し、Webスケールのアプリケーション開発に取り組む最初のきっかけとなった課題の代表例でしょう。
TwitterやFacebook、New Relicといった企業が、機能の重要な部分を、従来のモノリスから独立的にデプロイ可能なサービスへとリファクタする作業に着手しました。重要なビジネス機能をサービスとしてデプロイすることで、アプリケーション全体をさまざまな側面で独立的にスケールアップし、管理することが可能になったのです。これら独立したサービスへのトラフィックは、モノリスを通じてルーティングされていました。そのため、ルーティングに何らかの変更を行う場合には、モノリス全体を頻繁に再デプロイしなければならず、変更作業のボトルネックになっていました。
APIゲートウェイの台頭
これらの企業を含む多くの企業は、広範な技術コミュニテイによって自分たちのイノベーションや発見を共有していました。このような企業の初期に携わった技術者の多くが、他の企業に移籍したり、あるいは自らの知識をもとにしたスタートアップを立ち上げたりしました。当時のアーキテクチャから得られた教訓のひとつは明白でした -- すなわち、リファクタされたサービスに対して、モノリスは単なるルータの役割を果たしていたのです。
この認識から、初期のAPIゲートウェイの開発が始まりました。APIゲートウェイは元々モノリスが行っていたルーティング機能を代行すると同時に、アプリケーション全体に対する共通的なファサード(facade)を形成していました。レート制限や認証、ルーティングといったアプリケーションレベルの横断的な機能をAPIゲートウェイに集中化することにより、個々のサービスに必要な機能の重複を削減することが可能になりました。
クラウドネイティブの時代: マイクロサービス
今日の私たちは、クラウドネイティブの時代にいます。この時代でキーとなるのが、マイクロサービスの急増です。マイクロサービスは、アプリケーションアーキテクチャのあらたな動向を示しています。個々のマイクロサービスは自己完結的なビジネス機能を表現しており、アプリケーションの他のマイクロサービスとは独立して開発され、リリースされます。開発サイクルを分離することで、企業のクラウド向けソフトウェア開発プロセスを、より効率的にスケールアップすることが可能になります。
マイクロサービスはさまざまな環境 — 仮想マシン、ベアメタル、コンテナ、アズ・ファンクション — にデプロイ可能であるため、APIゲートウェイは、適切なマイクロサービスへのルーティングという重要な役割を担うことになります。
APIゲートウェイはいくつかの領域において、マイクロサービスのニーズに応えるために進化しています。特に、最近のAPIゲートウェイは、
- 認証やレート制限、APIの公開、メトリクス収集といった、横断的なアプリケーションレベルの関心事を引き続きサポートしています。
- 従来のアプリケーションデリバリコントローラに見られたようなトラフィック管理機能を取り込んでいます。高度なロードバランシングやキャッシュ、オートリトライやタイムアウトといったレジリエンスに関するセマンティクスなどがこれに含まれます。
- リアルタイム・サービスディスカバリをサポートします。Kubernetesやサーバレス環境など、短命(ephemeral)な環境へのマイクロサービスのデプロイが増えているため、マイクロサービスの全インスタンスのネットワークロケーションの検索が重要になっているのです。
フルサイクル開発: クラウドネイティブなワークフロー
マイクロサービスで変わるのはアプリケーションアーキテクチャだけではありません。開発ワークフローも変わります。マイクロサービスでは、各チームがソフトウェアデリバリの権限を所持します。何よりも重要なのは、チームがソフトウェア開発ライフサイクルのすべて -- 設計から開発、テスト、デプロイメント、リリースまで -- の責任を負う、ということです。これらのチームをオンコール・ローテーションに参加させている企業もあります(いわゆる"You build it, you run it"です)。フルサイクル開発(full cycle development)とNetflixが呼んだことで有名になったこの開発モデルは、ソフトウエアの開発と提供の方法における変革です。
このようなワークフローの変化は、データセンタエッジにも影響を与えています。APIゲートウェイ(およびエッジスタックの他のエレメント)がマイクロサービスアーキテクチャに対応しなければならない、というだけではありません。エッジ全体が、フルサイクル開発チームによってアクセスおよび管理が可能なものでなくてはならないのです。今日のクラウドネイティブな時代においては、エッジ管理に関する2つの検討事項がおもに議論されています。
検討事項１: リリースとデプロイメントのスケールアップ
デプロイメントとは、運用インフラストラクチャ上にコード更新をインストールするプロセスです。リリースは、コード更新を実際のプロダクトユーザに公開するプロセスです。デプロイメントとリリースをひとつのオペレーション(いわゆる"リリース・イン・プレース"モデル)として扱う場合もありますが、この方法では、デプロイメントのリスクをプロダクトユーザに見せることになります。例えば、必須の設定パラメータに関するミスがエンドユーザの目に見える機能停止を発生させる、ということが、リリース・イン・プレースモデルでは起こり得るのです。2つのフェーズを分離すれば、デプロイメントのリスクがエンドユーザに露呈することはなくなります。
データセンタエッジは、リリースにおいて重要な役割を果たします。特定バージョンのマイクロサービスへのトラフィックフローを管理することで、エンドユーザに対してアップデートを実際にリリースする責務を持っているのです。さらに、最新のエッジサービスでは、カナリアリリース(一定割合のトラフィックを、新しいアップデートに対して徐々に振り分けていく)やblue/greenロールアウトといった、インクリメンタルリリースのストラテジをサポートしています。
リリースを調整するためには、フルサイクル開発チームがエッジをコントロールする必要があります。ルーティング(どのバージョンのサービスが運用トラフィックを受信するのか)だけでなく、重み付きルーティング(カナリアリリースで必要)やトラフィックのシャドウイング(テスト目的で、サービスのテストバージョン用にトラフィックのコピーを生成する)といった詳細なコントロールも必要です。開発チームにリリースとデプロイメントを管理させることで、高度に複雑なアプリケーションでもサポートできるように、これらのプロセスをスケールアップすることが可能になります。
検討事項2: サービスの範囲の監視
フルサイクル開発チームは、自分たちのマイクロサービスの運用にも責任を持つことが少なくありません。この成功に不可欠なのが、マイクロサービスのパフォーマンスをリアルタイムで可視化することです。エッジは、マイクロサービスに出入りするすべてのトラフィックを分析することによって、マイクロサービスの挙動に関する重要な洞察を提供します。これによってレイテンシやスループット、エラー率といったメトリクスの報告が可能になり、アプリケーションの動作状態に対する洞察を提供するのです。
これらのメトリクスを、アプリケーション内の他の場所で収集されたメトリクスと関連付けることによって、アプリケーション動作のエンド・ツー・エンドのビューを完成させることが可能になります。このような関連付けは、最近ではOpenTracingなどの標準を使用して、要求データに相関関係識別子(correlation identifier)を導入することで実現されています。最終的に、最新のエッジスタックが収集したこれらメトリクスはすべて、担当するフルサイクル開発チームに対して、カスタマイズ可能なダッシュボードとして公開する必要があります。
エッジポリシ管理
昨今のクラウドネイティブなワークフローの重要性を考えた時、フルサイクル開発チームは、どのようにエッジを管理すればよいのでしょうか？残念なことに、エッジスタックのすべてのコンポーネントは、伝統的な理由によって運用担当者が管理しています。また、運用上のインターフェースは、フルサイクル開発チームのアプリケーション開発者には機能不足です。その上、エッジコンポーネントは分離した形で運用されるため、包括的なインターフェースが用意されていないことが少なくありません。結局のところ、フルサイクル開発者はフルタイム運用担当者ではありません — 自分たちの必要とする部分でエッジ機器を操作できれば、それだけでよいのです。
幸運なことに、Kubernetesエコシステムが指針とヒントを与えてくれています。Kubernetesモデルでは、ユーザは自身の意図をポリシとして、YAMLベースの共通コンフィギュレーション言語で宣言します。従来のRESTやUIベースのインターフェースとは違い、宣言型モデルでは、ポリシをコード化してソース管理システム(GitOpsなど)で管理することが可能であるため、監査可能性、バージョン管理、すべてのユーザへの透過性といったものが実現します。さらにKubernetesモデルでは、複数のポリシファイルをクラスタ全体のポリシ構成に集約するという、分散型ポリシをサポートしています。Azure Applcation GatewayやKong用のIngressコントローラの開発で分かるように、このモデルはAPIゲートウェイでも採用されています。これらのプロダクトの管理には、当初はREST APIが使用されていましたが、宣言型パラダイムへのシフトによって過去のものになりつつあります。
分散型で宣言型構成のこのモデルをエッジにまで拡張することは、フルサイクル開発チームが自分たちのエッジポリシを、他チームとは独立的に管理する上で不可欠なものなのです。このポリシは、マイクロサービスのコードと合わせてソースコントロールで管理することができます。これによってポリシを実際の開発プロセスの一部として管理できるようになります。独立したコンフィギュレーションを別管理する必要はありません。
要約
過去数十年にわたって、エッジは単なるロードバランサから、APIゲートウェイやロードバランサなどを含むハードウェアとソフトウェアプロキシのフルスタックへと進化しました。この進化を促したのはアプリケーションアーキテクチャであり、最近ではアプリケーション開発ワークフローです。
今日のクラウドネイティブアーキテクチャには、フルサイクル開発チームによるアクセスの可能なエッジスタックが必要です。宣言型、分散型コンフィギュレーションとしてエッジの全機能を公開することによって、フルサイクル開発チームには、エッジのメリットを活用した開発ワークフローの促進が可能になります。この中には可観測性の向上や、デプロイメントとリリースの分離などが含まれます。最終的にはこれが、イテレーション時間の高速化、リリースの安定性向上、ユーザに提供する価値の増加などにつながるのです。
著者について
Richard Li氏は、Datawireの創業者のひとりでCEOです。Datawireは、Telepresence(ローカル開発環境)やAmbassador API Gatewayなど、Kubernetes開発を促進する人気のオープンソースツールを提供しています。氏はDuo SecurityやRapid7、Red Hatなど、複数のテクノロジスタートアップを渡り歩いたベテランで、Kubernetesやマイクロサービスの専門家として認知されています。ApacheConやMicroservices Practionner Summit、KubeCon、O'Reilly Velocityなど、さまざまなカンファレンスで講演もしています。氏はMITから、コンピュータ科学におけるBSとMEngを所持しています。