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

Size: px

Start display at page:

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

ゆうりゅうりゅうとう
4 years ago
Views:

1 PlayStation Network とコンテナ, CICD ソニーインタラクティブエンタテインメント西海持雅隆

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

3 自己紹介西海持雅隆 ( さいかちまさたか ) 10 年近い開発経験 10 年近いインフラ運用経験 PlayStation Network 東京拠点の CICD チームのリード AWS Summit Tokyo 2014 PlayStation 4 (PS4 ) のロンチ時に PlayStation Network 東京拠点のサービスで AWS を全面採用した話のセッションを持つ

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

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

6 数字で見る 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.

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

8 コンテナと CICD 私達のケース企画から導入運用まで何をどのように考え判断し進めたか今回尖ったことや斬新なことは行わなかった先進的から教科書的まで多くの情報が Web にあるそれでも実現に約二年を要したその内容をご紹介します同じテーマに取り組んでいる方のご参考となれば幸いです

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

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

11 東京拠点の規模数十サービス ( 二桁後半 ) 数千インスタンスほぼ AWS 上 EC2 インスタンスと Chef

12 組織いわゆる Dev と Ops と Sec Dev Ops Sec! DevOps! DevOpsSec

13 サービスデリバー組織の構造 = システムの構造 ( コンウェイの法則 ) Ansible Chef CI リリース準備 D 進む個別最適化リリースと準備そしてデプロイ

14 既存の仕組み Dev と Ops それぞれの努力の成果ちゃんと機能するでもサービス数が多く大変リリースからデプロイに一日以上かかることも

15 2016 出発点

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

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

18 企画速度にフォーカスした CICD の仕組みを作るアベイラビリティを下げること無く迅速かつ効率的にサービスをデリバーすることで一日 100 回のリリースとデプロイができ本番運用可能な基盤構築を目指す開発から運用までの全体最適化を図るセキュリティを全てにおいて 1st class citizen として扱う

19 Project Haste 加速しそう!

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

21 セキュリティは本当に重要セキュリティを全てにおいて 1st class citizen として扱うセキュリティの問題が起きるとお客様にゲームを楽しんでいただけなくなってしまう何時でも安心してゲームを遊んでいただけるようお客様のプライバシーお預かりしている情報を全力で守る

22 方針

23 シンプルかつ必要最小限本当に必要なものだけを作る 10 行のコードであっても何かを作れば必ず運用が発生する作る前に最後まで面倒を見れるかを考えてみる極力 AWS のサービスを活用制約を受け入れるできないことも多いがそもそも不要なこと代替できることも多いベンダロックインのリスクは常に意識作り込まずになるべくそのまま使う AWS サービスの薄いラッパーやフレームワークを作る事が多い

24 迷ったら目標を思い出す速度にフォーカスしているかそれは一日に 100 回以上デプロイできる選択肢かセキュリティをなによりも大切にしているかまずやってみる動かして体験することはとても大事 100 点を目指して分析や設計中毒にならない

25 なぜコンテナかコンテナ 80% のサービスが提供可秒単位 ( 起動 ) 当初 Apache +Tomcat の普通の HTTP サービスのみを対象にインスタンスほぼ 100% のサービスが提供可分単位 ( 起動 ) すでに一定の仕組みを構築済みファンクション特定の目的のみで利用可 ( 当時 ) 秒単位いずれ AWS が仕組みを揃えてくれる

26 アーキテクチャ何をどう実現しようとしたか

27 アーキテクチャ ( コンテナ基盤 ) ECS, ECR, ALB, S3 と Route53 など標準的な AWS スタックを極力利用 Public Service A Amazon ECS Amazon ECR Artifact Bucket ACM Internal Service B Amazon Route 53 Service Discovery は現在未使用コンテナ基盤

28 2016 年の判断 Orchestration Tool ECS Kubernetes や Docker Swarm ではなく? シンプル : 学習コストが低い機能は限られる高品質 : 本番環境での利用事例 SPOF レス AWS サービスとの密な連携と強力なサポート当時の Kubernetes や Docker Swarm は発展途上に思えた今大切なことそれはコンテナ化コンテナ化されていれば必要な時に他のソリューションへも移行できると考えた

29 アーキテクチャ (運用監視) データを Kinesis, S3, CloudWatch に集約し極力 Serverless で処理監視ツールメトリクス Event Processing ログツールホストとコンテナ集約と蓄積ログアプリケーション Kinesis: 損失を最小限に抑えるログ / S3: 一定の損失を許容するログ

30 アーキテクチャ (CICD) Github の裏で動く CodePipeline を中心とした軽量フレームワーク github Hook Kick AWS CodePipeline Build CodeBuild に万能感 Feed Baaaaaaaaaaaaaaaaaack! CICD ( ステージング環境まで ) Inspect Test Register Image Auto re-deploy ステージング

31 設計のポイント

32 AWS Well-Architected Framework AWS SA の荒木さんが激推しクラウドアーキテクチャのベストプラクティス集設計の良い目次になる見逃しているポイントに気がつける会社から営業活動のプレッシャーがあるのかと勘ぐるも杞憂に終わる ( 流石です )

33 気がつけることの例データの保護より 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 がスロットルされて大変だ!

34 基盤 : 環境構成同一構成のステージング環境と本番環境インスタンス数の差異のみ環境に起因する問題を早期に見つけられる CloudFormation で容易に構築ステージング環境本番環境

35 基盤 : Subnet 設計はコンテナを十分考慮 AWS サービス毎の差異アタッチできる Subnet 数が異なる ECS Task は 10 Subnet ECS Task ELB は 1AZ あたり 1 Subnet IP アドレス (ENI) 大量消費 awsvpc モードではインスタンス数 + コンテナ数 ENI を消費 Lambda VPC も配慮 NAT Gateway の分散 NAT の障害対策として 1 つの ECS Service や AutoScaling Group が複数の NAT を使うように

36 基盤 : ホスト高速かつ安定した起動を優先 AMI AmazonLinux AMI 必要最小限の種類 Golden AMI Packer と Ansible Serverspec Hardening ECS クラスタ単一の共用クラスタ AutoScaling Scale-in/out CPU 予約率 Memory 予約率消費 ENI 数

37 コンテナ : ECS Task 全サービスで共通のリソース設定 Tomcat は CPU: 1024, メモリ : 2GB などチューニングやサイジングを容易に性能はスケールアウトで確保し最適化は後日 Service AutoScaling httpd Tomcat fluentd CloudWatch カスタムメトリクス TCP Connection, ミドルウェアのスレッド数やコネクション数コンテナ単位のメトリクス慎重なスケールインすべての CloudWatch アラームが収束したらスケールイン

38 CICD: サービス開発用に三種のパイプライン Pull Request パイプラインアプリケーションのビルドとテスト Docker Image の作成と開発環境への登録 Push パイプライン Pull Request パイプラインの作業 + さらなるテストステージング環境への Docker Image の登録と自動デプロイ Release パイプライン本番環境への Docker Image の登録他に CICD インフラ用もある AMI 用 Docker BaseImage 用

39 CICD: Git Branching Model への適合 Git flow でうまく動くよう主要ブランチごとのパイプラインなお CodePipeline は同一パイプラインで追い越しができない for develop branch for master branch

40 CICD: Developer へのフィードバック Developer が大好きな Github や Slack に情報を集約というのも AWS Management Console は正直使いにくい Developer 向けの適切に限定された IAM 権限の設定も難しいデベロッパー体験のため CI の処理状況や詳細を AWS サービスの UI にあまり頼らずこれらに集めた Github - Pull Request や Comment など Slack AWS Management Console は今後に期待!

Pipeline + ECS Service Update 本番環境へのデプロイツール (

41 CICD: サービスデリバー役割により異なるニーズ異なるソリューションステージング環境までの CD パイプライン Dev 作業速度と頻度 Github でのマージでデプロイ Code Pipeline + ECS Service Update 本番環境へのデプロイツール ( ステージング環境でも使用 ) Ops 作業信頼性ガバナンス既存の変更管理プロセスのサポートマニュアルで扱う独自実装ツール

42 CICD: 本番環境へのデプロイツール信頼性とガバナンス重視の手動で操作する独自実装デプロイツール CLI が StepFunctions のワークフローを開始実行される ECS Task や Lambda Function が CloudFormation などで ECS Service, ALB, Alarm を操作 Canary testing Blue-Green Deployment AutoScaling (scale-in / out) のサポート承認者による承認プロセスや監査への対応トラブル時のロールバック任意のバージョンの ECS Task へのロールバックなど

43 進め方

44 進め方 Haste 開発 Test Bed Tune 既存移行 Tune Native 開発 Haste 開発 Test Bed : 社内利用サービスを移行 (1 サービス切り戻し可 ) 既存移行 : 本番サービスを移行 (3 サービス切り戻し可 ) Native 開発 : サービスを最初からコンテナで開発

45 かかった時間は約二年 Haste 開発 Test Bed Tune 既存移行 Tune Native 開発 Haste 開発 : 9カ月 Test Bed : 10カ月評価とチューニング既存移行 : 7か月最初のサービスの Dockerize から移行まで Native 開発 : 2か月最初のサービスのステージング導入まで

46 役割に変化 Haste 開発 Test Bed Tune 既存移行 Tune Native 開発 Haste 開発パイプライン構築コンテナ化パイプライン利用サービス構築サービス運用最初は自分たちで次に使ってもらうそして作ってもらう CICD Team Ops Team Dev Team

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

48 Docker で複雑曖昧になる役割の境界コンテナに OS やミドルが含まれるデプロイを一部 Dev が行うといった点で Dev と Ops の境界が複雑かつ曖昧に多くの人との議論多くの人の理解と協力 Haste 開発パイプライン構築コンテナ化パイプライン利用サービス構築サービス運用 CICD Team Ops Team Dev Team

49 多くの人を巻き込んだ

50 Dev の人は新しいチャレンジに積極的パイプラインや Dockerize の設計支援既存のプロセスやサービスに精通海外拠点とのアラインパイプラインや Dockerize の設計支援最初の Dockerize サービスの担当サービスのレクチャやパイプラインの評価とフィードバックコードの修正パイプラインや Dockerize の設計支援フレームワークの対応環境変数や ECS Task IAM Role など開発マネジメントによる工数確保の支援と積極的なスクラムチームの参加

51 Ops の人もコンテナに興味津々インフラの設計支援設計レビューサービス構築運用監視と移行インフラ構築運用と監視プロセスの整備ドキュメント Runbook の整備 AutoScaling (Host / Task) の実現調査手段や HotFix の実現運用マネージャのアドバイスでサービス運用チームでは有志の参加者を募った 8 名のエンジニアが参加する WG が発足しモチベーション高くタスクを遂行

52 AWS の皆さんはいつも頼りになる採用予定の AWS サービスについて質疑アーキテクチャレビューサービスイン時のサポート各種トラブルのフォローアップ

53 Sec の人は最初から協力的開発から運用まで新基盤に最初から適切なセキュリティを導入できることは Sec としても効率的セキュリティレビューツールの導入支援攻撃事例の調査各種相談定例開催協業成果セキュリティ対策の立案セキュリティポリシーへの準拠インフラやパイプラインへのセキュリティツールの組み込みパイプラインのガバナンス整備など

54 セキュリティは難しいセキュリティは専門知識が必要インスタンスとコンテナで Hardening はどう異なる? Forensic のために何が必要? コンテナへの攻撃事例にはどのようなものがある? Security オペレーションにどのような変更が生じる? プロジェクトの立ち上げ当初から協力を依頼し一緒に取り組んだ

55 タイミング最初からカラフル最初から Dev, Ops, Sec, AWS! Haste 開発 Test Bed 既存移行 Native 開発

56 広める! 伝え応える

57 Demo Day の開催 Monthly で Dev と Ops の参加者に状況や機能を紹介 1. CI パイプラインとデバッグ機能 2. 結合テスト手法 3. AMI と Docker BaseImage のパイプライン 4. Haste を使った開発とデバッグのトライアル開発スクラムと共催 5. メトリクス 6. CD のプロトタイプ 7. コンテナに移行を容易にする結合テストの設定 8. パイプラインに必要な資材の Scaffolding 9. ログの調査手法

58 Slack Channel

59 On-boarding Program サービス開発スクラムチームの学習コストを下げるパイプラインを容易に設定する Scaffolding ツールの提供コンテナ開発を行うための Hands-on の開催

60 サービスイン大きなリスクを積極的にとるのではなくリスクを小さくしながら進める

61 移行サービステストベットお知らせ系トロフィー系フォロー系 12 Task 20 Task 300 Task 200 Task 社内利用サービス CICD Team 主導本番サービス Ops Team 主導完了完了完了 In progress 11 ヶ月

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

63 本番サービス移行 by Ops お客様に影響を発生させないためにやったこと移行手順の整備レビューサイジングと余剰キャパシティの設置カットオーバークライテリアの設定と移行前後のエラー性能計測 EC2 基盤への切り戻し手段の整備やらなかったことオートスケーリング ( in / out )

64 結果お客様に影響なし性能劣化なしエラーの変動なし

65 トラブルお客様に影響のあるトラブル無しステージング環境で解消コンテナが落ちる ( チューニング誤りスクリプトのバグ ) コンテナが生成できない特定クライアントからの接続 NG 移行前後のサービスが別 VPC にあり両方を ALB に登録できない本番環境で解消低頻度でコンテナが落ちる ( チューニング誤り ) リトライ + 自動復旧

66 2018 達成

67 速度ステージング環境へのデプロイ本番環境へのデプロイ 1 日 20 分 2.5 倍高速 Github でのマージからステージング環境でのデプロイ終了まで Ops の手動作業資材の準備からデプロイ完了までサービスの起動分単位秒単位 ALB のヘルスチェックに要する時間を除く

68 PSN のお客様により多くの体験を届けたい一歩前進!

69 エンジニアの輪 -- snip -- Docker 楽しい! Contribute!

70 たくさんの Docker Image Amazon ECR

71 困難

72 難しさ開発者の開発の加速の体感ラップトップ PC 上での開発はまだ加速していない AWS はラップトップ PC 上での開発にはまだ十分にリーチできていない Kubernetes? アプリケーションアーキテクチャの課題依存サービスもコンテナ化し自分専用の開発環境を立ち上げたかった既存のサービスは非常に依存関係が複雑依存サービスもコンテナ化が困難サービスの Decoupling, コンテナデザインパターンやサービスメッシュなどコンテナを活用するアプリケーションアーキテクチャも必要か

73 難しさ (Cont.) AWS Managed Service の CI への組み込み求む AWS Managed Service の公式コンテナ代替ソリューションは互換性に課題テスト毎に Managed Service を立ち上げるのは遅いよね調査の難易度調査で見るべき箇所が増え調査の難易度が上がったとのフィードバック Docker レイヤの追加やコンテナの生存期間の短命化なども原因にコスト管理共用クラスタ上の複数のサービスにどのようにコストを配分するか

74 難しさ (AWS Managed Service) 膨大かつ進歩の早い AWS Managed Service をどう理解しどう使うか AWS の提供 / 推奨機能は簡素なことが多いどうしても必要な機能がなければ作る AWS の世界の部品は多く便利 AWS の世界の外側たとえば Docker の世界ではもちろん別途作り込みが必要似たような部品もあるので迷うことも AWS の提供するサービスは部品が多い複数の部品を組み合わせて使う場合には Glue コードが必要なことが多い AWS の世界の変化は速い継続的にキャッチアップしてゆく必要

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

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

77 未来の予測は難しいインスタンスと Chef の世界コンテナ CICD の世界

78 未来の予測は難しい予測できたか Docker 本体に Kubernetes 予測できるか今後コンテナとファンクションのどちらが優勢になるか

79 変化を受け入れる変化する前提で進める変化しにくいものに最初に投資する本件で言えば ECS, Kubernetes ではなく Docker 作りすぎない作ればそこから運用が始まる捨てる勇気をもつ作ったものと同等機能の Managed Service がでたら思い切って乗り換える新しいデファクトスタンダードがでたら思い切って乗り換える

80 DevOpsSec / CICD の流れと人の変化 DevOpsSec の流れ Dev, Ops, Sec 全ての要素が必要一つも欠かせない CICD の流れ Dev, Ops, Sec の境界は今後さらに複雑かつ曖昧になる変化に備える特に人の変化には時間がかかる一緒に取り組む仲間を見つける

81 結び

82 More Dev, Less Ops お客様により多くの価値を届けるために方向性は More Dev, Less Ops そのためにももっとコンテナもっと Serverless

83 We are hiring! 登場人物になりませんか? SIE ではグローバルに広がる開発拠点と協業しながら PSN の開発運用を行うエンジニアを募集中しています

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

AWS Deck Template

AWS Deck Template AWS OpsWorks のご紹介 Amazon Data Services Japan 2013/06/25 Agenda AWS OpsWorks とは OpsWorks の特長 OpsWorks 利用の流れ OpsWorks のメリット Chef とは OpsWorks のライフサイクルイベントどのようなアプリケーションが OpsWorks に向いているのか? OpsWorks の機能詳細