私とCDN、及びfastly meetup #2

私とCDNとedge computing

最近、CDN各種に続々とedge computing周りの機能が入っており¹ã€ç¾åœ¨ã«ãŠã„てCDNでどこまで何ができるのかみたいなことをよく考えており、仕事でもやっていきたいな、と考えている。 以下発表で フルCDNアーキテクチャ の提言をしてから3年が経ち、今ではフルCDNはかなり当たり前の選択肢としてそこにある、というかマイクロサービス間の通信もCDNを通すようなことまで行われる世界になっており純粋にすごいなと感じている(そもそも フルCDNとはなにか というのは私の中でも確たるものがあるわけではないが、イメージ的には動的なサービスにおいてもすべてのエンドポイントをCDN経由で返し、ある程度柔軟なキャッシュのPurgeを行うようなものを想像している^{2 3})。

speakerdeck.com

上記、私は提言するだけしたが、その後そこに強く取り組もうとしてこなかったのに若干の後悔がある(動的な部分もTTL0で全部CDNを通す、のようなことはやったりはしていたが)。

CDNに限らない、様々な意味でのedge computingという文脈では、以下さくらインターネット研究所のビジョンを見ても、これはすべてがユーザの近くとしてのedgeとして動きながら、それぞれが必要に応じて協調していくという話であり、夢広がるなぁなどと思いつつ見ている。 research.sakura.ad.jp

また、話は変わるが私はJSを前職でゲームを作るなど書きまくっていたりした。CDNのedge computingとフロントエンドは親和性が高いと思っており、そういう意味でも私はここに取り組むべき人材なのではないかと感じている。 CDNでのedge computingはどこまでfrontendの話題と言えるのかはわからないが、edgeで計算させることによるレイテンシ短縮やBFFとしてのedge computing等、フロントエンドの必要とする世界のためのグルーとしてCDNのedge computingを捉えることもできると思っている。そもそもどこまでがフロントエンドにまかせてどこまでをedgeに任せるか、どこまでをオリジンに任せるかというところから様々な組み合わせが考えられ、まさに大変夢の広がる話である。 エッジコンピューティングを活かしたウェブアプリケーションホスティング構想 - ゆううきブログ ã‚„ 超個体的DBクエリキャッシング構想 - Speaker Deck などを見ても、 edgeにそこまでやらせるか〜 と大変おもしろく、更に夢が広がっていく日々である。

というわけで、CDNのedge computingをやっていくぞとなったはいいが、では実際に何をやっていくのか、と思っていたらうちのチームのテックリードが"これdekokun好きそう"と言って以下URLをくれた。訳してみたところなかなかおもしろく、扱っているものがWebAssemblyということもありちょうど最近私はRust + WebAssemblyのアプリ作ってたしまずはfastly + edge computingを見ていこう、となったのであった。

www.fastly.com

上記URLの内容は、かなり雑に要約すると以下となる

• fastlyはlab立ち上げていろいろやってるよ、Terrarium,っていうプロジェクトが熱いよ。これはWASMベースのエッジコンピューティングプラットフォームだよ。早くて安全だよ
• Tettariumはsystem callの実装が多くなく、std libのほとんどが使えない。副作用の起こし方はhttp_guestというライブラリを使ってやってね
  • KVSも使えたりするよ
• その後、http_guestの具体的な使い方の説明が続く

なお、Terrariumはログインなどなしで誰でも気軽にwasmアプリ(という表現が適切だろうか、wasmで動くサーバサイドアプリ？)をデプロイできるから皆試してみるといいよ。

wasm.fastlylabs.com

などというわけで、Fastlyには今非常に注目しているわけです。 で、 Fastly Yamagoya Meetup 2018 に参加して最高と思ったり、最近はFastly Meetup #2に参加したりしました。以下、fastly meetup当日メモ。上記Terrariumの中で動いているLucetについての話もあって嬉しかった。

fastly meetup当日メモ

Intro

• 営業のToshi Aizawaさん による、fastlyの紹介とデモ

Fastlyのメリット

以下、デモをしながらリアルタイム性を見せてくれたんだけど、キャッシュのpurgeが本当にすぐだったし、logもアクセスしたら数秒でpapertrail上に流れてきたし、設定変更の内容が反映されるも、35秒くらい(いつもは10秒とかもっと早いとのこと)、というのを分かりやすくデモしてもらえていて大変うまいデモだった。 設定変更は、35秒だとしても、かなり早いという印象(私の触ったことのあるCDNと比べて)

メモ

• リアルタイム
  • instant purge
  • log streaming
  • config change
• cloud native(easy to manage)
  • api first, api everything
    • ので、CI/CDに組み込みやすい
• パフォーマンスがいい
  • キャッシュヒット率が高い

How we build Fastly with Fastly

Tatsuhiko Miyagawaさんによる、Fastlyで動いているFastlyのコントロールシステムの裏側についての話。 Fastly Yamagoya Meetup 2018で話されていた内容とほぼ同じ内容(と本人も最初に言っていた。 fastlyの裏側でfastlyが動いているというのが面白い。fastlyが全体的に障害に陥った時に裏側も一緒に死ぬので大丈夫なのだろうか、というのは気になった(質問すればよかった)。 VCLのテストは同じ設定をもう一つ作るのがベストプラクティス、というのはAPIで操作しやすいからこその選択肢だなと感じた。

メモ

• fastlyのAPIはfastly上で実装されている
  • VCLでroutingしている
• 最近、APIのbackendを切り替えた
  • 古い方から徐々に新しい方に流して最後にshutdownする
• APIのroutingサービスもfastlyに全部のせた。chefでデプロイしていたのがterraformでデプロイされている
  • 確率的にAPIを古いbackendに流したり新しいbackendに流したりした
  • 新しい方にヘルスチェックを入れておいて、ヘルスチェックを落とすことで戻す、みたいなことも可能
  • A/Bテストで、例えばヘッダにユーザIDとか入れて、それをsha256で振り分けるとかできる
• fastlyの行っているcanary deploy方式
  • 火曜日と木曜日にデプロイしている
  • まずcanary サーバにデプロイ。リクエストにcanaryのヘッダが入っていたらcanaryバックエンドに飛ぶように
  • 普段はproduction clusterを見ている。canary リリースの際はcanary クラスタにリクエストが飛ぶようになる。HTTPヘッダでcanaryに飛ばすなどがfastlyで可能。その場合、varyでそのヘッダを定義してあげる必要がある。これによってキャッシュが分離されてcanaryが変な動きしてもproduction側には影響を及ぼさない
• configを各edgeに対してどのように配信しているか
  • pull型。edgeがcontroll planeにpollしている。何かが変わったタイミングでキャッシュがpurgeされて新しいものを取得できるというモデル
  • fastlyのキャッシュサーバはリクエストをthundering herdを防ぐ機能としてクラスタリングしているため、pull型でも TTLが切れた/キャッシュpurgeした瞬間にoriginに大量アクセス のようなことは起きない
    • クラスタリングは何も設定していなくても勝手に有効になっている。
      • (ここ、若干本当にこれで正しかったか確認したい。特にshieldに関する理解が曖昧) objectのハッシュ値を調べてmasterを調べてそこに投げる。その後もう一段階同様のことをして、originに投げる。originへのリクエストはshieldからしか来ない、ということもできる
    • shieldについて参照： オリジンシールド - パフォーマンス・チューニング | Fastly Help Guides
• optimizing delivery
  • VCLのbinaryへの変換を全てのedgeでやっていたがもったいないので、binaryを作って配信するようにしている
  • routing service(fastlyのedge cloud自体のことを指している)がcompiler serviceに問い合わせ、compiler serviceがroutingにVCLを問い合わせ、control planeからVCLが返され、compilerがbinaryに変換してedgeに返す
  • node, pop, customer毎に少しずつbinary直接取得へ変更していった
  • edgeが、"おれはbinaryを受け取れるぜ"というのをaccept headerで表現。accept headerで渡してもテキストが返る場合もある(control planeがその判断をする)。routing serviceはcontrol planeにbinaryを返すか確認し、カスタマーやサービスのfeature flagをみてyesだったら、binaryを返すようにする
    • accept: varnish-soであり、かつ、compiler_service.healthyであればcompilerに行く。つまり、compilerのヘルスチェックを落としたら全部戻る
• (質問) vcl反映する時に行われること、vclのテストの仕方について
  • syntax checkでapiからエラーが返る
  • vcl自体をローカルでテストするのは一筋縄でいかないので、同じ設定を持つ別のサービスを作ってそこにリクエストを送ってテストするのがベストプラクティス
  • vclFiddleというサービスでチェックすることもできる
  • fastlyではapiのデプロイはterraformを使っていて、そこにPRを送ってマージされるとデプロイされる

Introduction to Lucet

ここが今回一番聞きたかったところであったが、もう体調不良と英語と内容の難しさによりほとんど頭が理解できなかった…英語の部分は同時通訳さんいたんだけど、同時通訳ありの発表に慣れていなかった、というのもある。

メモ

• CTOより
• 少人数のリサーチチームを率いている
• terrariumはlucetで動いている
• lucetの内部構造について
• lucetはcompiler
  • lucetはruntimeでもある。安全と分離
  • lucetはツールセットでもある
    • プロファイラ・デバッガとの統合も考えている
• wasmには、静的型付けの個人的上位のTS, Rust, Cの3つが合理的、好き
  • wasmへのコンパイルはlucetの外で行われる。assemblyscript, rustc(Rust), llvm(C)
• wasiというスタンダードをmozillaと作っている
  • wasmの外界へのinterfaceがそれぞれのcompilerで別の取り組みをしている。wasiがなんらかのインターフェースを与える、posixなどと似ている
• wasmでedge computingを考えている
• lucetはブラウザの外でwasmを動かす場合の答え
• wasm -> lucet -> native code
• AOT compilerによってelfオブジェクトファイルとなる
• lucetc はlucetのcompilerサイド
  • wasmのparser -> verifier(compileしようとしているものが有効なモジュールなのか、有効じゃないと危険) -> translator(wasmのbyteコードを中間表現に) -> codegen -> artifact(metaデータに沿ってパッケージ化) -> runtime
• 上記のcodegenはcranelift(コレ自体がverifierのような動き)が行う。craneliftはmozillaと共同開発
  • verifier(中有感表現が正しいか) -> preopt(最適化) -> legalizer(native code生成の起きているところ。特定のプロセッサでコード認証(legalize)が行われる。machine codeと1対1のマッピング) -> postopt(特定のアーキテクチャをターゲットとして最適化。いくつかのload/storeを統合してsingle instructionにする、とかがよく行われる) -> register allocator(すべてのシンボリック変数を取り込む) -> branch relaxer(説明は割愛。メモリの最終コードをどのようにレイアウトするか)

• runtime

  • metadata, globals, linear memory, guest stack, signal stack のようなメモリの細部のレイアウト。数千、数万の並列処理ができるように

• なぜこれをわざわざするか？

• お客に最新のedge computingを提供したかったが、パフォーマンスと安全性に多大なる配慮をしていて、提供したい機能を提供できてなかった。安全性とパフォーマンスを両方できるテクノロジーがなく2年前に作り始めた、lucetとしてopen sourceで作り始めた OSXのサポート。x86-64のみで現在は実行。fastlyはintellのプロセッサのみ。

lucetのlive demo

• lucetとwasiがどんなふうに動くか(注：以下、dekokunは全然理解せず機械的に前に写ったものを書き写したのみである
• fastly/lucet: Lucet, the Sandboxing WebAssembly Compiler.
• helllo.cをまずwasmにcompule。 wasm32-unknown-wasi-clang hello.c -o hello.wasm
• wasm-objdump -h hello.wasm
• wasm-objdump -xj function hello.wasm
• lucetc-wasi hello.wasm -o hello.so
• lucet-objdump -t hello.so | grep "F .text" # ノーマルなelfファイルに
• lucet-wasi hello.so

質問

• cranliftとlucetの違い。
  • cranliftはlaw levelで安全性の保証ができていない
• コンテナで走らせるのと何が違うのか
  • v8やコンテナと比べて軽量、大量のインスタンスを高速に起動できる

LT

残念ながら体調悪くて早退…聞きたかったネ…以下、流れていた発表資料に対する感想。

blog.spacemarket.com 私もCookieを見てキャッシュを出すかどうかの実装をしたことがある。非ログイン状態のキャッシュ、テレビや突然の検索流入対策などに圧倒的に便利。それが自前でコンポーネントを用意しなくてもVCL書いてCDNで動くのはやっぱ圧倒的に嬉しいよなぁ。

speakerdeck.com 404がキャッシュされて大変ってのは、あるある…対策部分にも書いてある2つがまさに重要な対策だなぁ。誰でもいつでも簡単にハマる罠だと思うので今後私も気をつけよう…

最後に

上記2本の内容は別記事にしても良かったが、fastly meetup中にどんどん体調が悪くなりあまり内容が理解できず、最後は途中離脱したので書くことがあまりないというのもありコンテンツ2本立てにした。関連のある内容だしまぁいいだろう。

更に最後に

CDNのDはdekokunのDです(と最近社内で言い続けている。id:papix さんが考えてくれた最高の標語。ありがとうございます。まだ実績は伴っていないので実績作っていきたい

---

1. 例えば、 エッジコンピューティングに向けた分散キャッシュ技術の調査 - ゆううきブログ にはAWS Lambda@Edge2，Cloudflare Workers3，fly.io4の例が出ているし、本エントリで扱うfastlyのTerrariumもその一つである↩

2. 光を超えるためのフロントエンドアーキテクチャ - Speaker Deck のCache Awareな設計参照↩

3. もっといい名前募集中。ってかこれを書いていて上の脚注の Cache Awareな設計 でいいんじゃね？という気もした。CDNにこだわる必要もなさそうな感はある。↩