メルコインのインフラ設計・構築と、信頼性のあるサービスをリリースするためのSREの取り組み / SRE Initiatives to Design and Construct Mercoin’s Infrastructure and Release Reliable Services

メルコインのサービスローンチに伴って、SREがメルコインのインフラをどのように設計し、限られた時間の中で構築を行い、さらに数十あるマイクロサービスをバックエンドエンジニアと協力してProduction Readyな状態にし安全にローンチしたかをお話します。

In tandem with the service launch of Mercoin, SRE designed the infrastructure for Mercoin, building it in a limited amount of time and also managing to work with backend engineers to create dozens of microservices and get the service production-ready for what was ultimately a safe launch.

------
Merpay & Mercoin Tech Fest 2023は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイ・メルコインの技術スタックに興味がある方々を対象に2023年8月22日（火）、23日（水）、24日（木）の3日間、開催します。 Merpay & Mercoin Tech Fest は事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りです。

今年のテーマは「Unleash Fintech」。 メルペイ・メルコインのこれまでの技術的な取り組みはもちろん、メルカリグループのFintech事業における新たな挑戦をお伝えします。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチなど多面的にご紹介予定です。

メルペイ・メルコインが今後どのようにUnleash（解放）していくのか、ぜひ見に来てください。

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2023/
- 申し込みページ：https://mercari.connpass.com/event/286670/
- Twitterハッシュタグ： #MerpayMercoinTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Session Title メルコインのインフラ設計・構築と、信頼性のあ るサービスをリリースするためのSREの取り組 み Masaki Iino & Takaaki Yuhara 株式会社メルコイン SRE Team
2. Masaki Iino 2019年5月にメルチャリに参画し、インフラとバック エンドを担当。2020年2月からメルペイSREチーム に参加。2021年からメルコインSREのテックリードと してメルコイン事業の立ち上げを担当。 株式会社メルコイン Site Reliability Engineering Takaaki Yuhara 2019年6月にメルペイのSREとして入社。2021年か らはメルコインのSREチームでネットワークやインフ ラ周りを中心に事業の立ち上げを担当。 株式会社メルコイン Site Reliability Engineering
3. メルコインのセキュリティとコンプライアンスへの取り組 み 01 02 本セッションのテーマ インフラの全体像と信頼性あるサービスをリリースする ための取り組み
4. メルコインのセキュリティとコンプライアンスへの取り組 み 01 インフラの全体像と信頼性あるサービスをリリースする ための取り組み 02
5. メルコインとは メルコインは、メルカリアプリ内でビットコインの売買ができるサービスを 提供する会社 2023年3月9日より暗号資産交換業を開始
6. メルコインのインフラに求められるもの 暗号資産取引所システムとしての高度なセキュリティと コンプライアンス管理 セキュリティ コンプライアンス
7. メルコインに求められるセキュリティ セキュリティ規定と要件はメルカリやメルペイとは異なる • ビジネスの特性上、さまざまなサイバー攻撃への対策が必要 • 急な規定変更への対応が必要 メルカリ、メルペイとインフラを分離 • 守るべきポイントを減らす • 急な規定変更に耐えられるようコンパクトに
8. インフラの分離 Mercari Development Tool Production Mercoin Development Tool Production Environmental isolation Tenant isolation
9. インフラの分離 Google Workspaceを分離 GCP Organizationを分離 Billing Accountは共通 01 02 03
10. メルコインに求められるセキュリティ 誤った設定によるセキュリティホールを無くす • 開発者が意識せずともセキュリティが保証されるべき • 新しくマイクロサービスを追加してもセキュアな状態である メルコイン全体でSecure by defaultを目指す
11. Secure by default 間 違った危 険な設 定が 出 来 ないようにセキュリ ティ設定を追加していく Addon 始めから使える設定を最 小限にし、必要に応じて 限定的に例外を許可す る Default
12. Secure by default GCP Organization Security Policyで制約を強制 セキュリティチームと協力して全てのOrganization security policyを一つづつ 検討 GCP Organizationレベルでポリシーを強制 下記資料で推奨されている設定を参考にポリシーを強化 • Google Cloud security foundations guide • CIS Benchmark: Google Cloud Computing Platform
13. Secure by default 採用しているポリシーの例 • compute.requireOsLogin ◦ SSH keyをMetadataに埋め込んで使うことを防止 • compute.requireShieldedVm ◦ ブートローダーやOSの改ざんを防止 • iam.automaticIamGrantsForDefaultServiceAccounts ◦ GCEのデフォルトサービスアカウントへの Editor権限の付与を防止 • storage.publicAccessPrevention ◦ GCSのパブリック公開を制限
14. Secure by default 最小権限を全チームに付与 権限の対象範囲をチームによって変える • SREチームには本番環境全体に対して付与 • マイクロサービスチームにはマイクロサービスプ ロジェクトを束ねるチームフォルダに対して付与 権限昇格が必要な際は、セッションの後半で説明す るCarrierを使って一時的に権限を昇格
15. PRC (Production Readiness Checklist) PRCを使ってシステム上の制約をカバー Security Policyではカバー出来ないものは、PRCの項目に追加し、新規サービ スのリリース時や定期的にチェック
16. メルコインに求められるコンプライアンス インフラの変更管理をメルコインの組織内で行う 適切な承認プロセスを経ることでインフラ全体のコントロールと統一性を図る インフラのオーナーをメルコインSREが担う
17. メルカリグループのSRE Infrastructure Platform team Mercari SRE Merpay SRE Mercoin SRE Merpay Mercari Mecoin PlatformとSREチーム • カンパニーごとにSREがいる ◦ Mercari SRE ◦ Merpay SRE ◦ Mercoin SRE • インフラ基盤の開発運用を担当する Platformチームがいる
18. メルペイのインフラ管理 Merpay microservice team Infrastructure Platform team component A B C Platform team Service A team Service B team Owner Manage Support Merpay SRE Merpay common • SREチームは開発チームのサポートと共通機能の開発運用を担当 • Platformチームはインフラ基盤の開発運用とインフラ全体のオーナー D E
19. メルコインのインフラ管理 Mercoin microservice team Infrastructure Platform team component A B C Platform team Service A team Service B team Owner Support Mercoin SRE • SREチームは開発チームのサポート、共通機能の開発運用、 インフラ全体のオーナー • Platformチームはインフラ基盤の開発運用 Manage Mercoin common D E
20. メルコインに求められるコンプライアンス サーバやお客さまデータの取り扱いを日本国内に限定 • 国内で取り扱うことで日本の法令と規制への遵守が容易になる • お客さまデータの保護指針が明確になり、管理とセキュリティ対策が容易 になる GCPのリージョン設定を東京と大阪に制限
21. リソースとデータの配置 バックアップを 含 むアプ リケーションの 全 てのリ ソースとデータを国内で 管理 Tokyo/Osaka CloudDNSなどGCPが グローバルで 提 供 して いるサービスはリージョ ンレス Global
22. リソースとデータの配置 GCP Organizationで国外を禁止 GCP Organization Security Policyの gcp.resourceLocationsを使ってOrganization レベルで制限 プロジェクト単位で例外を許可 • Aプロジェクト ◦ us-west1でリソース作成不可 • Bプロジェクト ◦ us-west1でリソース作成可能
23. 前半のまとめ インフラを分離し、セキュリティと規定変更への耐性を上げる 01 組織内でのインフラ管理 02 国内でのサーバとデータの管理 03
24. メルコインのセキュリティとコンプライアンスへの取り組 み 01 インフラの全体像と信頼性あるサービスをリリースする ための取り組み 02
25. GKE Project メルコインのアーキテクチャ Kubernetes Cluster Gateway API Service Auth token Service A Service B Service C Project A Project B Project C Cloud Load Balancing Cloud Spanner Cloud Spanner Cloud Spanner Pub/Sub Pub/Sub 共通のGKEクラスター 01 個別のProject 02 レイヤーアーキテクチャ 03
26. VPCの構成 Shared VPC Host Project Service Project B subnetworks Service Project A GKE GKE VPC Firewall Cloud NAT Cloud DNS Service Project C Memorystore Service Project D GCE Shared VPC Shared VPC構成 01 Default Deny Firewall 02
27. Private Service Connect(PSC) Mercoin Organization Mercari Organization Project VPC Kubernetes Cluster ILB Service Attachment Project VPC Kubernetes Cluster PSC Endpoint Service A Service B Gateway メルコインとメルカリ間連携で Private Service Connect接続 対象のServiceと接続元のProjectを絞って限定公開。VPC Peeringなどは不要。 Service X
28. メルコインのGKE Cluster • Private Cluster ◦ 外部IPアドレスを持たないノード構成 ◦ ノードや同じVPC内のホストはPrivate Endpoint経由でControl Planeと通信 ◦ インターネット上のホストは Public Endpoint経由でControl Planeと通信 Authorized networkによって指定したIPアドレスからのみの接続を許可 ◦ ワークロードから外部向けの通信は Cloud NATを経由 GKE Private Cluster Control Plane Node A Node Z Internet Cloud NAT Authorized network Public Endpoint Private Endpoint Kubernetes API Server Kubectl client
29. メルコインのGKE Cluster • その他の機能（一例） ◦ Network Policy ▪ deny by default policyを強制 ◦ Cloud DNS for GKE (VPC scope) ◦ Google Group for RBAC ◦ Workload Identity ◦ Istio ▪ GKEのadd-onは使わず、指定したバージョンを使うために個別にセットアップ ▪ Canary releaseの時のTraffic Managementや, マイクロサービス間の mTLS などで活 用
30. メルコインのmicroservices Mercoin GKE Cluster Namespace A Namespace B Namespace C Microservice A Microservice B Microservice C Service A Team Service B Team Service C Team Project A Project B Project C Cloud Spanner Pub/Sub Cloud Spanner Memorystore GCE Cloud Spanner
31. メルコインのmicroservices Mercoin GKE Cluster Namespace A Namespace B Namespace C Microservice A Microservice B Microservice C Service A Team Service B Team Service C Team Project A Project B Project C Cloud Spanner Pub/Sub Cloud Spanner Memorystore GCE Cloud Spanner
32. メルコインのmicroservices Mercoin GKE Cluster Namespace A Namespace B Namespace C Microservice A Microservice B Microservice C Service A Team Service B Team Service C Team Project A Project B Project C Cloud Spanner Pub/Sub Cloud Spanner Memorystore GCE Cloud Spanner Kubernetes resources Namespace Deployment Service ServiceAccount RoleBinding NetworkPolicy Istio VirtualService BackendConfig FrontendConfig Ingress … Cloud Resources Spanner Pub/Sub Secret Manager Service Account Project IAM Spanner IAM PubSub IAM Secret Manager IAM Workload Identity …
33. IaCと抽象化 • インフラをTerraformやYAMLなどで記述する一方で、専門的な知識や実装も不可欠 • チームの開発を促進しメルコインで定めた設定をプロビジョニングできるように、 SREが抽象化 したモジュールを提供 • これらを使うことで開発者は、全ての設定を 1つ1つ行う必要なく、標準化されたものをプロビ ジョニングできる • GCP resources, PagerDuty, GitHub, Datadogや一部のKubernetes resourceなどの設定を Terraformで定義 • Kubernetes の workload に関わるresourcesはCUEによって抽象化 Service X Team Kubernetes Service X Team PR & Review PR & Review GitHub CI/CD Pipeline Kit を配布 CI/CD Pipeline
34. Terraform modulesの一例 • microservices-starter-kit ◦ 専用のGCP ProjectやKubernetes Namespaceなど、microserviceに関わる基本的に 設定など • microservices-team-kit ◦ Google Groupの管理とグループ単位の IAM設定や、OnCallチームの設定、GitHub teamの管理などチームのユーザー管理を一元化 • microservices-spanner-kit ◦ Spanner instanceやdatabase、バックアップの設定、 Spanner autoscalerの設定など • microservices-slo-kit ◦ SLOを定義しそれに対応した Datadog monitor設定など
35. CUEによるKubernetes resource抽象化 • microservices-kubernetes-kit ◦ Kubernetesマニフェストの簡易化とコードの削減、 KubernetesやIstioなどの周辺技術の 知識軽減などを目的に、マイクロサービスで必要な Kubernetesマニフェストをセキュリ ティや可用性などの面でコントロールされた状態で抽象化 [補足] CUEを使用したKubernetesマニフェスト管理 https://engineering.mercari.com/blog/entry/20220127-kubernetes-configuration-management-wi th-cue/
36. Conftestによるコードの検証 • CI/CD PipelineにてTerraformやKubernetesのコードを検証 ◦ 一例 ▪ モジュールに対する検証 • Shared VPCへの接続が許可されているか ▪ Terraformの検証 • VPC Firewallでログが有効になっているか ▪ Kubernetesマニフェストの検証 • 特権モード、ホストネットワークの使用　など Service X Team Kubernetes Service X Team PR & Review PR & Review GitHub CI/CD Pipeline CI/CD Pipeline Conftestでコードを検証
37. Carrier • 運用者がオペレーションで一時的に必要な権限を取 得するシステム • SREの承認が必須 • 権限は有効期限付きで付与される
38. まとめと課題 独立したGCP Organization 01 マイクロサービスは共通のGKEクラスターでマルチテナント 02 インフラ開発・運用を支援するためSREからツールを提供 03 ツールが増えてきたことによる学習コストや認知負荷の増大 04