PlayStation(TM)Network とコンテナ, CICD · • 高品質：本番環境での利用事例、spof レス • AWS サービスとの密な連携と、強力なサポート •

©Sony Interactive Entertainment

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 カ国

(2017年12月31日時点) (2017年12月最終週) (2018年3月末時点) (2018年3月末時点)

© Sony Interactive Entertainment Inc. All rights reserved. Design and specifications are subject to change without notice.


お話しする内容 PSN 東京拠点で、フルスクラッチでコンテナ基盤と CICD を実現し、サービスインした話

コンテナ基盤 CICD サービスイン


コンテナと CICD “私達のケース” 企画から導入、運用まで、何をどのように考え、判断し進めたか。

• 今回、尖ったことや斬新なことは行わなかった • 先進的から教科書的まで、多くの情報が Web にある

それでも実現に約二年を要した、その内容をご紹介します。同じテーマに取り組んでいる方のご参考となれば幸いです。


目次 1. 2016 | 出発前 2. 2016 | 出発点 3. 方針 4. アーキテクチャ 5. 設計のポイント 6. 進め方 7. 組織の協業

8. 広める！ 9. サービスイン 10. 2018 | 達成 11. 困難 12. 今後 13. 結び


2016 | 出発前本セクションには、後の成果を目立たせるために悲壮感の演出があります


東京拠点の規模

• 数十サービス (二桁後半)

• 数千インスタンス • ほぼ AWS 上 • EC2 インスタンスと Chef


いわゆる Dev と Ops と Sec

! “DevOps” ! “DevOpsSec”

組織

Dev Ops sec


サービスデリバー組織の構造＝システムの構造 (コンウェイの法則)

CI リリース D 準備

進む個別最適化

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

Ansible Chef


既存の仕組み

Dev と Ops それぞれの努力の成果ちゃんと機能する

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

リリースからデプロイに一日以上かかることも…


2016 | 出発点


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


新しい部署の発足サービスデリバリーを扱う部署が Dev に発足。三人のエンジニアが立候補して参加し、私はチームリードを担当。今は 10 名程度のチームです。


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

• アベイラビリティを下げること無く、迅速かつ効率的にサービスをデリバーすることで一日 100 回のリリースとデプロイができ、本番運用可能な基盤構築を目指す

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

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


Project Haste 加速しそう！


Haste CICD とは Haste CICD はコンテナの作成、開発、デプロイから運用に至るすべてを提供します。継続的インテグレーション＋継続的または手動デプロイ＋コンテナ実行環境 (開発と本番) ＋ Docker BaseImage ＋セキュリティ＋オペレーションエクセレンス (Auto-scaling やログ、監視、メトリクスなど)

Haste CICD


セキュリティは本当に重要セキュリティを全てにおいて 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

Internal Service B


2016 年の判断 Orchestration Tool ECS Kubernetes や Docker Swarm ではなく？ • シンプル：学習コストが低い、機能は限られる • 高品質：本番環境での利用事例、SPOF レス • AWS サービスとの密な連携と、強力なサポート • 当時の Kubernetes や Docker Swarm は発展途上に思えた

今大切なことそれはコンテナ化 • コンテナ化されていれば、必要な時に他のソリューションへも移行できると考えた


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

ログ

メトリクス

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

アプリケーション集約と蓄積

監視ツール

Kinesis: 損失を最小限に抑えるログ / S3: 一定の損失を許容するログ

ホストとコンテナ

ログツール

Event Processing


CICD (ステージング環境まで)

アーキテクチャ (CICD) Github の裏で動く、CodePipeline を中心とした軽量フレームワーク

github

ステージング

Build

Inspect

Test

Auto re-deploy

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 を越えると… • アカウント全体で KMS の API がスロットルされて大変だ！


基盤: 環境構成同一構成のステージング環境と本番環境 • インスタンス数の差異のみ • 環境に起因する問題を早期に見つけられる • 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 • Hardening

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 の登録と自動デプロイ

Release パイプライン • 本番環境への Docker Image の登録

他にCICD インフラ用もある • AMI 用 • Docker BaseImage 用


“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

AWS Management Console は今後に期待！


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) のサポート • 承認者による承認プロセスや監査への対応 • トラブル時のロールバック • 任意のバージョンの ECS Task へのロールバック • など


進め方


進め方

• Haste 開発 • Test Bed ：社内利用サービスを移行 (１サービス、切り戻し可)

• 既存移行：本番サービスを移行 (３サービス、切り戻し可)

• Native 開発：サービスを最初からコンテナで開発

Native 開発 Tune 既存

移行 Tune Test Bed

Haste 開発


かかった時間は約二年

• Haste 開発：９カ月 • Test Bed ： 10カ月評価とチューニング • 既存移行：７か月最初のサービスの Dockerize から移行まで • Native 開発：２か月最初のサービスのステージング導入まで



Haste 開発


Ops Team

Dev Team

役割に変化

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

CICD Team



Haste 開発


組織の協業たくさんの人との連携と協力


Ops Team

Dev Team

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

CICD Team

コンテナに OS やミドルが含まれる、デプロイを一部 Dev が行うといった点で、Dev と Ops の境界が複雑かつ曖昧に。 • 多くの人との議論 • 多くの人の理解と協力

Haste 開発パイプライン構築コンテナ化パイプライン利用サービス構築サービス運用


多くの人を巻き込んだ


開発マネジメントによる工数確保の支援と、積極的なスクラムチームの参加。

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

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

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

• パイプラインや Dockerize の設計支援 • フレームワークの対応、環境変数や ECS Task IAM Role など


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

• インフラの設計支援 • 設計レビュー

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

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


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

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

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


Sec の人は最初から協力的

開発から運用まで、新基盤に最初から適切なセキュリティを導入できることは、Sec としても効率的

成果協業 • セキュリティ対策の立案 • セキュリティポリシーへの準拠 • インフラやパイプラインへの

セキュリティツールの組み込み • パイプラインのガバナンス整備など

• セキュリティレビュー • ツールの導入支援 • 攻撃事例の調査 • 各種相談 • 定例開催


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

• インスタンスとコンテナで Hardening はどう異なる？ • Forensic のために何が必要？ • コンテナへの攻撃事例にはどのようなものがある？ • Security オペレーションにどのような変更が生じる？

プロジェクトの立ち上げ当初から協力を依頼し、一緒に取り組んだ。


タイミング

Native 開発

既存移行

Test Bed

Haste 開発

最初からカラフル、最初から Dev, Ops, Sec, AWS！


広める！伝え、応える


Demo Day の開催 Monthly で、Dev と Ops の参加者に状況や機能を紹介 1. CI パイプラインとデバッグ機能 2. 結合テスト手法 3. AMI と Docker BaseImage のパイプライン

4. Haste を使った開発とデバッグのトライアル

5. メトリクス 6. CD のプロトタイプ 7. コンテナに移行を容易にする結合テストの設定 8. パイプラインに必要な資材の Scaffolding 9. ログの調査手法

開発スクラムと共催


Slack Channel


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 11ヶ月


進め方ステージング環境 (複数) からはじめ本番環境へ • コンテナのサイズは全環境同じ、タスク数が異なる • アプリケーションの設定やネットワーク設定には差異がある

ステージング環境本番環境


本番サービス移行 by Ops お客様に影響を発生させないために

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

やらなかったこと • オートスケーリング ( in / out )


結果

お客様に影響なし性能劣化なし

エラーの変動なし


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

ステージング環境で解消 • コンテナが落ちる (チューニング誤り、スクリプトのバグ)

• コンテナが生成できない • 特定クライアントからの接続 NG • 移行前後のサービスが別 VPC にあり両方を ALB に登録できない

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


2018 | 達成


速度ステージング環境へのデプロイ本番環境へのデプロイ

1日 → 20 分 2.5 倍高速 Github でのマージからステージング環境でのデプロイ終了まで Ops の手動作業、資材の準備からデプロイ完了まで

サービスの起動

分単位 → 秒単位 ALB のヘルスチェックに要する時間を除く


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

一歩前進！


エンジニアの輪

Docker 楽しい !

Contribute!

-- snip --


たくさんの Docker Image

Amazon ECR


困難


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

アプリケーションアーキテクチャの課題 • 依存サービスもコンテナ化し、自分専用の開発環境を立ち上げたかった • 既存のサービスは非常に依存関係が複雑「依存サービスもコンテナ化」が困難 • サービスの Decoupling, コンテナデザインパターンや、サービスメッシュなど、コン

テナを活用するアプリケーションアーキテクチャも必要か


難しさ (Cont.) AWS Managed Service の CI への組み込み • 求む AWS Managed Service の公式コンテナ、代替ソリューションは互換性に課題 • テスト毎に Managed Service を立ち上げるのは遅いよね

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

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


難しさ (AWS Managed Service) 膨大かつ進歩の早い AWS Managed Service をどう理解し、どう使うか AWS の提供／推奨機能は簡素なことが多い • どうしても必要な機能がなければ作る

AWS の世界の部品は多く便利 • AWS の世界の外側、たとえば Docker の世界では、もちろん別途作り込みが必要 • 似たような部品もあるので迷うことも

AWS の提供するサービスは “部品” が多い • 複数の部品を組み合わせて使う場合には、Glue コードが必要なことが多い

AWS の世界の変化は速い • 継続的にキャッチアップしてゆく必要


難しさ (AWS Managed Service) (Cont.) コンテナ周りは作り物が多かった • コンテナの Bootstrap 処理、安全な環境変数の受け渡し • Deployment Tool, Canary Testing や Blue Green Deployment • ラップトップ PC からテスト用の ECS Task を起動するツール • セキュリティインテグレーション • 多くのカスタムメトリクスやログまわり • Docker Image - 例えばテスト用の DynamoDB Local Container • など


今後私の経験、私の視点より変化への対応


未来の予測は難しい 2014 インスタンスと Chef の世界

2018 コンテナ、CICD の世界


未来の予測は難しい

予測できたか • 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

そのためにも、

もっとコンテナ、もっと Serverless


We are hiring!

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

SIE では、グローバルに広がる開発拠点と協業しながら、 PSN の開発・運用を行うエンジニアを募集中しています。


本日はご清聴いただき、誠にありがとうございました。


PlayStation(TM)Network とコンテナ, CICD · • 高品質：本番環境での利用事例、spof レス • AWS サービスとの密な連携と、強力なサポート •

Documents