※本記事は2022年2月9日に公開された記事の翻訳版です。
*この記事は、Developer Productivity Engineering Camp ブログシリーズの一部です。
はじめに
みなさん、こんにちは。メルカリNetworkチーム Tech LeadのRaphael Fraysseです。この記事ではチームについて簡単に紹介し、チームが達成したいこと（ミッション）やその達成方法（戦略）を説明していきたいと思います。
ミッション
私たちのチームのミッションは、お客さまとメルカリのシステムの間の通信をシームレスで信頼性と安全性の高いものにすることです。
ネットワークの要は、アプリケーションのユーザーとこれらのアプリケーションを実行しているシステムとの間の通信です。私たちのシステムは非常に複雑なことに加え、地理的にもさまざまな場所にあり、データパスに応じてホップが異なります。
ネットワークの観点から見た典型的なデータパスの概要は以下の通りです。
特にお客さまの大部分がモバイルアプリを使用しているので、お客さまのデバイスからエッジシステムまでのネットワークを制御することがほぼ不可能です。
エッジシステムは、レスポンスタイムを縮めるのに役立ちます。主なユースケースは、マーケットプレイスに掲載されている商品の画像をキャッシュすることですが、DDoSや悪意のある攻撃からインフラを保護するためにもエッジシステムを使用します。
エッジの後ろには、パブリッククラウドプロバイダー（主にGCP、AWSなど）で実行されているアプリケーションシステムがあります。クラウドリソースの責任共有モデルのおかげで、低レベルのネットワークインフラ（OSIモデルのL1～L2）を維持する必要がないので、上位レイヤー（L3～L7）に集中して、より多くの価値をお客さまに提供できます。
最後に、データの中核部はデータベースにありますが、これはまだほとんどが東京のデータセンターにあるオンプレミス環境で運用されています。クラウドと比べると、データセンターの運用では、低レベルのネットワークインフラ（トランジット回線、スイッチ、ルーター、インターネットエクスチェンジ（IX）との接続など）のメンテナンスも必要です。ただし、私たちはこれらのデータベースをクラウドにマイグレーションし、オンプレミスのフットプリントを削減している最中です。
ご想像のとおり、個々のドメインはかなり大きく、異なる分野に特化しています。メンバーがこれらすべてのドメインに精通することは現実的に期待できないため、チームにはネットワークを中心としたさまざまなスキルセットを持つメンバーで構成されています。それはまた、メンバーが自分のコンフォートゾーンから自由に出て他のドメインに挑戦できることを意味します（好奇心旺盛な人にとって最適な環境ですね！）
戦略
チームには、ミッションを実現するために次の戦略があります。
- 開発者とアプリケーションコードからネットワークの懸念を取り除く
- 組織全体のセキュリティ、信頼性、スケーラビリティを確保するためのコアネットワークビルディングブロックとガイドラインを作成する
Abstracting away network concerns from developers and application code
私たちはプラットフォームグループの一員として、開発者体験に関して同じ領域にフォーカスしています。ネットワークはインフラのクリティカルな根源的要素ですが、開発者はそれに無駄な時間をかけるのではなく、お客さまへの価値提供に集中する必要があります。
効果的であるためには、ネットワークの重要な属性（シームレスさ、安全性、信頼性）が通信経路においてエンドツーエンドで体現され、アプリケーションがその中で重要な役割を果たす必要があります。アプリケーション開発者の時間を節約する唯一の方法は、次のようなネットワークの懸念に対応する抽象化レイヤーを提供することによってこれらの属性を簡単に実装できるようにすることです。
- セキュリティ機能
- TLS 終端
- 認証認可
- ネットワークポリシー
- 復旧機能
- サーキットブレーカー
- リトライ
- ユーザートラフィックへの露出
- ロードバランサーのプロビジョニング
- パスベースルーティング
- デプロイ機能
- カナリアリリースのためのきめ細かいトラフィック制御
- QAテストのためのサービスの動的ルーティング
数年前は大きなモノリシックアプリケーションを扱っていましたが、当時はアプリケーションコンポーネント間の通信はほとんど同じサーバー内で行われていたため、これらの懸念のほとんどは問題ではありませんでした。
これらの懸念は、マイクロサービスアーキテクチャへのマイグレーションを開始したときに現れ、そのうちの多くは、分散コンピューティングの落とし穴に直接関係しています。
この戦略を具体化したプロジェクトのいくつかの例を挙げます。
1. メルカリでのIstioの採用（IstioConでのプレゼンテーション）
上記の懸念の大半に対応するため、サービスメッシュパターン（Istioはその実装）を使用しています。いくつかの課題を経て、マイグレーションプロセスはまだ進行中です。プレゼンテーションでは、これらの課題の概要とマイグレーションの状況について説明しています。
2. 大規模なIstioガードレールの準備（KubeFest 2020東京でのプレゼンテーション）
このプレゼンテーションでは、開発者とネットワークオペレーターの両方からのヒューマンエラーを防ぎ、Istioを安全に実行するために必要なガードレールをどのように作成したかに焦点を当てています。
また本プロジェクトについては、このブログシリーズでいくつかの記事を公開しているので、ぜひご覧ください。
- Yusaku Hatanaka（@hatappi）「Istioが解決する私達の問題（2022年2月10日（木））
- Yohei Kanemaru (@kanemaru)「Managing network policies for namespaces isolation on a multi-tenant Kubernetes cluster（英語）」（2022年2月14日（月））
- Sharma Rajesh (@raju) 「Dynamic Service Routing using Istion」（2022年2月15日（火））
組織全体のセキュリティ、信頼性、スケーラビリティを確保するためのコアネットワークビルディングブロックとガイドラインの作成
上記の抽象化は、主にサービス間通信に焦点を当てており、アンサンブルの安定性、復旧力、安全性を保ちながら、マイクロサービスのスケールアウトを可能にするビルディングブロックです。
また、ネットワークが組織拡大のボトルネックにならないようにすることが必要です。ゼロから新しいビジネスを始める場合、自力でインフラとネットワークを築くのに多くの時間を失う可能性があります。さらに、組織の強みを活用するためには新しいビジネスの統合がほぼ不可欠ですが、適切にデザインされていないネットワーク統合は大きなブロッカーとなる可能性があります。
同時に、組織全体が同じコンプライアンスに準拠している場合、それによって、要求されるコンプライアンスレベルがそこまで高くないビジネスの速度まで低下することになりかねないので、ネットワークとセキュリティのバランスが必要です。
この戦略を実現したプロジェクトの例を2つ挙げます。
1. GCPネットワークの共有VPCモデルへのアーキテクチャ変更
ネットワークの状態を評価したところ、そのアーキテクチャが拡張計画で多くのブロッカーを引き起こすことは明らかでした。組織のスケーラビリティを確保するために、米国のメルカリなどのエンティティを共有VPCモデルに統合できるクリーンなグローバルマルチカンパニーネットワークアーキテクチャを構築しました。
2. メルカリグループのネットワークセキュリティガイドライン
昨年、大規模なセキュリティインシデント（Codecov）が発生しました。その後、Networkチームでは組織で使用されているネットワークの棚卸しを行いました。また、ネットワークセキュリティガイドラインを策定および実行し、組織のセキュリティ体制の改善を図っています。
おわりに
この記事では、メルカリのNetworkチームとそのミッションと戦略、およびチームが行ったいくつかのプロジェクトを紹介しました。
プラットフォームグループは過去数年間で大きく成長し、現在も急速に成長しており、メルカリとそのすべての子会社にポジティブな影響を与えています。Networkチームには非常にエキサイティングな課題があります。例えば、組織のネットワーク戦略を確保してその成長をサポートしながら、マイクロサービス群の通信を強化し、新しいビジネスのネットワークを構築するといった課題があります。私たちの活動についてご興味をお持ちの方は、TwitteまたはLinkedInからご連絡ください。メルカリは就労ビザの取得も支援しています。また、日本語能力はチームの必要要件ではありません。
