Session Title メルコインのインフラ設計・構築と、信頼性のあ るサービスをリリースするためのSREの取り組 み Masaki Iino & Takaaki Yuhara 株式会社メルコイン SRE Team

Masaki Iino 2019年5月にメルチャリに参画し、インフラとバック エンドを担当。2020年2月からメルペイSREチーム に参加。2021年からメルコインSREのテックリードと してメルコイン事業の立ち上げを担当。 株式会社メルコイン Site Reliability Engineering Takaaki Yuhara 2019年6月にメルペイのSREとして入社。2021年か らはメルコインのSREチームでネットワークやインフ ラ周りを中心に事業の立ち上げを担当。 株式会社メルコイン Site Reliability Engineering

メルコインのセキュリティとコンプライアンスへの取り組 み 01 02 本セッションのテーマ インフラの全体像と信頼性あるサービスをリリースする ための取り組み

メルコインのセキュリティとコンプライアンスへの取り組 み 01 インフラの全体像と信頼性あるサービスをリリースする ための取り組み 02

メルコインとは メルコインは、メルカリアプリ内でビットコインの売買ができるサービスを 提供する会社 2023年3月9日より暗号資産交換業を開始

メルコインのインフラに求められるもの 暗号資産取引所システムとしての高度なセキュリティと コンプライアンス管理 セキュリティ コンプライアンス

メルコインに求められるセキュリティ セキュリティ規定と要件はメルカリやメルペイとは異なる ● ビジネスの特性上、さまざまなサイバー攻撃への対策が必要 ● 急な規定変更への対応が必要 メルカリ、メルペイとインフラを分離 ● 守るべきポイントを減らす ● 急な規定変更に耐えられるようコンパクトに

インフラの分離 Mercari Development Tool Production Mercoin Development Tool Production Environmental isolation Tenant isolation

インフラの分離 Google Workspaceを分離 GCP Organizationを分離 Billing Accountは共通 01 02 03

メルコインに求められるセキュリティ 誤った設定によるセキュリティホールを無くす ● 開発者が意識せずともセキュリティが保証されるべき ● 新しくマイクロサービスを追加してもセキュアな状態である メルコイン全体でSecure by defaultを目指す

Secure by default 間 違った危 険な設 定が 出 来 ないようにセキュリ ティ設定を追加していく Addon 始めから使える設定を最 小限にし、必要に応じて 限定的に例外を許可す る Default

Secure by default GCP Organization Security Policyで制約を強制 セキュリティチームと協力して全てのOrganization security policyを一つづつ 検討 GCP Organizationレベルでポリシーを強制 下記資料で推奨されている設定を参考にポリシーを強化 ● Google Cloud security foundations guide ● CIS Benchmark: Google Cloud Computing Platform

Secure by default 採用しているポリシーの例 ● compute.requireOsLogin ○ SSH keyをMetadataに埋め込んで使うことを防止 ● compute.requireShieldedVm ○ ブートローダーやOSの改ざんを防止 ● iam.automaticIamGrantsForDefaultServiceAccounts ○ GCEのデフォルトサービスアカウントへの Editor権限の付与を防止 ● storage.publicAccessPrevention ○ GCSのパブリック公開を制限

Secure by default 最小権限を全チームに付与 権限の対象範囲をチームによって変える ● SREチームには本番環境全体に対して付与 ● マイクロサービスチームにはマイクロサービスプ ロジェクトを束ねるチームフォルダに対して付与 権限昇格が必要な際は、セッションの後半で説明す るCarrierを使って一時的に権限を昇格

PRC (Production Readiness Checklist) PRCを使ってシステム上の制約をカバー Security Policyではカバー出来ないものは、PRCの項目に追加し、新規サービ スのリリース時や定期的にチェック

メルコインに求められるコンプライアンス インフラの変更管理をメルコインの組織内で行う 適切な承認プロセスを経ることでインフラ全体のコントロールと統一性を図る インフラのオーナーをメルコインSREが担う

メルカリグループのSRE Infrastructure Platform team Mercari SRE Merpay SRE Mercoin SRE Merpay Mercari Mecoin PlatformとSREチーム ● カンパニーごとにSREがいる ○ Mercari SRE ○ Merpay SRE ○ Mercoin SRE ● インフラ基盤の開発運用を担当する Platformチームがいる

メルペイのインフラ管理 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

メルコインのインフラ管理 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

メルコインに求められるコンプライアンス サーバやお客さまデータの取り扱いを日本国内に限定 ● 国内で取り扱うことで日本の法令と規制への遵守が容易になる ● お客さまデータの保護指針が明確になり、管理とセキュリティ対策が容易 になる GCPのリージョン設定を東京と大阪に制限

リソースとデータの配置 バックアップを 含 むアプ リケーションの 全 てのリ ソースとデータを国内で 管理 Tokyo/Osaka CloudDNSなどGCPが グローバルで 提 供 して いるサービスはリージョ ンレス Global

リソースとデータの配置 GCP Organizationで国外を禁止 GCP Organization Security Policyの gcp.resourceLocationsを使ってOrganization レベルで制限 プロジェクト単位で例外を許可 ● Aプロジェクト ○ us-west1でリソース作成不可 ● Bプロジェクト ○ us-west1でリソース作成可能

前半のまとめ インフラを分離し、セキュリティと規定変更への耐性を上げる 01 組織内でのインフラ管理 02 国内でのサーバとデータの管理 03

メルコインのセキュリティとコンプライアンスへの取り組 み 01 インフラの全体像と信頼性あるサービスをリリースする ための取り組み 02

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

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

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

メルコインの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

メルコインの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 などで活 用

メルコインの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

メルコインの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

メルコインの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 …

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

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設定など

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/

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でコードを検証

Carrier ● 運用者がオペレーションで一時的に必要な権限を取 得するシステム ● SREの承認が必須 ● 権限は有効期限付きで付与される

まとめと課題 独立したGCP Organization 01 マイクロサービスは共通のGKEクラスターでマルチテナント 02 インフラ開発・運用を支援するためSREからツールを提供 03 ツールが増えてきたことによる学習コストや認知負荷の増大 04

No content