PlayStation(TM)Network とコンテナ, CICD

PlayStation™Network とコンテナ, CICD

ソニー・インタラクティブエンタテインメント 西海持 雅隆

はじめに

スライドは後日公開予定です そのこともあり、プレゼンを ２PPM 目標で進めます サクサク進む、プレゼン・エンタテインメント

自己紹介

西海持 雅隆

(さいかち まさたか)

• 10 年近い開発経験

• 10 年近いインフラ・運用経験

• PlayStation™Network 東京拠点の CICD チームのリード AWS Summit Tokyo 2014

PlayStation®4 (PS4®) のロンチ時に、PlayStation™Network 東京拠点のサービスで AWS を全面採用した話のセッションを持つ

会社紹介

ソニー・インタラクティブエンタテインメント (SIE) は PlayStation®を作っている会社 です。

会社紹介

SIE では PlayStation®の遊びを広げるオンラインサービス PlayStation™Network (PSN) を ご提供しております。 PSN の開発・運用は • グローバルに広がる複数拠点で実施 • 各拠点がゲーム、コマース、ストアなどの単位で機能を分担 • 各拠点がグローバルにサービスを提供 私の所属している東京拠点は、オンライン対戦やトロフィー、メッセージなど、ゲーム 向けのネットワーク機能を開発・運用しています。

数字で見る PS4® と PSN

全世界累計実売台数 PS4®ゲームプレイ

MAU

展開国・地域

7,360

万台

8

億時間

以上/週

8,000

万

以上

70

カ国

お話しする内容

PSN 東京拠点で、フルスクラッチでコンテナ基盤と CICD を実現し、

サービスインした話

コンテナと CICD “私達のケース”

企画から導入、運用まで、何をどのように考え、判断し進めたか。

• 今回、尖ったことや斬新なことは行わなかった

• 先進的から教科書的まで、多くの情報が Web にある

それでも実現に約二年を要した、その内容をご紹介します。

同じテーマに取り組んでいる方のご参考となれば幸いです。

目次

1. 2016 | 出発前 2. 2016 | 出発点 3. 方針 4. アーキテクチャ 5. 設計のポイント 6. 進め方 7. 組織の協業 8. 広める！ 9. サービスイン 10. 2018 | 達成 11. 困難 12. 今後 13. 結び

2016 | 出発前

本セクションには、後の成果を目立たせるために

悲壮感の演出があります

東京拠点の規模

• 数十サービス

(二桁後半)

• 数千インスタンス

• ほぼ AWS 上

いわゆる

Dev

と

Ops

と

Sec

! “DevOps”

組織

サービスデリバー

組織の構造 ＝ システムの構造 (コンウェイの法則)

CI

リリース 準備

D

進む 個別最適化

“リリース” と “準備” そして “デプロイ”

既存の仕組み

Dev と Ops それぞれの努力の成果

ちゃんと機能する

でも、サービス数が多く大変

新しい部署の発足

サービスデリバリーを扱う部署が Dev に発足。

三人のエンジニアが立候補して参加し、私はチームリードを担当。

企画

“速度” にフォーカスした CICD の仕組みを作る。

• アベイラビリティを下げること無く、迅速かつ効率的にサービスを

デリバーすることで一日 100 回のリリースとデプロイができ、

本番運用可能な基盤構築を目指す

• 開発から運用までの全体最適化を図る

• セキュリティを全てにおいて

1st class citizen として扱う

Haste CICD とは

Haste CICD はコンテナの作成、開発、デプロイから運用に至る

すべてを提供します。

継続的インテグレーション

＋ 継続的または手動デプロイ

＋ コンテナ実行環境

(開発と本番)

＋ Docker BaseImage

＋ セキュリティ

セキュリティは本当に重要

セキュリティを全てにおいて 1st class citizen として扱う。

セキュリティの問題が起きると、お客様にゲームを楽しんでいただけなくなっ

てしまう。

何時でも、安心してゲームを遊んでいただけるよう、お客様のプライバシー、

お預かりしている情報を全力で守る。

シンプルかつ必要最小限

本当に必要なものだけを作る

• 10 行のコードであっても、何かを作れば必ず運用が発生する • 作る前に 「最後まで面倒を見れるか」 を考えてみる

極力 AWS のサービスを活用

• 制約を受け入れる – できないことも多いが、そもそも不要なこと、代替できることも多い • ベンダロックインのリスクは常に意識 – 作り込まずに、なるべくそのまま使う

AWS サービスの薄い “ラッパー” や “フレームワーク” を作る事が多い

迷ったら

目標を思い出す

• 速度にフォーカスしているか • それは一日に 100 回以上デプロイできる選択肢か • セキュリティをなによりも大切にしているか

まずやってみる

• 動かして、体験することはとても大事 • 100点を目指して、分析や設計中毒にならない

なぜコンテナか

コンテナ

• ○ 80% のサービスが提供可 • ○ 秒単位 (起動) 当初 Apache +Tomcat の 普通の HTTP サービスのみを対象に

インスタンス

• ○ ほぼ 100% のサービスが提供可 • × 分単位 (起動) すでに一定の仕組みを構築済み

ファンクション

• × 特定の目的のみで利用可(当時) • ○ 秒単位 いずれ AWS が仕組みを揃えてくれる

コンテナ基盤

アーキテクチャ (コンテナ基盤)

ECS, ECR, ALB, S3 と Route53 など標準的な AWS スタックを極力利用

Amazon Route 53

Service Discovery は現在未使用 Amazon ECR

ACM

Amazon ECS Artifact Bucket Public Service A

2016 年の判断 Orchestration Tool

ECS

Kubernetes や Docker Swarm ではなく？

• シンプル：学習コストが低い、機能は限られる • 高品質：本番環境での利用事例、SPOF レス • AWS サービスとの密な連携と、強力なサポート

• 当時の Kubernetes や Docker Swarm は発展途上に思えた

今大切なこと

それは コンテナ化

データを Kinesis, S3, CloudWatch に集約し、極力 Serverless で処理。

ログ

メトリクス

アーキテクチャ (運用・監視)

アプリケーション 集約と蓄積 監視 ツール Kinesis: 損失を最小限に抑えるログ / S3: 一定の損失を許容するログ ホストとコンテナ ログ ツール Event Processing

アーキテクチャ (CICD)

Github の裏で動く、CodePipeline を中心とした軽量フレームワーク

github ステージング Build Inspect Test Register Image Feed Baaaaaaaaaaaaaaaaaack!

Hook Kick AWS CodePipeline

CodeBuild に 万能感

AWS Well-Architected Framework

AWS SA の荒木さんが激推し

• クラウドアーキテクチャのベストプラクティス集

• 設計の良い目次になる

• 見逃しているポイントに気がつける

• 会社から営業活動のプレッシャーがあるのかと

勘ぐるも、杞憂に終わる (流石です)

気がつけることの例

データの保護より • AWS 側でデータの暗号化をサポートしているサービスに何があるか • その実現手段 S3 のサーバ側暗号化 SSE-KMS と KMS API の制限 • AWS で暗号化の鍵管理といえば KMS • S3 のサーバ側暗号化には SSE-S3 と SSE-KMS がある

• SSE-KMS では、オブジェクトのダウンロード毎に Decrypt API が呼ばれる • Decrypt API はアカウント単位 1,200 Req/Sec のスロット制限がある

• デフォルト暗号化に SSE-KMS を選択し、暗号化されたオブジェクトのダウンロード数が 1,200 Req/Sec を越えると…

基盤: 環境構成

同一構成のステージング環境と本番環境

• インスタンス数の差異のみ

• 環境に起因する問題を早期に見つけられる • CloudFormation で容易に構築

基盤: Subnet 設計はコンテナを十分考慮

AWS サービス毎の差異

• アタッチできる Subnet 数が異なる • ECS Task は 10 Subnet

• ELB は 1AZ あたり 1 Subnet

IP アドレス (ENI) 大量消費

• “awsvpc” モードではインスタンス数 + コンテナ数 ENI を消費 • Lambda VPC も配慮

NAT Gateway の分散

• NAT の障害対策として、１つの ECS Service や AutoScaling Group が複数の NAT を使うように

ECS Task

基盤: ホスト

高速かつ安定した起動を優先

AMI

• AmazonLinux AMI • 必要最小限の種類 • Golden AMI • Packer と Ansible • Serverspec

ECS クラスタ

• 単一の共用クラスタ

AutoScaling

• Scale-in/out • CPU 予約率 • Memory 予約率 • 消費 ENI 数

コンテナ: ECS Task

全サービスで共通のリソース設定

• Tomcat は CPU: 1024, メモリ: 2GB など • チューニングやサイジングを容易に • 性能はスケールアウトで確保し、最適化は後日

Service AutoScaling

• CloudWatch カスタムメトリクス – TCP Connection, ミドルウェアのスレッド数やコネクション数 – コンテナ単位のメトリクス • 慎重なスケールイン – “すべて” の CloudWatch アラームが収束したらスケールイン httpd Tomcat fluentd

CICD: サービス開発用に三種のパイプライン

Pull Request パイプライン

• アプリケーションのビルドとテスト • Docker Image の作成と、開発環境への登録

Push パイプライン

• Pull Request パイプラインの作業 ＋ さらなるテスト • ステージング環境への Docker Image の登録と自動デプロイ

“Git flow” でうまく動くよう主要ブランチごとのパイプライン

なお CodePipeline は同一パイプラインで追い越しができない

CICD: Git Branching Model への適合

for develop branch

for master branch

CICD: Developer へのフィードバック

Developer が大好きな Github や Slack に情報を集約

というのも AWS Management Console は正直使いにくい…

Developer 向けの適切に限定された IAM 権限の設定も難しい…

デベロッパー体験のため、CI の処理状況や詳細を AWS サービスの UI にあま

り頼らず、これらに集めた。

• Github - Pull Request や Comment など • Slack

CICD: サービスデリバー

役割により、異なるニーズ、異なるソリューション

ステージング環境までの “CD” パイプライン

本番環境へのデプロイツール (ステージング環境でも使用)

Github でのマージでデプロイ

Code Pipeline + ECS Service Update 速度と頻度

Dev

作業

既存の変更管理プロセスのサポート マニュアルで扱う独自実装ツール 信頼性 ガバナンス

Ops

作業

CICD: 本番環境へのデプロイツール

信頼性とガバナンス重視の、手動で操作する独自実装デプロイツール

CLI が StepFunctions のワークフローを開始。実行される ECS Task や Lambda

Function が CloudFormation などで ECS Service, ALB, Alarm を操作。

• Canary testing

• Blue-Green Deployment

• AutoScaling (scale-in / out) のサポート • 承認者による承認プロセスや監査への対応 • トラブル時のロールバック

進め方

• Haste 開発

• Test Bed

： 社内利用サービスを移行

(１サービス、切り戻し可)

• 既存移行 ： 本番サービスを移行

(３サービス、切り戻し可)

Native

開発

Tune

既存

移行

Tune

Test

Bed

Haste

開発

かかった時間は約二年

• Haste 開発 ： ９カ月

• Test Bed

： 10カ月 評価とチューニング

• 既存移行 ： ７か月 最初のサービスの Dockerize から移行まで

• Native 開発 ： ２か月 最初のサービスのステージング導入まで

Native

開発

Tune

既存

移行

Tune

Test

Bed

Haste

開発

Dev Team

役割に変化

最初は自分たちで 次に使ってもらう そして作ってもらう Haste 開発 パイプライン構築 コンテナ化

CICD

Native

開発

Tune

既存

移行

Tune

Test

Bed

Haste

開発

Dev Team

Docker で複雑・曖昧になる役割の境界

CICD

コンテナに OS や ミドルが含まれる、デプロイを一部 Dev が行うとい

った点で、Dev と Ops の境界が複雑かつ曖昧に。

• 多くの人との議論 • 多くの人の理解と協力 Haste 開発 パイプライン構築 コンテナ化

多くの人を巻き込んだ

• パイプラインや Dockerize の設計支援 • 既存のプロセスやサービスに精通 • 海外拠点とのアライン

Dev の人は新しいチャレンジに積極的

• パイプラインや Dockerize の設計支援 • 最初の Dockerize サービスの担当 • サービスのレクチャやパイプラインの評価とフィードバック • コードの修正 • パイプラインや Dockerize の設計支援

運用マネージャのアドバイスで、サービス運用チームでは有志の参加者を募った。 ８名のエンジニアが参加する WG が発足し、モチベーション高くタスクを遂行。 • インフラの設計支援 • 設計レビュー

Ops の人もコンテナに興味津々

• サービス構築・運用・監視と移行 • インフラ構築・運用と監視 • プロセスの整備 • ドキュメント・Runbook の整備 • AutoScaling (Host / Task) の実現 • 調査手段や HotFix の実現

• 採用予定の AWS サービスについて質疑 • アーキテクチャレビュー

AWS の皆さんはいつも頼りになる

• サービスイン時のサポート • 各種トラブルのフォローアップ

Sec の人は最初から協力的

開発から運用まで、 新基盤に最初から適切な

セキュリティを導入できることは、Sec としても効率的

成果

協業

• セキュリティ対策の立案 • セキュリティポリシーへの準拠 • インフラやパイプラインへの セキュリティツールの組み込み • パイプラインのガバナンス整備 など • セキュリティレビュー • ツールの導入支援 • 攻撃事例の調査 • 各種相談 • 定例開催

セキュリティは難しい

セキュリティは専門知識が必要。

• インスタンスとコンテナで Hardening はどう異なる？

• Forensic のために何が必要？

• コンテナへの攻撃事例にはどのようなものがある？

• Security オペレーションにどのような変更が生じる？

タイミング

Native

開発

既存

移行

Test

Bed

Haste

開発

Demo Day の開催

Monthly で、Dev と Ops の参加者に状況や機能を紹介

1. CI パイプライン とデバッグ機能 2. 結合テスト手法

3. AMI と Docker BaseImage のパイプライン 4. Haste を使った開発とデバッグのトライアル 5. メトリクス 6. CD のプロトタイプ 7. コンテナに移行を容易にする結合テストの設定 8. パイプラインに必要な資材の Scaffolding 9. ログの調査手法 開発スクラムと共催

On-boarding Program

サービス開発スクラムチームの学習コストを下げる

• パイプラインを容易に設定する Scaffolding ツールの提供

• コンテナ開発を行うための Hands-on の開催

サービスイン

大きなリスクを積極的にとるのではなく

リスクを小さくしながら進める

移行サービス

テストベット

お知らせ系

トロフィー系

フォロー系

12

Task

20

Task

300

Task

200

Task

社内利用サービス

CICD Team 主導 Ops Team 主導 本番サービス

2017-04 完了 2018-03 完了 2018-05 完了 In progress

進め方

ステージング環境 (複数) からはじめ本番環境へ

• コンテナのサイズは全環境同じ、タスク数が異なる

本番サービス移行 by Ops

お客様に影響を発生させないために

やったこと

• 移行手順の整備、レビュー • サイジングと余剰キャパシティの設置 • カットオーバークライテリアの設定と、移行前後のエラー、性能計測 • EC2 基盤への切り戻し手段の整備

やらなかったこと

• オートスケーリング ( in / out )

結果

お客様に影響なし

性能劣化なし

エラーの変動なし

トラブル

お客様に影響のあるトラブル無し

ステージング環境で解消

• コンテナが落ちる (チューニング誤り、スクリプトのバグ) • コンテナが生成できない • 特定クライアントからの接続 NG • 移行前後のサービスが別 VPC にあり両方を ALB に登録できない

本番環境で解消

• 低頻度でコンテナが落ちる (チューニング誤り) リトライ+自動復旧

速度

ステージング環境へのデプロイ

本番環境へのデプロイ

1

日

→

20

分

2.5

倍高速

Github でのマージからステージング環境でのデプロイ終了まで Ops の手動作業、資材の準備からデプロイ完了まで

サービスの起動

分

単位

→

秒

単位

ALB のヘルスチェックに要する時間を除く

PSN のお客様に、より多くの体験を届けたい。

一歩前進！

エンジニアの輪

Docker 楽しい !

Contribute!

たくさんの Docker Image

難しさ

開発者の「開発の加速」の体感

• ラップトップ PC 上での開発はまだ加速していない • AWS はラップトップ PC 上での開発には、まだ十分にリーチできていない • Kubernetes ?

アプリケーションアーキテクチャの課題

• 依存サービスもコンテナ化し、自分専用の開発環境を立ち上げたかった • 既存のサービスは非常に依存関係が複雑「依存サービスもコンテナ化」が困難

難しさ (Cont.)

AWS Managed Service の CI への組み込み

• 求む AWS Managed Service の公式コンテナ、代替ソリューションは互換性に課題 • テスト毎に Managed Service を立ち上げるのは遅いよね

“調査” の難易度

• 調査で見るべき箇所が増え、調査の難易度が上がったとのフィードバック • Docker レイヤの追加や、コンテナの生存期間の短命化なども原因に

コスト管理

• 共用クラスタ上の複数のサービスに、どのようにコストを配分するか

難しさ (AWS Managed Service)

膨大かつ進歩の早い AWS Managed Service をどう理解し、どう使うか

AWS の提供／推奨機能は簡素なことが多い • どうしても必要な機能がなければ作る AWS の世界の部品は多く便利 • AWS の世界の外側、たとえば Docker の世界では、もちろん別途作り込みが必要 • 似たような部品もあるので迷うことも AWS の提供するサービスは “部品” が多い • 複数の部品を組み合わせて使う場合には、Glue コードが必要なことが多い

難しさ (AWS Managed Service) (Cont.)

コンテナ周りは作り物が多かった

• コンテナの Bootstrap 処理、安全な環境変数の受け渡し • Deployment Tool, Canary Testing や Blue Green Deployment • ラップトップ PC からテスト用の ECS Task を起動するツール • セキュリティインテグレーション

• 多くのカスタムメトリクスやログまわり

• Docker Image - 例えばテスト用の DynamoDB Local Container • など

今後

私の経験、私の視点より

変化への対応

未来の予測は難しい

2014

インスタンスと Chef の世界

2018

未来の予測は難しい

予測できたか

• Docker 本体に Kubernetes

予測できるか

• 今後コンテナとファンクションの どちらが優勢になるか

変化を受け入れる、変化する前提で進める

変化しにくいものに “最初に” 投資する

• 本件で言えば ECS, Kubernetes ではなく “Docker”

作りすぎない

• 作れば、そこから運用が始まる

捨てる勇気をもつ

• 作ったものと同等機能の Managed Service がでたら思い切って乗り換える • 新しいデファクトスタンダードがでたら思い切って乗り換える

DevOpsSec / CICD の流れと人の変化

DevOpsSec の流れ

• Dev, Ops, Sec 全ての要素が必要、一つも欠かせない

CICD の流れ

• Dev, Ops, Sec の境界は今後さらに複雑かつ曖昧になる

変化に備える、特に人の変化には時間がかかる

一緒に取り組む仲間を見つける

More Dev, Less Ops

お客様により多くの価値を届けるために

方向性は More Dev, Less Ops

そのためにも、

We are hiring!

登場人物になりませんか？

SIE では、グローバルに広がる開発拠点と協業しながら、

PSN の開発・運用を行うエンジニアを募集中しています。