大規模APIと開発者の自律性の両立を図るNetflix

NetflexエンジニアリングマネージャのKatharina Probst氏とJustin Becker氏は先頃，同社のテックブログに，API環境における開発者の自律性の維持に関する記事を書いた。8月23日に公開されたブログ記事“Engineering Trade-Offs and the Netflix API Re-Architecture”の中で氏らは，コードとプロセスに対する開発者の権利と，API環境におけるチーム全体のサービス共有を両立させることの困難さについて考察している。

マイクロサービスの興隆と，ソフトウェアエンジニアリングコミュニティにおける自己完結型および自己維持型ソフトウェアスタック(例えば，Docketのようなツールによるコンテナベース開発の普及)の重要性の向上は，アプリケーションに極端な複雑性を加えずに多様なサービスのデータにアクセスしたいというユーザの意向と，ともすれば反発し合うものになる。マイクロサービスはそのコードの再利用やコラボレーションにおいて，業界の一般的なベストプラクティスとは複雑な関係にある。これは外部ソフトウェアであるマイクロサービス内において，新たな内部依存性が生成されることになるためだ。

記事の中で氏らは，“... 私たちは速度と所有権，コードの統合と再利用の最大化という，一見すると矛盾している技術的原則を両立させようと努力しています。”と書いている。APIは複数のサービス間のコミュニケーションを直接表現するものであるため，ひとつのチームがそのデータ利用を所有し，管理することには難しい部分もある。もしすべてのマイクロサービスがエンドユーザと直接通信するAPIを持ったとすれば，個々のマイクロサービス自身がエンドユーザの多様な要求に応えなくてはならなくなる。それぞれが完全に独立し，サービスの生産性の最大化を目指すことによって，システムの全体概念が損なわれる結果になるだろう。全マイクロサービスに対するバッファ層として機能する単一のAPIがあれば，そのAPIがすべてのユーザ要求に対するキャッチオール(catch-all)となり，実際のデータ利用方法を個々のサービスが管理する必要性は極めて小さくなる。

Probst氏はQCon New York 2016で，多数の自律的アプリケーションのニーズにより応えるためにAPIを変更する可能性があるという，Netflixの計画について講演している。Netflixには，さまざまなマイクロサービスと個々のAPIの間でオーケストレーションサービスとして機能する，単一のAPIが用意されている。このAPIは個々のマイクロサービスに代わって，1,000を越えるさまざまなデバイスからのユーザ要求を負担する一方で，システムに単一障害点を導入するという意味も持っている。このAPIがダウンすれば，関連する一部のユーザではなく，すべてのユーザサービスが影響を受けるのだ。Probst氏はコンテナを利用したAPIの将来バージョンで，このサービスへの影響のリスクを軽減したいと考えている。QConでの講演の中で氏は，“将来的に，多数の問題のひとつとしてスクリプトが持ち上がった時 ... ひとつのデバイス，あるいはひとつのデバイスのスクリプトが実行不能になった時でも，その他のデバイスやAPIに影響することはなくなります”，と述べている。単一のオーケストレーションを維持しつつ，コンテナによるプロセス分離によってリスクを軽減することにより，すべてのエンドユーザ向けマイクロサービスが通信するひとつのAPIだけをメンテナンスすればよいことになる。これにより，多くのマイクロサービスにとって悪評の高い痛点である，ツールやサービスの共有を行なうために最適なプラットフォームが手に入ることになる。

コンテナを利用してスクリプトを分離するというようなAPIに関する重要な決定の一部については，Probst氏が最終的に判断していたが，その他には最適な解決策でないものもあったのは間違いない。例えば，ブログ記事のおもな話題のひとつとして，複数のオーケストレーションAPIを用意して下位にあたるサービスによるコントロール範囲を拡大するか，あるいは既存APIが備えるロジックを削除してサービスグループ独自の論理層に移動し，データ層とその論理層がエンドユーザにサービスを提供するフロントエンドとして配置すべきか，というものがある。前者のアプローチでは，さまざまなオーケストレーションAPIのすべてを同期させることが難しく，複数のサービスグループによる共有ソフトウェアの障壁が生まれることになる。後者では，実際に追加されていない機能によるレイテンシ上昇を正当化することが難しく，サービス間のコントロールの明確な識別や適切な粒度が得られなくなる。ブログ記事には最終的な結論は明確に書かれていないが，どのような形であれ，さまざまなトレードオフによる妥協の結果になることが暗示されている。共通ツールやライブラリ，ユーザとの接続性などのニーズから，独立した自己完結型サービスは今後も増え続けると思われる。完璧なソリューションは存在しないだろう。