InfoQは先日，“I Love APIs”カンファレンスで講演を終えたDaniel Jacobson氏にインタビューする機会を得て，エフェメラル(ephemeral, 短命の)APIについて，エクスペリエンスベースのAPIとの関係や，企業がいつその導入をいつ検討すべきかなどを聞いた。
氏はNetflixのフロントドアで，1,000以上のさまざまな形式のデバイスから毎日送られてくる数十億というリクエストにサービスする，クリティカルなシステム開発のリーダを務めている。さらに氏は，ピーク時には北米のダウンストリームトラフィックのおよそ３分の１を占めるという，Netflixのプレイバックエクスペリエンスの管理も行っている。
InfoQ: Netflixでのあなたの役割と，日々の業務での責任について教えてください。
Daniel Jacobson: 私はNetflixで，サインアップや検索，再生に関して，世界中のすべてのデバイスから送られてくる全トラフィック処理に責任を持つ，最先端のエンジニアリングチームを運営しています。再生の面では，プレイバックエクスペリエンスをサポートする機能を担当しています。またAPIに関しては，デバイスから直接送られてくるトラフィックを処理し，中間層(mid-tier)データサービスの広範なセットからデータを取得した上で，データ返送を仲介する役割を担っています。プレイバックができなくても，あるいはAPIが使えなくなっても，ストリーミングは不可能になりますから，どちらのチームもNetflixの成功には不可欠なのです。
InfoQ: エファメラルAPIとはどのようなものなのでしょう，あなたが以前提唱していたエクスペリエンスAPIとの違いを説明して頂けますか？
DJ: エクスペリエンスAPIは，要求を行ったエージェントに対して，最適な応答を処理するためのものです。エファメラルAPIとは直交の関係にあります。つまりエクスペリエンスAPIは要求パターンとペイロードに関係が深いのですが，エファメラルAPIは反復処理に関係が深く，エクスペリエンスAPIを発展させるものなのです。
これまでAPIは，APIプロバイダがサポートしやすいように選択されてきました。その結果として生まれたのがフリーサイズ(one-size-fit-all)APIです。ただしこのアプローチには，幅広いユーザによる利用が困難であるという問題があります。表現を変えれば，このようなモデルにおいての最適化は，一部にとって改善であっても，大部分のユーザには改悪なのです。エクスペリエンスAPIの目標は，リクエスト個々のニーズを重視して，APIをそれぞれに対して最適化する，というものです。つまりこれは，さまざまなAPIを幅広く運用することに他なりません。結果としてAPIの変異性が高くなるため，APIプロバイダにとってはサポートの難しい環境になります。一方でAPIユーザにとっては，最高のパフォーマンスを得られる，自分たちのクライアントにとって最も都合のよいものを選択することが可能になります。最終的にはこれが，より優れたカスタマエクスペリエンスに転化されることは疑う余地がありません。
エフェメラリティ(ephemerality)は，私たちのAPI開発方法のストーリの一部ですが，エクスペリエンスAPIモデルにこれが必須という訳でもありません。エファメラルAPIとは，エンドポイントとペイロードが簡単かつ柔軟に消滅あるいは生成可能であると同時に，それが任意のタイミングで，さらには極めて頻繁にも可能であることを意味しています。エフェメラリティをサポートできれば，迅速なイノベーションが実現すると同時に，製品のニーズを継続的にサポートする上で，APIがボトルネックになることもなくなります。
例えばもし，SmartTVエクスペリエンスの新機能を評価するA/Bテストを実施しているのであれば，その機能を開発しているUIチームは，APIチームの関与なしでクライアントコードとAPIの修正を繰り返すことが可能になります。テストを開発するのは彼らですから，データ変更の必要性は判断できますし，最適化も可能です。その結果を反映して，エンドポイントの削除や新規作成を行うことになります。こうしたことをプロジェクトの過程において，(すべてのデータ要素がパイプラインに存在する限り)APIチームの関与なしに，何十回も行うことができるのです。
InfoQ: エクスペリエンスベースのAPIで，適当な粒度を見出す最もよい方法は何でしょうか？デバイス能力とチーム組織，どちらを基本とすればよいのでしょう？
DJ: その話題については以前，ブログ記事に詳しく書いたことがあります。その中で，エクスペリエンスベースのAPIを選択肢として検討すべき場合のレシピも紹介しています。これは基本的にスケールアップに関する問題ですから，ほとんどの企業は，このルートを選択する必要はないと思います。
それに対して，APIを使用するユーザと密接な関係を持つべく分岐した，さまざまなインタラクションモデルが存在しているのであれば，最適化の目標としてよい指標になります。緊密なフィードバックループを確立し，個々のユーザが望むものをより深く理解するには，APIの利用者に近づくことが重要なのです。
汎用的なリソースベースのAPIが違うのは，誰が，どのようにAPIを利用するのかが分からないということです。ユーザが組織内にいて，彼らのニュアンスを理解できるならば，彼らすべてのために最適化されたアーキテクチャを構築することも可能です。
Netflixにいる私たちは，アーキテクチャをJava APIセットとして開発しました。さまざまなデバイスを担当するすべてのチームが，自分たちのクライアントに最適化された，エクスペリエンスベースのWeb APIを開発できます。私たちのシステムは従来のAPIではない，API開発用のプラットフォームと呼べるものだと思っています。
InfoQ: NetflixのモバイルアプリAPIは，Android用とiOS用で別なのですか？
DJ: プラットフォーム構造の中にあるJavaベースのAPIは，JVM内のメソッドコールとして実装されています。その次にアダプタ層が，デバイス固有の方法で開発されたWeb APIの上に配置されます。つまり，アダプタを開発するモバイルチームには，それぞれエンドポイントや要求パターン，ペイロード，場合によってはプロトコルも独自のものがあるのです。
iOSとAndroidには，重複した部分がもっと多かった時もありましたが，現在ではこれらのエクスペリエンスがまったく異なっています。すべてに共通する関数もありますので，共有を可能にするためのツールセットも用意しました。
InfoQ: NetflixのAPIを記述する上で，API言語は使用しましたか？
DJ: 今のところ使用していません。 これについては定期的に議論していますが，メンテナンス上の課題やコストから，まだ実現に至っていないのです。言語記述子(language descriptor)を使用するということには，ほとんどの場合，処理の相違をその場で処理して，APIユーザに対して一貫性を持たせたいという意図があるはずです。私たちのAPIはエファメラルなので，そのためにもディスクリプタが必要になります。ですから，API言語の導入コストがさらに大きくなり，メリットがないのです。
もうひとつ考えられるのは，さまざまなニーズを持ってWeb APIを構築する数多くのチームがあって，それらチームがWeb APIを繰り返し利用する場合です。私たちは，配信データを継続的に変更する必要のあるA/Bテストをいつも実行していますから，この繰り返しも継続的に発生しています。イテレーションの実行では，同じ人物あるいはグループがWeb APIの記述と利用を行います。これらの開発は同時進行されて，彼らはインターフェースの性質をすでに知っていますから，API言語の採用に価値はありません。
記述言語に関する議論の大部分はJava APIレベルのものですが，先程も説明したように，このレベルは頻繁に変更されます。このようなAPIの一貫性に関する記述を極めて低いコストで実施する方法があるならば，ぜひ私たちのシステムでも採用したいと思います。ですが現状では，メンテナンスに要するコストがメリットを越えているようなのです。
InfoQ: API開発速度を向上するために，デバイスチームの開発したAPIツーリングを使用していますか。
DJ: 私たちが開発しているツールスイートは，APIスクリプトの管理，デプロイ，状態監視を実行し，その結果をエンドポイントの有効性の切り替えに反映するものです。これらのスクリプトに関するコードの共有性をサポートするためのツールや，ペイロードを調査するツールもあります。開発の必要なツールは他にもあります。例えば，デバッグ可能性は開発上の難しい課題ですが，この分野でも改善が必要だと思っています。
InfoQ: あなた方のメインWebサイトがUnversal JavaScriptに移行したことは，エクスペリエンスベースのAPIプラットフォームに合わせたものなのでしょうか？
DJ: WebサイトチームのアーキテクチャとAPIは，ほとんどのデバイスのそれとは違います。APIコールの前面に，それぞれが別の層を持っているからです。通常のデバイスではWeb APIを直接呼び出しますが，Webサイトでは，トラフィックを処理する自身のクラスタを直接呼び出した上で，データを取得するために私たちのクラスタをコールしています。彼らのクラスタやその上位で行われていることは，現時点では私たちから見ることはできないのですが，それでも彼らの記述したスクリプトが，私たちのアダプタ層で動作していることには変わりありません。
ここでお伝えしておきたいのは，私たちが現在，これと同じような構造あるいはそのサブセットを，さまざまなデバイスに幅広く適用すべきかどうか，調査している最中であることです。このアプローチを行うことで，プロセスのアイソレーションに加えて，デバッグ性の向上に向けて一歩前進できるのではないかと期待しています。
InfoQ: Netflix APIプラットフォームでは，Groovyなどのスクリプト言語はどのような位置付けなのでしょう？
DJ: アダプタスクリプトの記述に使用できる言語はGroovyだけですが，他の言語についても検討中です。次は多分，Node.jsになるでしょう。他のJVM言語をサポートするのは難しいことではありませんが，今のところ十分な要望がないのです。デバイスチームからScalaなど他の言語を使いたいという要求があれば，十分に調査した上で，実現に取り組みたいと思います。
Node.jsはJVMに統合して実行されないので，私たちのメインWebサイトでやっているような層の分離というメリットもあります。
InfoQ: そのような変更を開発フローに対して行うためには，デバイスチームは何をすればいいのでしょうか？
DJ: 企業の文化的な変革は，技術的な変更よりもずっと困難です。チームがこのようなルートを実行しようとしても，人々の同意を得て新しい環境で異なる運用を行うまでには，いくつもの課題があります。Groovyによる記述の導入も，あるいは関数型プログラミングのパラダイム導入も，それなりの時間が必要でした。振り返ってみると，それは間違いなくネットワークの勝利です。
InfoQ: 講演では，APIアダプタ層にコンテナを導入するという，進行中のプロジェクトに言及されていましたが，これはNicobarオープンソースプロジェクトにどう影響するのでしょう？
DJ: Webサイト層へのコンテナ採用を調査すると同時に，私たちはこれまで，他のデバイスに適用するにはどうすればよいのかを考えてきました。コンテナベースのモデルとしてのNicobarは，私たちにとっての中心的な存在ではないと判断しています。実際のところ，私たちがNicobarとそのスクリプト機能を設計した時には，スクリプトを分離した方法でデプロイする手段としてでした。コンテナは，私たちが元々持っていた意図を，その次のレベルにまで引き上げてくれました。その結果としてNicobarには必要性がなくなったのです。ただし私たちのシステムでは，今後数年間はスクリプトとNicobarのサポートを継続する予定です。これによって当面は，開発と発展が続くものと考えています。Nicobarの今後の展開では，このような変更部分についてもオープンソースプロジェクトにする予定です。
InfoQ: Netflixはこの８月に，オープンソースプロジェクトのFalcorを発表していますが，それをAndroidで利用する方法が先日公開されましたね。これは何を提供するもので，APIプラットフォームの拡張にはどのように関連するのでしょう？
DJ: Falcorは仮想JSONグラフを通じて，リモートデータソースを単一のドメインモデルとして表現するものです。クライアントのメモリでもネットワーク経由のサーバ上でも，データの所在する場所に関係なく，同じコードを記述することが可能になります。また，デバイスとサーバ間のネットワークコミュニケーションを処理し，要求のバッチ処理や重複性排除による効率を向上する働きもします。
Falcorはデバイスとサーバ間の効果的なデータフェッチ機構を備えているので，アーキテクチャ的に進化している私たちのプラットフォームでも，これまでと同じように重要な役割を果たしています。
私たちにとって特に大きなメリットは，開発の効率化とアプリケーションのパフォーマンス向上です。特にアダプタの記述では，アクセスパターンに高い一貫性があるため，開発効率の大幅な向上が実現できています。とは言っても，Falcorには急勾配の学習曲線があるので，デバッグ面では課題の多い環境ではあります。
InfoQ: AWS Auto Scaling Groupにはどのような制限があるのでしょう，また，Netflix Scryerはそれに対して，どのような解決策となるのでしょうか？Scryerをオープンソースにする予定はありますか？
DJ: AWSの自動スケールは，Netflixでは広く使用されています。とても便利ですし，パワフルです。ロードアベレージなどのメトリックに反応して，ある特定の値を越えると，新しいサーバの追加するタイミングだと判断する仕組みです。ただし，新しいサーバがオンラインになるまで，10～20分を要する場合があります。この間にさまざまな問題が発生する可能性があるので，可用性というプロファイルに新たなリスクが加わることになります。
Scryerを開発したのは，このような理由からです。Scryerは過去データの参照やリアルタイムデータのフィードバックループの取り込み，さらには，キャパシティ面で近い将来何が必要になるかを評価して，そのニーズを先取りしてサーバ追加などの処理を行います。Scryerを使うことで，ロードアベレージのスパイクが回避されること，クラスタによるトラフィックのより効率的な処理によって，レスポンスとレイテンシがはるかに平準化されることに，特に注目して頂きたいと思います。
Scryerは数年前のブログ記事で発表しましたが，現時点ではオープンソース化する予定はありません。
InfoQ: Netflix Engineeringで有名なのはChaos Monkeyサービスですが，Simian Armyに含まれるその他のサービスについて，もっと詳しく説明して頂けますか？
DJ: さまざまな処理を行うモンキースイートがあります。サービスをいくつかご紹介しましょう。
- Latency Monkeyはサービスにエラーやレイテンシを挿入して障害のカスケードを確認するために設計されたもので，さまざまなレベルで使用されてきました。現在は拡張されて，FIT(Failure Injection Testing/故障挿入試験)になっています。
- Chaos GorillaはChaos Monkeyに似ていますが，個々のインスタンスではなく，AWSアベイラビリティゾーンを停止します。フェールしたゾーンから正常なゾーンにトラフィックをリダイレクトすることで，ゾーン間で高可用性をテストするという考えに基づくものです。
- Conformity MonkeyとSecurity Monkeyは，特定の運用あるいはセキュリティガイドラインに準拠していること，そうでないものは停止されていることを確認するためのものです。
- Janitor Monkeyは，正常でない，あるいは停止したインスタンスをクリーンアップします。
- Chaos Kongは最近追加されたもので，AWSリージョン全体のサービス停止をシミュレートして，トラフィックを別リージョンにプッシュします。
InfoQ: Netflixは長年にわたって，たくさんのオープンソースプロジェクトをローンチしていますが，コントリビューションを活用する上では何が有効か，積極的にメンテナンスされるためにはどうすればよいのかを知る上で，最もよい方法はどのようなものでしょう？
DJ: OSS戦略を進めていく上で，私たちはUIやクラウド，ツールといったさまざまなカテゴリにわたって，合わせて約60のプロジェクトをリリースしてきました。その中には，他よりも積極的な管理が行われているものもあります。私たちはそれらを，開発者Webサイトで区別しようとしています。APIを直接サポートするためのツールも，ZuulやNicobar{/1, Histrix，RxJavaなど，さまざまなものがあります。
InfoQ: APIに初めて取り組む企業は，NetflixのようにフリーサイズAPIアプローチから初めて，段階的に発展させるのがよいのでしょうか，あるいは最初からすぐに，適切な粒度のエファメラルエクスペリエンス APIを手掛けるべきでしょうか？
DJ: APIに不慣れなら，OSFA(One Size Fits All)がよいでしょうね。もっとも，Netflixほどのスケールが必要になるのかどうかという問題はありますが。エクスペリエンスAPIはそれよりも難度が高くなりますが，どちらを選ぶにしても，エファメラリティは企業として心得ておいた方がよいでしょう。
エクスペリエンスベースAPIの方法を選択すべきかどうかは，機会とコストの関数になります。コストは余分にかかりますが，それに見合った効率の向上や最適化が得られるかも知れません。しかし，対象とするデバイスが少ない，開発チームの規模が極めて小さい，あるいはAPIを利用する外部パーティが広範に及ぶ場合にば，このような不安定な環境を運用するためのコストが，おそらくは回収できないものになるでしょう。
固定的なAPIを前に悪戦苦闘を強いられるがため，APIユーザの開発効率が阻害されている，と判断できる転換点を把握しておく必要があります。別の表現をすれば，もしもさまざまなデバイスチームがあって，お互いの差異がAPIコールを不効率なものにしている状況のために，パース処理やエラー処理を補完しなければならないのであれば，それらの追加に要するエネルギーをすべて，最適化されたインタラクションモデル開発に転化することは可能なはずです。ただし，この方法にメリットがあるのは，このように非効率な開発活動を行っている開発者の数が多い場合に限られます。
InfoQ: 開発者の作業効率以外に，エクスペリエンスAPIによって期待できるメリットは他にもありますか？
DJ: 最適化されたAPIセットを使うことで，システムパフォーマンスの改善や製品に変更を取り入れる速度の向上といった，優れたエクスペリエンスをユーザに提供できるソリューション構築が可能になります。
こういったエフェメラリティと最適化を望むのなら，パブリックAPIでは実現できません。エクスペリエンスAPIは優れた戦術ですが，プライベートAPI向きでもあるのです。APIユーザのニーズ解決に自由度を持たせることができるのは，少数の開発者チームによる親密な関係があってこそだからです。
InfoQ: API関連で今，最も注目しているものは何ですか？
DJ: 大規模APIを支えるコンテナやストリーミングデータ，HTTP 2.0, WebSocketと永続的接続, ツーリングや分析といったものに特に注目して，調査や実験を続けています。
その他，この分野に新しく登場したもの，例えばマイクロサービスや継続的インテグレーション，継続的デプロイメントなどはすでに実施しています。Netflixでは，マイクロサービスがそれぞれ特定の機能を備えるという分散アーキテクチャを採用しているのですが，成功したマイクロサービスは必然的に範囲が拡大されるため，時間が経つにつれてモノリス的になる可能性があります。その点からは，一度分解してやり直すことにも意味がありますね。
InfoQ: 最後に，継続的デプロイメントはエフェメラルAPIにどのように関連するのでしょう？
DJ: 私は自分のチームに，２つのパート間でデータを前後にプッシュすることを，砂時計の細くなった部分に例えてよく説明しています。太い部分の一方はAPIのユーザやUI，デバイスチームで，もう一方は分散されたサーバ側のマイクロサービスです。どちらも常に変化(A/Bテスト，新機能，新しいデバイスなど)しています。
太い部分が変化すれば，その製品をサポートするデータが細い部分を通って流れることと，その製品のすべてのテストが実行可能なことを確認しなくてはなりません。他のチームが作り出す変化を処理するためには，私たちのチームが社内で一番早く変化する必要があるのです。
７年前に私たちは，完全に自動化されたデプロイメントパイプラインの開発が，これを行う唯一の方法だと判断しました。継続的デプロイメントという観点から，リスクの低い，素早くロールバックする能力の高い方法で，迅速かつ頻繁にデプロイできることが，私たちにとって重要でした。それらすべてを実現するためには，ユーザに提供する製品の変更に関して，私たちがボトルネックであってはならないのです。
私たちのチームが行っている他のものと同じように，継続的デプロイメントは目的達成の手段です。その最後は，継続的な革新です。ビジネスやユーザのニーズに対して，迅速かつ定常的に変化できる環境を持つことは，エファメラリティに対する私たちの気持ちに強く結び付いています。