Fastlyの相澤さんと、CDNについてのお話

相澤: はい。私なんですけども、Fastlyでセールスエンジニアをしている相澤 俊幸といいます。元々ソフトバンクに2001年頃在籍していて、その時にソフトバンクグループの会社として大手CDNベンダーの日本立ち上げメンバーとしてJOINしました。それ以来、複数のCDNベンダーに勤務して、Fastlyで4社目になります。他にもユーザー企業の方でCDNを担当してたということもあって、かなりCDNとは長い付き合いをしているんですね。

永野: 相澤さんと初めてお会いしたのは、やっぱりアカマイだったですかね。

相澤: おそらく、はい。そこで私も社員ではなくて、お手伝いをしてる時があって、その時にお会いしたのが最初だったんじゃないかなと思います。

永野: そうですよね。一緒にちゃんと仕事したってあまり経験なかったりするんですけど、なんとなくお互いを知ってますみたいな感じですよね。

相澤: そうですね。同じオフィスにいたことがある、アイツいたな的な、お互いそんな感じなのかなって思っています。

永野: キャリア的にはずっとCDNと関わられているんですか。

相澤: はい。キャリアの中でCDNが一番長くなってますけども、その前はWeb、ソフトバンクにいた時もそうですが、Web開発者として、CDNの前は、コードを書く役割でWebに携わっていました。

永野: じゃあプログラミングとかもやられてたんですね。

相澤: その通りですね。これが横滑りで、開発者の方を相手にする仕事に変わってきた感じです。

永野: なるほど。CDNだとコーディングというよりは、XMLとかスクリプトみたいなものをコピペするような作業が結構多くなってくるのかなっていうふうに思うんですけど、アーキテクチャだとか。キャリアを変えられた時に、どういう風な心境の変化があったりしましたか。

相澤: そうですね。それで言うと、開発者を辞めようとか思ったりした訳ではないです。実はソフトバンク入った時に狙いがあって、2000年頃ある意味バブルの頃なんですけど、わりと海外との合弁を立ち上げて、アメリカのビジネスを日本に持ってくるみたいなことを沢山してたんですよね。当時だと、Aribaとかいろいろあったような気がするんですけど、そういったところに携わってグローバルな仕事をしたいって思ってたんですよ。それを狙ってソフトバンクに入って、合弁を立ち上げる一つであったアカマイに手を挙げてそっちに入った。なので、コード書くのを止める、開発者じゃなくなるっていうよりは、グローバルな仕事をしたいっていう流れで今に繋がっています。

永野: なるほどそうなんですね。ありがとうございます。いま働かれているのはFastlyということで、HerokuもAdd-onマーケットプレイスで、パートナーとなっていただいているんですけれども、Fastlyに出会ったのはどういったきっかけですか。

相澤: はい。これも面白いと言えば、話すと長くなっちゃうですけど、実はですね、僕Fastlyに入ったのは2015年で、その前の仕事は、直前の仕事は英語の先生だったですね。ちょっとここは突然どっから英語の先生になって、また戻ってきたのかっていうところが不思議な話だと思うんですけども、僕はその時は完全にフルタイムの英語の講師で、そのままずっとその仕事を続ける予定だったんですよ。あの実は声かけて貰った時、一度断ってるんです。ただFastlyっていう話を聞いてちょっと調べてみると、非常に面白い。CDNって自分の知った世界なんだけど、全然アプローチが違っていて、こんな会社があるんだっていうので、「やっぱりこの間の話ちょっと待ってくれる。断ったけど、話聞かせてよ」みたいな感じで、2015年にFastlyに入社しました。

永野: なるほど。ちょうど僕もHeroku始めたのは2015年ぐらいだったので、その時にキャリアチェンジっていうタイミングが一緒だとは思うんですけど。僕はもうCDNに携わっていた時から6年以上経ってるので、CDN業界の知識が追いついてなかったりするんですけど、Fastlyの特徴っていうのはどういったものがあるのでしょうか。

相澤: はい。そういった意味で言うと、CDN、コンテンツ配信ということはこれまで何回も出てきてますけども、Fastlyは自社のサービスのことをエッジクラウドって呼び方してるんですね。 我々自身では、CDNっていう表現はしていないんですよ。ここに込められてる意味っていうのは、単なるキャッシングとか、俗に言われるCDNというサービスではなくて、それをもっと超えた、色んな目的で使えるものという位置づけで、エッジクラウドって呼び方をしているのです。

永野: なるほど。ではそのエッジクラウドっていうものの中には、コンピューティングだとか、キャッシング以外のことも含まれてるっていうような位置付けなんですかね。

相澤: そうですね。そういった意味で言うと、代表的なものとしては例えばセキュリティもそうですし、コンピューティングというのも、特にこれからリリースしていく Compute@Edge、これも時間取れれば今日是非お話ししたい内容なんですけど、コンピューティングにもより足を踏み出していく、どんどんそこを攻めていくっていうのが、Fastlyのこれから狙ってる部分です。

永野: なるほど。実際にユースケースとしては、やはりキャッシングっていうところで沢山ユーザーさんがいらっしゃると思うんですけれども、今だともっと、ユーザーの特徴としては、Fastlyを使ってセキュリティを高めたりだとか、もしくは例えばWeb配信をより早くするだとか、そういったことにもシフトしているっていうような位置付けなんでしょうか。

相澤: おっしゃる通りですね。そういった意味では事例を使ってお話させていただくとそこがわかりやすいと思うので、メルカリさん。メルカリさんはFastlyをもう3年、4年近くおそらく使っていただいているんですね。御存じの通り、アプリベースでフリーマーケットというサービスを提供されている会社で、ここは説明要らないかもしれません。Fastlyをもちろんキャッシングにも使ってます。でもそれだけではなくて、例えばロードバランスだったりマルチクラウドっていう切り口で使っていただいたり、もしくはさっき言ったセキュリティですね。WAF (Web Application Firewall)としても活用いただいている。あとは画像の最適化。画像をEdge側で、Fastlyの方で最適化して配信をしていくなんていう目的でも、使いこなしていただいている会社がメルカリさんです。

永野: 僕、最近メルカリユーザーになったんですね。本当に今週、配送をしたんですけど、非常に使いやすくて良かったです。メルカリさんだと、モバイルユーザーがメインになるのかなというふうに思うので、CDN側としては、ドコモだとかソフトバンクだとかというキャリア相手みたいな感じでの扱いになるのかなというふうに思うんですけれども、そのモバイルをメインにされているサービスに対しての特別な対応みたいなものもやられてたりしてるんでしょうか。

相澤: それ非常に良い質問だと思うんですが、モバイルに対して配信をしていくっていうことになると、そのコンテンツ配信の仕方としては、よりモバイルキャリアに近づいて、より近くから配信していくっていうのは、これコンテンツ配信、CDNとしてはある意味王道のやり方だと思います。ただこれはCDNとして古典的なアプローチで、ユーザーの近くから配信する、エッジから配信する、これも正解なんですが、実はFastlyちょっと新しいアプローチを取っていて、コンテンツ配信っていう仕組みの中ではFastlyは集中型の戦略を取ってるんですね。どういうことかって言うと、キャリアの中に入れていくユーザーに近づいていくってやり方ではなくて、日本国内では実は三箇所の配信拠点しか持ってないというアプローチを取っていて、おそらく今、永野さんが頭の中で想像していたアプローチとはちょっと違うんじゃないかなという風に感じました。

永野: なるほど。つまりアカマイに僕がいた時代っていうのは、とにかくエンドユーザーの近くにサーバーがいっぱいあるので、速くなりますよ、（キャッシュ効率が）良くなりますよみたいなアプローチだったんですけど、それが日本の拠点としてもそんなにいっぱいサーバーを色んなところに用意するのではなくて、集中した中で管理をしていくっていうようなアプローチを取られてるっていうことなんですかね。

相澤: おっしゃる通りです。なぜFastlyがそういった選択をしてるかっていうと、おそらく２つ、そこに補足できると思います。１つ目は、例えばアカマイサービスが生まれたのは90年代末、もしくは2000年前後ですが、その当時配信する上でのボトルネックって、ラストマイル、ユーザーの近くだったですよね。それを踏まえると、ユーザーの近くから配信するというアプローチは非常に正解だったと思います。その一方で、今ボトルネックどこにあるかっていうと、必ずしもラストマイルではなくなってきてると思うんですね。例えば当時は常時接続っていうのも非常に限られていたし、ブロードバンドという言葉が出始めたぐらいかなと思いますが、今はもうブロードバンド当たり前、常時接続が当たり前、ボトルネックは実はエッジの方ではなくて、色んなところに、例えば場合によってはデータセンターの中かもしれないっていう風になってきています。このインフラ構造の違いが、集中型がより有利になってきているというのが一つの理由です。

永野: なるほど、まあそうですよね。2014年ぐらいの時でも、トレンドとしてはそういうような形になってるなっていう印象があります。例えばブラウザ自体が一つのコンピュータみたいな位置付けになっていて、色々なものをまずダウンロードしてきたら、そこのローディングだとかそういうものに関しては、全てモバイルの、スマホのパワーに依存してしまうような、そういうような状況になるので、ミドルマイルはあまり関係ないなっていうような位置付けでしたし。サーバーサイド側でさまざまなスクリプトとか利用して、他のサーバーと接続していくっていうところが増えてくるっていうところがあったので、これはもうセンター側というか中央側で処理してあげた方が、より高速化だとかセキュリティ性を高めるっていうことが管理できるのかなっていう位置付けはあったと思うんですけれども。それをFastlyの創業当初からコンセプトに置いてるといったイメージでよろしいでしょうか。

相澤: はいそうおっしゃる通りです。Fastlyは創業が2011年なので、2011年という時点でそこからスタートして、じゃどんなネットワークが最適なのか、もしくは2015年、2020年を見据えてどうかっていうことを考えて、そういった流れで今の集中型の構成を取っていると思います。また永野さんが仰られた、ネットワーク構造が違うだけではなくて、アプリの作りも変わってきてますよね。それも集中型がより適しているという背景になってるかと思います。

永野: なるほど、ありがとうございます。僕がそのFastlyを知った時っていうのは、2012年とか13年とか、元アカマイの福田さんとかがFastlyっていう会社を始めましたぐらいな時に知ったんですけれども、（注: 福田さんは2016年にFastly入社なので、別の方と勘違いしました。）その時にバズっていたのは、パージが早いっていう、つまりキャッシュしたコンテンツがすぐに消せるっていうようなところがあったと思うんですけれども、これもやっぱり集中型アーキテクチャを取ってるからそういったことができるっていう感じだったでしょうか。他に何か技術的な特徴ってありますか。

相澤: はい。技術的な特徴、Fastlyらしいところで言うと、パージの早さっていうのは、これはもう絶対にお伝えしないと帰れない感じがしますね。ただ、そのパージが早いのは、集中型だから、例えばサーバーの台数が少ないから、拠点の数が少ないからパージが早いかっていうと、実は必ずしもそうではないようです。これはその少ない台数という以上に、元々のアーキテクチャー設計が違っている、考え方の違いって言った方がより正確だと思います。

永野: 例えばアカマイとかだと、そのTTL (Time-To-Live)設定で、ブラウザからもう一回聞かれた時に早めに消してあげるよりは、更新があるかサーバー側に聞きに行きますよみたいなことで調整をしてたと思うんですけれども、そういったことじゃなくて、とにかくすぐに消してくれってサーバー側に指示をしてあげれば、一瞬で消えてしまうっていうのが、あんまり僕の頭では理解ができなかったりするんですけど、これはどういうふうなメカニズムなんですか。

相澤: はい、メカニズムということで言うと、あの実際にはですね、ゴシッププロトコル (Gossip Protocol)っていう、コンピューターサイエンスの世界で、恐らくそっちの背景がある方はご存知の情報かもしれないですけれども、少しぶっちゃけていうと、サーバー間でお互いにメッセージを投げ合って、急速に短い時間でサーバネットワーク全体に展開されるっていったような仕組みを使って、実際に実装してみて我々150msでネットワーク全体からコンテンツをパージ（消去）することができるという仕組みになっているんですが、そこがキモなようです。なので、今実際にはグローバルで拠点数が72拠点、サーバーの数で言うと大体2500台なんですけれども、これ数が少ないから実現されている訳ではなくて、そのゴシッププロトコルを選択して実装したタイミングで、これがネットワークの規模が大きくなっていても、この150msっていうのは維持できるという風に聞いてます。

永野: なるほど。つまりFastly内部で各サーバー間で、さまざまな技術を使って早くしているっていうところが、基本的なキモになるって位置付けなんですかね。

相澤: はいその通りですね。プロトコルがキモで、その集中型、台数が少ないというところは実は関係ないんだよっていうことです。

永野: なるほど、ありがとうございます。これから新製品を出されていくというふうに思うんですけれども、今アナウンス予定のものだとか、発表されている製品のことについてご紹介いただけますか。

相澤: はい、新しい、これから出る製品で、ユーザーの方も御存じの方は期待しているもの、また内部でですね、実際に製品紹介して販売している立場でも、凄いエキサイティングなものが２つあるので、それぞれ話しさせてください。 1つ目がCompute@Edgeという製品があります。これ今プライベートベータという形で、一部のお客様に試していただいてる、そういったフェーズの製品なんですが、これは一言で言うとサーバーレスの製品。皆さんが御存じのAWSのLambda、もしくはLambda@Edgeに非常に似通ったサービスです。

永野: Lambdaでサーバレスって聞くと、僕の理解では必要な時に必要なインスタンスが立ち上がってくる、もしくは必要な時だけ利用ができるようなそういった位置付けで、インフラだとかサーバーというものを意識しなくて使えるっていうようなイメージなんですけれども、その理解であってますか。

相澤: はい。その特徴はサーバーレス製品という意味で共通です。なのでその理解で完全に合ってますね。

永野: それで実際に何ができるようになるのでしょうか。

相澤: はい。FastlyのCompute@Edgeの特徴いくつかありますが、まず技術としてWebAssemblyベースで、これをサーバーレス環境で実現しているということが一つ大きいですね。

永野: ということは、何かしらの作業をさせるっていうことを、必要なときにキックしてくれるようなそういったイメージですかね。

相澤: はいその通りです。基本的にはWebAssembly、念のためにお伝えしておくと、主にブラウザ上で実行するために使われることが多いかと思うんですが、そのWebAssemblyをサーバーサイドで、もしくはエッジで実行できるようにしたっていうのがひとつのポイントになってきます。実はFastlyは、Lucetと呼ばれるオープンソースのWebAssemblyコンパイラかつ実行環境にもなるんですが、これをオープンソースとして開発していて、このCompute@Edgeというサービスのコアな実装に位置づけているんですね。こちらの方を活用していく。そして他のサーバレス製品、Lambdaもですけれども、と比べての大きな違い、もしくは優れたところは、コールドスタートの時間が非常に短いですね。他社さんの製品、大体説明を聞くと、スタートアップにかかる時間というのは早くてもミリ秒なんですが、FastlyのCompute@Edgeは、マイクロ秒単位で立ち上げることができるので、その立ち上げ時間というのは桁違いに速くなっている。なので、必要な時に必要なだけスケールできる。そしてパフォーマンスも非常に高いという特徴があるのが、サーバーレスの中ではCompute@Edgeの売りにしている部分です。

永野: なるほど。それを聞くとスケーラビリティという観点では凄く有効ですよね。ピーク性が高いトラフィック時には、本当に瞬時にサーバーの数を増やしたいっていうニーズは高いでしょうから。これができるのはすごいなという風に想像しますね。

相澤: そうですね。まだ私自身もそんなに触れていないし、限られたお客さんにしかご案内できていないですが、ここは本当にこれからエキサイティングになっていく領域だと思っていて。私自身まそこまで触れてないっていうのは実は大きな理由が一つあって、現時点でFastly、WebAssemblyという環境、WebAssemblyベースのサービスだということをお伝えしたんですけれども、実際に何を使って開発をするのか、開発言語という面ではですね、現在Rustだけをサポートしています。なのでCompute@Edgeを使うためには、Rustでコードを書かないといけないという縛りが現時点ではあるんですね。私もこのためにRust勉強していかなきゃとは思っているんですけれども、まだそれほど手を付けられていない状況です。ただ、じゃRustだけしかサポートしないのっていうことで念のために補足しておくと、今後の対応予定としてはType Scriptだったり、Go言語への対応を予定しているので、そういった意味では、今後より使いやすくなっていくことは間違いないかと思っています。

永野: そうですね。あまりRust使えますっていうWeb開発者の方って聞いたことがなかったりするので、結構まだハードルが高いのかなと思いますけど、これからGOだとかType Scriptとかを対応されることによって、様々なAPIを動かしたりだとかっていうのがあると思いますし、もっと重い処理だとやっぱりNode.jsだとかRuby、Railsみたいなものも対応してかなきゃいけないのかなという想像はしますが、そこまでになるのはちょっと、もう少し時間がかかるという感じなんですかね。

相澤: はいそうですね。恐らくですけれども、私の理解ではType、型とかっていったところを非常にストリクトに対応していくことが必要なので、俗にいうスクリプトへの対応というのは非常にハードルが高くなってる、実装する側としてハードルが高いのではないかなと思うんですよね。そういった意味で、Type Scriptというのは、そのWeb開発者の方にとっても比較的敷居が低いし、その型を重視する、こちら側のシステムにとってもそこはサポートしやすいという意味で、ある意味妥協点として、中間地点として非常に良い選択なのかなっていう風に個人的には感じています。

永野: なるほど、期待できる製品ですね。あとセキュリティに関しても、これから何か開発されたりだとか、提供されていくような予定はございますでしょうか。

相澤: はい。Compute@Edgeと並ぶ、もう一つのこれから出てくる製品なんですけれども、これがSecure@Edgeです。これは一言で言うと、Webセキュリティスイートと言ったらいいでしょうか、代表的にはWAF、プラス色んなセキュリティ機能を追加したものと考えればいいですね。FastlyではWAFすでに提供していて、オーバーヘッドが非常に小さくてパフォーマンスが高いっていうところが、高く評価いただいている理由なんですけれども、ただセキュリティっていうことになると、それだけではない、いろんな機能がお客さんから求められているという現実もあるかと思います。代表的なものとしては、例えばボット対策ですね。ボット対策とかクローリングの対策といったところも、「そこができないの？」って言われことが非常に多くて、そういった、より幅広いセキュリティニーズに対応していく製品としてこのSecure@Edge位置付けています。

永野: 先日買収についてもアナウンスされてたと思うんですけれども、それについてもご紹介いただけますか。

相澤: はい。まさにこのSecure＠Edgeの流れで、是非お伝えしたい情報ではあるんですが、買収したのはSignal Sciencesという、アメリカのカリフォルニア、ロサンゼルスエリアに本社がある会社なんですけども。実はこの会社、ある意味そのCDN業界の中でのFastlyに相当するような、Webセキュリティの中での、Fastlyに相当するWebセキュリティの会社といったらいいですかね。非常に会社のカルチャーとしても似ているところが多いのと、その次世代のWebセキュリティを提供しているという意味でも、似ているところが多い会社なんですけども。具体的な例で言うと、WAFを導入するっていう場合、一般的には導入当初はチューニングのためにモニタリングというモードで運用するというのが一般的だと思います。これはどういうことかって言うと、いきなりWAF有効にしてブロックしてしまうと、False Positiveという形で、本当はブロックしたくないものも間違ってブロックするということが起こりがちなんですよね。なので、一般的なWAF運用というのは、当初モニタリングモードで運用して、チューニングをした上でブロッキングするっていうのが一般的です。一方で、このSignal Sciences社のWAFなんですけれども、これはもう多くのお客様が初日から、導入した最初からブロッキングモード、ブロックするモードで運用するなんていうところがですね、非常に革新的なアプローチの会社なんですよ。そして実はこのSignal Sciences社の買収、先月（９月）に発表をして、そして今この話してる時点で先週ですね、１０月の頭に買収が完了しました。なので、ようやく一つの会社になったっていうタイミングなんですけれども、このSignal Sciences社のセキュリティ製品を、完全にSecure@Edgeの中に取り込んでいくという方向性になっています。まだまだ私も、一緒の会社になったばかりなので、これから学んでいくところではあるんですが、このSignal Sciences社の製品がSecure@Edgeに入るということが決まった時点で、僕の期待度っていうのはもう１０倍ぐらい膨らんだ気がしますね。

永野: そうですか。実際にFastlyさんのお話を聞かせていただいて思ったのは、やっぱり今までの単にキャッシングだとかっていうようなCDNの領域から、それぞれのWebアプリケーションに合わせて様々なカスタマイズをしたりだとか、アーキテクチャを変えていったりだとかっていうところに対応できるような製品を提供されているっていうところがメインなのかなというふうに思って。そうすると、プリセールスアーキテクトだとか、実際にお客さまを支援される方たちの作業っていうのがすごく重要になっているのかなというふうに感じました。やはり相澤さんがやられてるようなビジネスっていうのは凄く楽しいでしょうし、また大変なものなのかなという風に想像しました。

相澤: おっしゃる通りですね。楽しいっていうところはもうこの会社に入社して５年間ずっと感じるところですし、大変なところっていうのはいあの先程のCompute@Edgeのところなんかで、これは本当にやっていくのは大変だけど、でもやりたいっていう思いでその狭間で揺れ動いてる感じがします。

永野: もう毎日勉強しなきゃいけない状況ですよね。

相澤: そこはそうですね。この仕事、会社問わず、その側面はあるかと思うんですが、特にFastlyにいて2020年という今はその実感が非常に強いです。

永野: 今、日本法人って何名いらっしゃるんですか。

相澤: はい。グローバル全体では買収が完了して約800人という、800人台に突入しました。日本は、もうこの半年オフィスに行ってないのでちょっと実感はないですけど、恐らく30名をちょっと超えてるぐらいじゃないかなと思います。

永野: ああそうなんですね。まだHiringとかもされていたりしますか。

相澤: はい。Fastly、日本に限らず全体でも、日本でも急成長しているところなので、おそらくこの1年間で、おそらく1年前はまだ15人とかぐらいだったんじゃないかなと思うんですね。この1年間で2倍になっている。その成長はこの先も変わらないので、是非これを聞いている皆さんリスナーの方にもですね、Fastlyの求人情報をチェックしていただけると、皆さんのやりたいことだったり、向いてる仕事があるかもしれません。

永野: リモートで働くことも可能なんですかね。

相澤: おっしゃる通りです。元々このコロナが発生する前から、リモートフレンドリーで、リモート勤務をしているのはグローバルでもたくさんいるし、日本国内でもオフィスに基本的にこない人間は、30人中少なくとも5人はいたんじゃないかなと思います。そういった意味ではリモートフレンドリーな会社で元々あったですが、今はですね、来年前半、2021年の6月までは基本的にリモート勤務ということになっているので、そこまでは職種問わず完全にリモート勤務が可能です。

永野: そうなんですね。これ聞かれてる方で興味がある方、チャレンジしてみたい方は、是非ともFastlyさんの求人情報をチェックして頂ければと思います。相澤さん、色々お話を聞かせていただきまして誠にありがとうございました。

相澤: はい、今日はお時間ありがとうございました。