グリーの様々なサービスを支えるクラウド運用およびデータ分析基盤

(1)

グリーの様々なサービスを⽀えるクラウ

ド運⽤およびデータ分析基盤

(2)

⾃⼰紹介

• グリー株式会社インフラストラクチャ部堀⼝真司 • やっていること • 主にクラウド環境の設計、開発、運⽤ • ゲームそのものの開発協⼒は少ない • コンソールの操作より、プログラムを書く⽅が多い • やっていたこと • コンシューマーゲーム → オンラインゲーム → アーケードゲーム → 弊社 • いわゆるゲーム業界の、横断部署や基盤技術を扱うチームがほとんど

(3)

AWS をとりまく環境

SNS

Platform

ゲーム

以外

フィーチャーホン時代からの SNS 中⼼とした GREE はオンプレミスが多め負荷や⼈気が安定しないゲームはクラウド環境多めスタートアップ系や⼩規模サイトなどもクラウド環境が多め

(4)

AWS 環境のゲームと規模感

• 消滅都市２ • リリースからそろそろ三年⽬ • AWS → オンプレ → AWS という歴史あり • ららマジ • 武器よさらば • ホーム画⾯とバトルを⾏き来 • アナザーエデン • いわゆる JRPG でソシャゲとちょっと違う • アカウント数、インスタンス数、利⽤者数 • クローズ済みも含めて、結構多い

ゲーム

多数…

(5)

アカウントの区切り⽅

• ゲーム本番環境

• Amazon EC2 や Amazon RDS が多め

• ゲーム開発環境

• 各ゲームや部署毎に⾃由に使ってよい

• ⼩規模

• Amazon CloudFront と Amazon S3 だけの静的サイト • WordPress + Amazon RDS が⼀組だけあるような • 共通 • 分析基盤やセキュリティ上の都合など • 関連会社、協⼒会社 • 検証環境 • 全部で２００弱

(6)

アカウント依存関係

ゲーム 本番環境 本番環境ゲーム 開発環境 共通系 ⼩規模 関連会社 アカウント/リージョン固有リソースは VPC を分けるだけでは不⼗分 IAM の権限をなるべく⼀様に設定するため、アカウント毎区切るリスクが少なくスピード重視の環境は各々の裁量で運⽤してもらう。インフラチームが呼ばれたときにだけ相談に乗る

(7)

共通系でやっていること

ゲーム 本番環境 モニタリング アナリティク_ス 運⽤ツール セキュリティ 共通系アカウントには他プロダクト、他部署の情報も含まれているため、⼀⽅的にしかアクセスできない情報の流れ的には、 Push/Pull どちらもある

(8)

⽤途ごとにアカウントを分けているので

(9)

アカウント開設、初期⼿順が⻑い

ブラウザで⾒るとこのぐらい⻑い。印刷すると38 ページにも及ぶ • IAM 設定 • AWS CloudTrail 設定 • AWS Lambda 設定 • AWS Config 設定 • その他情報の記録 • GitHub • Spreadsheet

(10)

Amazon EC2 など VPC を使う環境はさらに続く

• Network 設定 • Amazon VPC • Subnet • SecurityGroup • Route, Gateway • ツールのセットアップ • IAM 設定 • AWS Lambda 等など • AMI 構築環境セットアップ • Cookbook • Jenkins • DNS 関連 • Amazon Route53 • Bind • モニタリング対応 • セキュリティ対応要件にもよるけどだいたいどのような案件でも同じようなものが必要になってくる。

(11)

とにかく⼿順が⻑い。

⻑いと間違えやすい。

→ なるべくツール化。

(12)

ツール化も安泰ではない

• シェルスクリプト、 ruby 2.3〜、 nodejs 4.3〜 • そもそもツール利⽤までの障壁が⾼い • Windows 利⽤者が結構ツライ • エラーが出たりすると問い合わせがすぐに来る • テストが書きにくい • 「検証アカウント」でテストしてるが、費⽤は発⽣する • 実際にリソースを⽣成するので時間もかかる • モック作るにも実装がめんどくさい • CLI や SDK 叩くにしてもそもそも実装が⻑くなりがち

• Amazon EC2 Instance を良い感じに複製するツール

• nodejs で 450 ⾏ • IP アドレスの棚卸ツール • .sh で 50 ⾏ • ⾊々なリソース⼀覧を表⽰するツール • ruby で 1100 ⾏ • 年 30 個ぐらいのペースでツールが増える（概算） • 技術的負債化が激しい

(13)

万事オッケーではない。

そこで

AWS

(14)

AWS CloudFormation おさらい

• データ定義で各種サービス・リソースの構築ができる • JSON と YAML が対応 • Update したときは部分的に更新される • 冪等性がそこそこある • 組み込み関数がいくつかあり、関数型⾔語っぽく書くこともできる • ⽂字列操作 • 条件による選択 • パラメータの取得 • 依存関係の順序 • ⼤量のアカウントがあっても、テンプレートを読み込ませるだけ • ⼤量、複数に向いている気がする

(15)

主な⽤途

• Amazon VPC や SecurityGroup などの初期構築

• ほかの VPC と被らないように名前や Cidr アドレスをパラメータにしている

• Amazon RDS や Amazon ElastiCache などのインスタンス構築

• パラメータグループを分け、いつも同じようなパラメータはここで設定 • default でも⼗分動くけど、ゲーム⽤に若⼲チューニング • ノード数や⽤途毎にテンプレートも分けてある • AWS Lambda 関連 • AWS Lambda 単体で運⽤はほぼ無い • IAM Role 作成

• Amazon CloudWatch Events 設定

• Amazon API Gateway や Amazon S3 、Amazon SNS など関連リソースも⼀緒に作成 • ダミーの Function だけ設定し、プログラムのアップロードだけ別途⾏う

(16)

組み込み関数だけでは物⾜りないので、

nodejs で js を eval して JSON.Stringify している

• 左辺のダブルクォートが不要 • 要素の最後のカンマはあっても無くても良い • 普通に JavaScript で式が書ける • 複数のリソースを作るときは、 Object を返す関数を作ったり • パラメータを map で選択したり • ループを展開したり、コメントが書けたり • AWS API でテンプレート外のパラメータを収集 • むしろこれができないとつらい • テンプレートのデプロイツールでバリデーションもある

• AWS Console から Create/Update はしない • 罠対策

“Tags”: [

{ “Key”: “Name", “Value”: "master" }, { “Key”: “Role", “Value”: { "Fn::Join": ["-" ,{ “Ref”: "Prefix" }, { “Ref”: “Suffix" } } ],

Tags: {

Name: "master",

Role : prefix + “-” + suffix, }, // comment

(17)

きみの罠？

Your trap?

AWS CloudFormation

AWS

三⼤難解サービス

のうちの⼀つ

(18)

リソース名を変えると再⽣成されてしまう

• Resources オブジェクトのフィールド名は変えないほうがよい • Resources 単位で作成・削除・更新される • ⾒かけ上は Resources 名を変えただけでも、別物として扱われる • IAM Role でやった場合 • Instance Profile が外れる • 今は付け替えできるけど、昔は Instance 作り直すしかなかった • Amazon RDS でやった場合 • ＼(^o^)／ • ほかにも再⽣成されるケースがある • Web Console で変更できないものを変更しようとすると、危険な可能性あり • AWS::RDS::DBInstance タイプの DBInstanceIdentifier • ＼(^o^)／ • 変えられなさそうなところは変えない

(19)

Delete は⽌められない

• 普通にオペミスなどで削除してしまうケース • 依存リソースがあっても、削除可能な場合は完全に消える • IAM Role • SecurityGroup • 依存リソースがブロックになる場合は部分的に消える

• Amazon S3 Bucket → Object が⼀つでもあると削除できない • Amazon VPC や Subnet など → 削除できない

• 消せないものを残して Delete が⼀時停⽌する

• DeletionPolicy を設定すべき

• “Retain” にすると Delete しても削除されず、無視される

• “Snapshot” にすると、状態が残せるリソースでは最終スナップショットを取得してからインスタンスを削除する

• AWS::EC2::Volume, AWS::ElastiCache::CacheCluster, AWS::ElastiCache::ReplicationGroup, AWS::RDS::DBInstance, AWS::RDS::DBCluster, and AWS::Redshift::Cluster

(20)

⾮同期で処理されるのでスクリプトに組み込みにくい

• シェルスクリプト → Rakefile → テンプレートの Create → 戻って引き続き処理など • (2016年3⽉ごろの更新で wait パラメータが対応) • 独⾃のデプロイツールを準備 • .js → .json の変換だけではない • diff の表⽰と dryrun • COMPLETE 状態になるまでポーリング • Parameter の設定簡略化 • Output の標準出⼒化 • 罠というよりは、 CLI をよく使う企業⽂化によるもの • 作業記録が取りやすいので…

(21)

⼀部リソースはランダムな⽂字列が与えられる

• IAM Role 名 • Suffix に 12U3DBD4GB5D みたいな⽂字列がくっつく • テンプレート内での Ref 関数には問題なし • 乱数が含まれると他のツールで設定しにくかったり、単純に⾒通しが悪い • http://labs.gree.jp/blog/2016/06/15988/独⾃ツールで対応 • 「 Subiamを使いAWSのIAM管理をコードベースでおこなう」 • 省略可能な名前を省略したとき • Redis ノード名など • API Gateway の⼀部リソース • Amazon CloudFormation 関係なくランダムかも

(22)

ほかにも

• ⼀部プロパティーは対応しておらず Web Console や CLI に劣る • バリデーションの動作が違う

• これは Web Console と CLI でも違うことがある

• Amazon API Gateway / AWS Lambda 周辺で記述量が多くなりがち

• 100 〜 500 ⾏

(23)

使わないよりは圧倒的に便利

複数アカウントで効果絶⼤

かゆいところは⾃⼒で対応

AWS

(24)

(25)

グリーの分析基盤

• 分析対象によって⼤きく分けると2種類

• GREE Platform

• ⻑く続いていて、ログに関する変更は多くない • MySQL、オンプレHadoop

• ゲーム、新規事業

• 新規リリースやイベントなど、頻繁に変更が⼊る • オンプレHadoop、AWS、Treasure Data

今⽇話す内容

(26)

ゲームや新規事業の分析体制

• データエンジニアリングチームは分析基盤を開発運⽤

• 各プロダクトの担当者は、分析基盤使⽤してプロダクトの分析を実⾏

• 分析のプロのアナリストチームは各プロダクトのサポート

プロダクトアナリストデータエンジニアリング分析基盤の提供分析のサポート

(27)

グリーで必要とされる分析基盤の機能

• 社内共通のKPIの集計

• プロダクト独⾃にダッシュボードを作成

• アドホックなクエリの実⾏

• 分析⽤途やサポートツールのバックエンド⽤途

• 利⽤者の権限管理

• 低コストな各プロダクトへの導⼊やサポート

• 多数のプロダクトがあるため、⼀つ⼀つに⼿厚いサポートができない

(28)

AWSに分析基盤を作成した理由

• 全社的にクラウドへ移⾏する流れ

• クラウドを利⽤した⽅がサーバー増減が容易

• マネージドサービスを使⽤することでメンテナンスコストを軽減可能

(29)

分析基盤の構成

Amazon Kinesis Amazon Amazon S3 Kinesis API Server BI Tool プロダクトA プロダクトB プロダクトC プロダクトD

(30)

ログの送受信部分について

Amazon Kinesis Amazon EMR Amazon S3 Kinesis Consumer API Server BI Tool KPI Metric プロダクトA プロダクトB プロダクトC プロダクトD

(31)

Amazon Kinesis Streams

• ⼤規模ストリーミングデータのためのマネージドなデータストレージ

• プロデューサーとコンシューマー

• プロデューサー: Amazon Kinesis Streamsにデータを送信 • コンシューマー: Amazon Kinesis Streamsのデータを処理

• シャード

• ストリーム内のグループ

• シャードごとに読み書きにキャパシティがあり増やすことでスケールする

• Kinesis Producer Library(KPL)

(32)

ログの送受信について

• 1⽇のログ量は 500GB ~ 800GB程度

• プロデューサー

• fluentdからKPLを使⽤して送信

• Amazon DynamoDBの更新イベントをDynamoDB Streamを経由して AWS Lambdaから送信

• コンシューマー

• Kinesis Consumer Library(KCL)でログを取り出してAmazon S3に保存

Amazon Amazon

(33)

ログの処理部分について

Amazon Kinesis Amazon Amazon S3 Kinesis API Server BI Tool プロダクトA プロダクトB プロダクトC プロダクトD

(34)

Amazon EMR

• Hadoopなどの実⾏が容易なクラスタプラットフォーム

• 複数のアプリケーションをクラスタで実⾏できる

• Hadoop, Hive, Spark etc..

• クラスタはEC2インスタンスで構成されていて、クラスタ起動時に選択したアプリケーション（Apache Sparkなど）があらかじめセットアップされた状態で使⽤できる

• クラスタ構築時に任意の処理を追加可能（Bootstrap Action） • 独⾃に作成したHiveのUDFを追加する等

(35)

ログ処理部分

• SQLエンジンであるHiveとPrestoを使⽤

• Hive, Prestoそれぞれ別のAmazon EMRクラスタで起動

• APIサーバーからAmazon EMR上のHiveとPrestoにクエリを実⾏

(36)

ユーザーインタフェース

Amazon Kinesis Amazon EMR Amazon S3 Kinesis Consumer API Server BI Tool KPI Metric プロダクトA プロダクトB プロダクトC プロダクトD

(37)

APIサーバー

• 実⾏するクエリは全てAPIサーバーを経由して実⾏

• Web APIを公開していてクエリの実⾏やクエリの結果を取得可能 • クエリの実⾏結果は全てAmazon S3に保存

• 権限チェック

• WEB APIは社内からなら⾃由に使⽤可能

• 社内ツールやBotなどが使⽤

• クエリを実⾏するAmazon EMRクラスターの管理

(38)

BIツール

• Web UIでクエリが実⾏できる

• グラフを簡単に作成できる

• 社内ドキュメント上で柔軟にレポートやダッシュボードが作成可能 • グラフ⽤データはAmazon DynamoDBに保存 • http://labs.gree.jp/blog/2015/12/14582/

• 登録したクエリを定期実⾏することが可能

• ワークフローにはdigdagを使⽤

(39)

(40)

⽬次

• セキュリティ & アクセス制御

• 変更に強いインフラ

(41)

セキュリティ & アクセス制御 (1/2)

• AWSアカウントを跨いだアクセス制御

• 例: Kinesis Streamsへデータを送信するプロダクトを管理しておきたい • プロダクトと分析基盤ではAWSアカウントが異なる • アクセストークン漏洩などのリスクを抑えたい • プロダクトが増えると漏洩のリスクが増える • 楽に管理したい • アクセス権の発⾏/停⽌、利⽤状況の把握など

(42)

セキュリティ & アクセス制御 (2/2)

• Cross AccountのIAM Assume Roleを使⽤

• プロダクトのAWSアカウントにデータ分析基盤のIAM RoleをAssume Roleする権限を付与 • トークンの発⾏が不要

• 利⽤状況はAWS Identity and Access Managementのコンソールで確認可能 • 利⽤停⽌も再開も簡単

IAM Role

(KinesisへのWrite権限) _{Amazon EC2}

AWS Lambda

1. AssumeRoleで⼀時的権限を取得

2. Kinesis::PutRecordsでログを送信

(43)

変更に強いインフラ

• データの保存場所とデータ処理をする場所の分離

• データ処理部を容易にスケールさせられる • 新たなデータ処理部を簡単に導⼊でき、障害対応も容易

• EMRクラスタはステートレス化して使⽤

• クラスタ内に永続的にデータを保存しない • Hive/Prestoのオートスケールが容易 • ログ量の増⼤や分析基盤の利⽤状況に合わせてパフォーマンスを柔軟に変更可能 • Hive/Prestoのバージョンアップも容易 • 導⼊前の検証を⼗分に⾏うことが簡単 • Hiveのバージョンアップ(Hive 1.x系からHive 2.x系へ）に伴うトラブルを事前に回避できた Amazon EMR 旧Hive/Presto APIサーバ BIツールユーザ Amazon EMR APIサーバ BIツールユーザ旧Hive/Presto 破棄

(44)

各種ツールの活⽤による運⽤の効率化、省⼒化 (1/4)

• データ分析基盤の運⽤

• 運⽤専任のメンバーは存在せず、開発者⾃⾝が本番環境の構築運⽤も⾏っている

• AWSの各種APIや周辺ツールを利⽤した効率的な運⽤

• インフラの構築、変更をプログラマブルに⾏うことが可能 • 事細かな運⽤⼿順書が不要 • ⼤量の⼿順を正確に素早く⾏うことが可能 • 少⼈数でも効率的に運⽤を回せる

(45)

各種ツールの活⽤による運⽤の効率化、省⼒化 (2/4)

• AWS CloudFormation

• 堀⼝の発表参照 • （データ分析基盤では）AWSアカウントの初期設定にのみ使⽤

• Terraform

• https://www.terraform.io/ • マルチクラウド対応のインフラストラクチャ管理ツール • シンプルで読みやすいフォーマット（右参照） • リソース間の連携を記述しやすい • 運⽤中に頻繁に変更されるものではないリソースの管理に使⽤

• Security Group, IAM Role/User, Amazon S3のBucketPolicy, Lambda Function, Elastic Load Balancing

Amazon Route53, Amazon CloudWatch

• など resource “aws_security_grpup” “allow_office” {_{vpc_id = “xxxxxxxx”}

ingress {

Security Groupの記述例 (Terraform)

resource “aws_iam_policy” “write_s3” { policy = <<EOF { "Statement" : [{ “Resource” : “${aws_s3_bucket.foo.arn}”, "Action" : "s3:Put*", "Effect" : "Allow"} ]} EOF }

(46)

各種ツールの活⽤による運⽤の効率化、省⼒化 (3/4)

• Chef

• サーバ構築と構成管理のためのフレームワーク • （データ分析基盤では）AMIの作成に使⽤

• AWS CodeDeploy

• プラットフォームや⾔語に⾮依存のデプロイ管理ツール • Web ConsoleやAPIで操作可能なので、デプロイサーバが不要 • アプリケーション依存の処理はスクリプトでカスタマイズ可能

• Kinesis Consumer, APIサーバ、BIツールのデプロイに使⽤

• ダウンタイム無しでデプロイ

1. Upload code

2. Download code

3. Detach instance from load balancer

4. Stop application and deploy code to itself 5. Start application and attach to load balancer

(47)

各種ツールの活⽤による運⽤の効率化、省⼒化 (4/4)

• AWS Lambda

• 定期的な処理の実⾏に使⽤ • 専⽤のサーバを⽤意しなくて済む

• 分析基盤での例

• Amazon DynamoDBのCapacity調整 • 集計batchが動く早朝にWriteのCapacityを上げる、⽇中および深夜は下げる • ⽇中はReadのCapacityを上げる、早朝および深夜は下げる • EMRクラスタやAPIサーバのE2E監視 • 実際にクエリを投げてみる • 異常を検知したらチームメンバーへアラートを通知 • Lambda Functionを追加するだけで監視項⽬が増やせる • 検知ロジックをプログラムで書けるので、実現できる監視内容の幅が広い

(48)

データ分析基盤まとめ

• AWSの様々なサービスを活⽤することで、柔軟なデータ分析基盤を構築することができた

• Amazon Kinesis Streams • Amazon S3 • Amazon EMR • 必要に応じてカスタマイズすることで、社内のニーズにあったシステムを作ることができた • APIサーバ • BIツール • 運⽤⾯においても、AWSのサービスやOSSツールを活⽤しリーズナブルかつ効率的な運⽤をまわすことができた • Terraform • Chef • AWS Lambda • AWS CodeDeploy • など