みなさんは「ネットワークチーム」というチーム名からどんな仕事を想像しますか？データセンターで物理的なネットワークを保守管理するような、いわゆるインフラチームをイメージされる方もいるかもしれません。メルカリのネットワークチームはそうしたイメージとはだいぶ趣きが異なります。クラウドとデータセンター、グループ間のネットワークをシームレスにつなぎ、アプリケーションデベロッパーが開発しやすい環境をつくるという、非常に広範な仕事をしています。

今回、この「ネットワークチーム」にフォーカスしていくのですが、お客さまとの直接的なタッチポイントが少ないこともあり、彼らの仕事のおもしろさ（それは技術面においても、取り組んでいる課題においても）を上手く伝えてこれなかったのではないか…？という素朴な疑問から企画はスタートしています。

メルカリPlatform CampのEngineering Headの中島大一（@deeeeeet）がファシリテーターとなり、ネットワークチームを牽引する、Raphael Fraysse（@raphael）と金丸洋平（@kanemaru）に、ネットワークチームの成り立ちやミッション、事業拡大するメルカリだからこその仕事の面白さ、技術的なトレンドから今後の展望まで、みっちりお話しを聞いてきました！

より良いお客さま体験の「縦軸」と、グループ各社の「横軸」をつなぐ

@deeeeeet：まずは二人の経歴を簡単に教えてもらえますか？

@kanemaru：私は大学院修了後、ネットワークエンジニアとして新卒でLINE株式会社に就職しました。メルカリと違いLINEは基本的にオンプレミスのデータセンター上に自分たちでインフラを構築する戦略をとっていて、入社後は物理的なネットワークの運用や構築などをしていました。その後徐々に運用の自動化や、既存のネットワーク機器に不足している部分を自分たちでソフトウェア開発して補うような取り組みを始めて、仕事の中心が物理の領域から少し高いレイヤーへと移っていきました。メルカリには2021年に転職しました。メルカリ入社後は、おもにクラウドやKubernetesのネットワークに関する業務を担当していましたが、最近はCDN（コンテンツデリバリネットワーク）やオンプレミスデータセンターに関する部分にも関わるようになってきました。

@raphael：僕はフランスでコンピュータサイエンスの大学に通っていて、同時に3年ほどプライベートクラウドのアドバイザーとして働いていました。そこでシステムとネットワークなど全体的にインフラを管理していました。卒業してからデータAIのスタートアップで働いた後に、日本に行くことを決めて、フランスの保険会社の日本支社に入社しました。そこでパブリッククラウドのプラットフォームの開発やマネジメントをリードするなど、全体的にインフラに携わりつつネットワークにも関係し続けました。とはいえコアビジネスは保険だったので、IT事業の会社に転職したいと思い、メルカリに入りました。

ちょうどメルカリはIPOのすぐ後ぐらいだったこともあり、すごく成長していたタイミングだったので刺激的でした。メルカリに入っていま5年目で、最初は全体的なインフラを担当して、2年半前に新たに組織されたネットワークチームに入りました。

Raphael Fraysse（@raphael）

@deeeeeet：そもそもネットワークチームはどういうチームなのか、どんなミッションやビジョンがあるのか話していきましょうか。

@raphael：はい。そもそも「ネットワーク」の定義は人それぞれに違うし、各会社でも違うと思いますが、僕が考える定義でお答えしますね。いまはインターネットで全世界が自律分散的につながっているのに、これが会社の中となるとなぜかネットワークがすごく複雑になってしまい、システム同士がうまく連携を取れなくなるという問題があります。これを解決するのがなぜこんなに難しいのかを常に考えています。昔は物理的なネットワークで個々に対応していましたが、いまはクラウド化のおかげでネットワークを一貫して作れるようになりました。会社の成長やお客さまのバリューにつながるネットワークを最適な方法でどう達成するかを考えてみると、アプリケーションやプロダクトとネットワークが一緒になって、end-to-endでより良いものにしていくことがすごく重要だと思っています。

以前はネットワークは物理的なことが中心的だったので、インフラにおけるバリューが、アプリケーションにおけるバリューとつながらないことが多かった。ネットワーク管理や開発をしている人たちの多くが、他のビジネスのチームとかなり距離を感じていると思います。やっぱり、もっと距離を近づけるきっかけが必要。ローレイヤーからアプリケーションまで、最終的にお客様の端末まで全てを一緒に支えていくような形になるべきだと僕は考えています。

@deeeeeet：少し具体的に説明すると、ネットワークチームが狙っていることは大きく2つの軸があると思っています。まずお客様のモバイルのアプリケーションから、僕らのサービスにつながるエッジに、そしてエッジからクラウドに行って、クラウドからさらに僕らはデータセンターを持っているので、データセンターまで一貫してサービスをつなげる“縦軸”にチームとして責任を持っている。

それだけではなくメルカリには、メルペイやソウゾウ、メルコインなど複数の会社がグループにあるので、会社同士のつながり、つまり“横軸”でも考えないといけない。“縦軸”と“横軸”の両方をどうつなげるかが、私たちネットワークチームのレスポンシビリティだと考えています。

Kanemaruさんが入社したのは、このネットワークチームができてからですが、前職のネットワークチームとメルカリの違い、ユニークな点はどこにあると思いますか？

@kanemaru：2021年の春頃、メルカリのプラットフォームグループのミートアップで、Raphaelさんがネットワークチームの取り組みを紹介していて、それで興味を持ったのが入社のきっかけなんですが、どこに興味を持ったかというと、先ほど触れていた2軸の長さがそれぞれ長いこと。

もちろん以前もend-to-endの通信について常に意識していましたし、横軸のたくさんの事業に寄り添うことにも関わっていましたが、メルカリでは一つのチームが全般に対してレスポンシビリティを持っている点がユニークだなと。それは良くも悪くもだと思うんですけども、きちんと全般に対して一貫性を持って取り組めそうなところが、そのときに魅力を感じた点ですね。

金丸洋平（@kanemaru）

@deeeeeet：実際に入ってみたらその辺のイメージはどうでしたか？

@kanemaru：そうですねえ…全部やってるなって（笑）。以前は低いレイヤーのネットワークに関わることが多かったので、それが最終的にお客さま、あるいは社内のバックエンドエンジニアにどう提供されているか、自分自身では直接実感しづらい面もあったのですが、メルカリではそこを意識せざるを得ないというか…。お客様や社内のバックエンドエンジニアにどう提供するのがいいか、常に考え実感しながら仕事するようになりましたね。

@deeeeeet：ネットワークに限らず、いわゆるインフラの領域は、ビジネスから遠いイメージもありますよね。ネットワークチームの母体となっているプラットフォームエンジニアリングチーム、というかメルカリのエンジニア組織は「お客様に対してどう価値を提供できるか」というのは昔から意識してるので、そのために「お客さまとの距離を遠くしない」という思想が反映されているんじゃないかと思います。Raphaelは昔からネットワークの世界にいて、メルカリのエンジニア組織に来てからの仕事の違いは感じますか？

中島大一（@deeeeeet）

@raphael：ひとことで言うなら、メルカリらしいエンパワーメントですね。何かレスポンシビリティを取りたかったら、失敗して何度も試して学習する、良くしていこうという文化がすごく強い。ただ、自分がレスポンシビリティを持つためにいろいろなことを理解しなくてはならないし、プラットフォームの一部だけを理解していても他の部分と上手くつなぐことはできない。だから、みんな知らないことや苦手なことにも取り組もうとしていて、それはこのチームのすごく素晴らしいところだと思っています。

@deeeeeet：そもそも、ネットワークチームの前身であるプラットフォームチームが、開発者に対して「プロダクティビティを高めるような基盤を作っていこう」というのを推し進めてきたチームだったという背景があるかもしれませんね。そこから分離してネットワークチームとなったから、いわゆるインフラの文脈から派生したネットワークチームではなく、プラットフォームエンジニアリングの文脈から派生して、進化したネットワークチームになっているので、チームとしての独自性が色濃く出てるなっていう感じがします。

例えば、デベロッパーエクスペリエンスを考えたネットワークを考えるとか、そういうことができるのはプラットフォームエンジニアリングチームから発生したからこそだなって、話を聞いてて改めて思いました。

セキュリティのベースラインを守りつつ、各チームの責任で使いやすい仕組みを構築する

@deeeeeet：ではここからは、今のメルカリグループの事業において、ネットワークの重要性がどんなところにあるのか語っていきましょうか！

@raphael：ある程度同じプラットフォームをグループ内の全社に提供しているような形になってますが、共通ではない部分もまだまだあります。同じグループ内であっても会社が違うと、異なるプラットフォームやスタックを用いていることがあって、困っているメンバーがいた時にサポートしづらいときがあります。とは言え、全ての会社にまったく同じプラットフォームを提供するのは難しいので、各社の要件とリミテーションにどうやってうまく対応するかが重要な課題です。各社が自分たちのやり方でネットワークを管理し始めると、グループ内の各社をつなげるのが難しくなっていきますよね。だけど、ネットワークが横軸でうまくつながらないと、結局成長がどんどん遅くなるし、コストがどんどん上がります。

なので、ネットワーク的にはできる限りローコストで、かつつながりやすい形に持っていこうとしています。結局のところ同じネットワークパターンになったほうが、最終的にグループ全体としてのコストが低くなるし成長をちゃんと支えていくことができる。それを実現するためには、ネットワークの基礎のレイヤーがちゃんとできていないといけない。そこで私たちが取り組んだのが、クラウドで同じShared VPCネットワークを使って全社がつながるようにすることです 。このおかげで、ローレイヤーのコネクティビティーを管理するのがすごくスムーズになりました。

参考記事：Network Architecture Design for Microservices on GCP

ここからは、どんどんハイレイヤー、アプリケーションをうまくつないでいくことがすごくコアな部分。最終的にはend-to-endでやろうとしてるから、どうやってうまくネットワークを管理しながら会社間をつなげるかに、いますごく注力しています。ネットワークに関わるコストをできるだけ低くして、デベロッパーはインフラのことに悩むことなくお客さまへ価値を提供することに集中できるようにしていく、そういうことをネットワークチームは進めています。

@deeeeeet：メルカリの事業はいま横に広がっている、そうした状況でメルカリというシステムをどう広げるかいくかに注力してるところがある。メルカリのエコシステムを展開するときに、スムーズかつセキュアに行うことが、いま一番期待されてしているところかなと思います。Kanemaruさんも、既にプロジェクトをいくつかやってきたと思うんですけど、具体的にどのような課題があり、それをどのように解決したのかを教えてもらえますか?

@kanemaru：具体的な例を一つ挙げると、ネットワークのセキュリティポリシーをそれぞれの事業会社ごとに適用するための仕組み。メルカリではサービスの運用にKubernetesを使っていて、GKEのクラスター上に基本的に全てのワークロードをデプロイしています。ただ、それぞれの事業会社やプロダクトはそれぞれ違うセキュリティ要件を持っていて、かつお互いに干渉しないようにする必要がある。例えば、1つの事業会社のサービスで何か問題が起きても、それが他の会社のサービスに影響が出ないように分離しなければいけない。一方で事業会社もプロダクトもどんどん増えていくので、細かな設定をネットワークチームが都度適用するのは大変だし、かといって事業会社の担当者が各自設定してくださいね、という運用も現実的ではない。

そこで作ったのが、ある事業会社に所属するサービスに対して、ネットワークチーム側が一度セキュリティポリシーを設定すれば、今後その事業会社に紐づいて作られるサービスは自動的にそのネットワークポリシーが適用されるようになる仕組みです。かつ、最低限ベースラインとして守りたいポリシーの部分はネットワークチーム側が管理して、それをプロダクトチームは勝手に変更できないような仕組みを作りました。それによって、プラットフォーム管理側からすると守りたいベースラインを守れるし、プロダクトチーム側からすると「プラットフォームチーム側の作業によってやりたいことが進められない」という状態から脱却できるようになりました。

参考記事：Managing Network Policies for namespaces isolation on a multi-tenant Kubernetes cluster

管理の仕組み部分をネットワークチームが作って、チーム・会社固有の部分は各々が自分たちで責任を持って管理する。一方で、私たち管理者側として適応したいポリシーのベースラインは守れる状態にする、それによって横軸の広がりに対応できるようにする。そういったことに注力していました。

もう一つの例として、Tailscaleという新しいVPNの導入をしています。メルカリの大部分の社内システムはVPNが不要な構成にはなっていますが、一方でVPNのようなものが必要なケースもあります。例えばアプリのQA用の環境を実際のお客さまの環境に近づけたいときや、あるいは多層防御の観点からセキュリティをより手厚くしたいときなどですね。今まで使っていたVPNソリューションは、スケーラビリティや管理の観点で横軸の広がりに対応しきれない部分がありました。そこで導入したのがTailscaleです。

これを使うと、どの社員がどのリソースにアクセスできるようにするか、管理者側で簡単に設定することができる。社内のVPNユーザーからも、使い勝手の良さが好評です。以前のソリューションは、クライアントが突然うまく動かなくなるとか、設定が煩雑といった問題があったのですが、そういう問題がほぼ無いので、サポートの負荷もなくなりました。また、時期的にWork from Homeという環境の変化への対応もVPN更新の理由としてあって。会社の拡大だけでなく、働き方の変化にもネットワークチームとして対応しました。

@deeeeeet：以前はVPNに関する問い合わせがめちゃくちゃ来てて、対応がかなり大変そうでしたが、いまは圧倒的に対応が楽になりましたよね。あと、以前のVPNはいかにも「つないでる」感じがありましたけど、いまは自然とプライベートネットワークの中にいる感じがしますね。

@raphael：Naokiさん（上級執行役員 SVP Japan）が提唱しているシームレスはすごい重要な言葉で、僕らがやってる仕事もまさに全部をシームレスにしようとしてますよね。

@kanemaru：横軸だけでなく縦軸の観点だと、CDNのトピックがあります。メルカリでは、お客さまに対してできるだけ良い体験を提供するため、そしてサービスをいろいろな攻撃から守るために、CDNを活用しています。今は手作業で設定を書く必要のある部分があったり、プロダクトチームと細かな要件を毎回擦り合わせながら実装していたりする。それは良い面もある反面、プロダクト開発のボトルネックになっている面もあります。チームとして今後こうした課題の改善に取り組みたいですね。

そのためには既に触れたネットワークポリシーの議論と同じように、ベースラインの基準や設定をしっかり守れるような仕組みをネットワークチームとして作って、その上でどうやってやりたいことを表現・実装するかが重要です。CDNの機能を上手く抽象化したうえで権限を各プロダクトチームに移譲していく、という仕組みが必要なのかなと思っています。

@deeeeeet：仕組みをつくるうえでブロッカーになっている部分はあるんですか？それとも、そういったものはだいぶ解消されつつある？

@kanemaru：そうですね、CDNを扱うのに専門知識が必要というのが難しい部分ですね。CDNにはベンダー特有の機能や挙動があったりするので、それらを十分に理解したうえで扱う必要があります。もちろん、HTTPやTLSといった技術要素についての理解も欠かせません。難易度が高いけど、一方でプロダクトチームからのリクエストは常にやってくるので、自動化する余力を確保しつつ目の前のリクエストに対応することを両立するのが大変…という状況ですね。

“Network as a Service”を作っているチームという感覚

@deeeeeet：ここまで話を聞いてきて改めて思ったのは、仕事の範囲がめちゃくちゃ広いなと（笑）。一言でネットワークっていうよりは、インフラエンジニアからSREというパラダイムが生まれていったみたいに、いまのネットワークチームがやってることも何か新しい名前や違う呼び名があってもいいんじゃないかなと思うんだけど、それに関して2人の考えも聞いてみたいな。

@raphael：やることが多すぎるから全体像がつかみづらいですよね。ネットワークに関するものをいろいろやってるんだけど、ネットワークはプラットフォームみたいな考えとか位置づけであるのかなと思う。他の会社だと、The Traffic Managementのような名前がつけられてるケースもあるけど、それでもめっちゃつかみづらいと感じますね（笑）。なんだろう、モダンプラットフォームネットワークとか…いろんな影響を受けて役割とか期待が変化してきていると感じます。

@kanemaru：難しいですね…。全部できるのはもちろんクラウドのおかげだし、安定した物理インフラが得られるようになったからこそ、私たちがその上のレイヤーで何をやるかということに集中できるようになったというのはあると思うので。

@deeeeeet：どんどん抽象度が上がっている…と。それっていわゆるサーバーの世界で起こってきた話に似ていますよね。物理からIaaSに行って、PaaSになって抽象度が上がっていく。「ネットワークチーム」というより「“Network as a Service”を作っているチーム」というか。

@deeeeeet：さて、二人へのラストクエスチョンとしては、今後1年とか2年スパンでやっていきたいことを聞きたいです。

@raphael：チーム内でよく話しているのは、コンポーサビリティについて。ネットワークサービスの各レイヤーをうまくハイコンポーザビリティにすること、かつそれをシームレスに提供することが重要で、いまそれに向けて準備を進めています。また最近、LinuxカーネルにeBPFのレボリューションが起きています。これまでアプリケーションのレイヤーで対応していたことが、カーネルのレイヤーでも実現できるようになっていますよね。私たちがそのレボリューションにも対応できるように、このレイヤーでも準備を始めようとしています。ハイコンサービリティなネットワークであれば、あるレイヤーで技術的な制約があるときに、異なるレイヤーでその一部を代わりに実現できたりする。そんなシームレスなネットワークサービスに注目しています。

@deeeeeet：確かに使いやすさとか、セキュリティの話が今日は多かったけど、ネットワークはやっぱりパフォーマンスがめちゃくちゃ重要ですよね。

@kanemaru：あとは、ひとつのチームで縦と横の二軸全般にわたってレスポンシビリティを持ってるとはいえ、その軸の上にあるコンポーネント一つひとつはやっぱりまだ独立してる部分があると思うんですね。例えばチームの中だと、CDN、クラウド上にあるGatewayと呼んでいるAPI gatewayサービス、そしてオンプレミスのデータセンター、全てのレスポンシビリティを持ってますけど、それらはもっとお互いに連携することで、より良い価値を提供できるはず。コンポーネント単位でいいものを作る、という今の状態から、それぞれを一気通貫にシームレスにつないでもっと良くしていきたいですね。

@deeeeeet：なるほど。こうした課題に中長期的にやっていきたいとなったときに、どういう方にメルカリに来て欲しいですか？

@raphael：ネットワークサービスはまだよく知られていないというか、まだいろんな可能性がある領域です。すごくネットワークが好きな人はもちろん、BtoBtoCシステムのコミュニケーションだったりとか、物理的からロジカル的まで興味がある方は、すごくコントリビューションできると思ってます。まさにKanemaruさんがその最たる例だと思っています。

@kanemaru：いま時点のスキルセットと、メルカリで使っている技術スタックがマッチするかというとこはもちろん大事かもしれないですけど、それよりはネットワークに関連して、お客さまとか社内のデベロッパー両方に対して良いものを提供したいというモチベーションを強く持っているのが一番大事なんじゃないかなとは思います。多分、入社時点でGKEを使ったことがないとかは、さしたる問題ではないと思うんですよね。実際、私は入社するまでほとんど触ったことはなかったし、クラウドを触ったことがあるとかは強い要件ではないと思いますので、ぜひ飛び込んできてほしいです。