今年も一応仕事として参加。久しぶりの幕張メッセだった。
基調講演 10:00-11:30
最初は「これって聞く必要はあったのか？」と思わせる何も栄養ない話がされていた。しかも通訳しながら。
その中できになったのは、新しく発表されたAWS App Mesh
あと、最後に紹介された
AWS DeepLens、AWS DeepRacer。
特にDeepRacerはちょー面白そうだった。丁度サイバーフォーミュラ世代としては
今後アルザードを作れるかも知れない、ときめきか。
スタッフに聞いたところ、アメリカで7月予約販売で399ドルらしい。
ただし、やっぱり席が狭い。隣が臭い。しかも終わる時間がギリギリ。
来年は終わる頃に入って聞いても良いかも。
【初級】AWS コンテナサービス入門 12:00-12:40 C
・Amazon ECS、Amazon EKS、Amazon ECR、AWS Fargateについての概要説明
・今まで何となくネットで拾っていた知識をまとめられる機会になった。
・まとめ
コンテナーの洗い出しとAmazon ECSの説明。
コンテナーのオーケストレーター
タスク、サービスについて。
Amazon EKS（kubernetes）
kubectlというツールを使用
pod、deployment、service、jobの概念。
Amazon ECR
プライベートなイメージレジストリ
これは知らなかった。
AWS Fargate
仮想マージンのバッチ当て、スケールイン・アウトを管理
今まで知識の振替・整理ができた。
Kubernetes on AWS（Amazon EKS実践入門） 13:00-13:40 A
・緊急の調査が入った為、殆ど聞いてない
・まとめ
Amazon DynamoDB Deep Dive 14:00-14:40 B
・本来は
「クラウドの利用メリットを最大化するための組織体制とそれを支える基盤テクノロジーの紹介」を選んでいたけど、調査の為、移動を損ねた。というか調査の続き。
・Bust Capacity
ストックしたキャパシティを超えてしまうと、バーストされスロットリングされてしまう現象。
・Adaptive capacity：ホットパーティションが発生しそうな場合、他のパーティションでキャパシティが余っていたらそれを利用できること。
・NoSQLの場合、正規化すぎるのは良くない。操作しやすいモデリングをするべき
・ED図とアクセスパターンのUSECASEを作成するべき
・まとめ
ロマサガRSの大規模トラフィックを捌くAmazon ECS & Docker 運用の知見 15:00-15:40 I
・人が多すぎだった為、立ちながら観覧
・2018/12リリースしたサービス。
・お知らせサーバー/ゲームサーバー/認証サーバーで構成されていて、プレイヤーデータ/セッション・キャッシュ/認証データを持っている。
・ECSにnginx、python、言語はelixir（関数型言語）を利用
・100%docker運用、９９％cloudformationで管理。オーケストレーションはECS。
・kumogata/kumogata2でコード管理（rubyのcloudformatonラッパーツール）
・スケール時間が遅い、FargateだとログがCloudwatchLogsのみの運用になるので
AWS FargateからECSに戻している。
・エラーログ：Datadog logs management、クセスログ：S３
・ECSスケールアウトの工夫
スケールインするEC2上のECSを停止させたいが、停止するEC2とECSタスクが一致する保証はない。
→完了イベントをキャッチしてlamdaコンテナを起動するように実装
・まとめ
めざせ！サーバレスプロフェッショナル 16:00-16:40 A
・今までネットで拾っていた知識で何となくやっていていたCloudFormationテンプレートの書き方について説明をもらった。
・serverlessフレームワークよりAWS SAMを利用するのも良いような気がしてきた。
・github awslabsにテンプレートが用意されている。
・ローカル環境でのテストはaws sam cliを利用。
・aws code starはテンプレートを選ぶだけで利用できる。
・まとめ
Fate/Grand Orderにおける大規模なデータベース移行と負荷試験 17:00-17:40 K
・DELiGHT WORKS社
・環境
EC2 / Aurora / Elastic cache / C#
UPDATE / INSERTがかなり多い
クライアントアプリもユーザーの状態を持っている
・移行の背景
- 2015/7 ロンチ後に予想外にユーザーが増えすぎた。垂直分割（テーブルを分離）では捌けなくなった。
- インデックスが乗らなくなった為、DBのデータ量増加によるデータ移行。
・垂直分割は最大のインスタンスタイプ以上のスケールができない。
・内容は知っていたけど、垂直分割・水平分割といた用語が改めて分かった。
・不可軽減の為のデータ移行時には移行前後の比較、目標値に到達しているかを確認するのが大事。
・スケール可能な構成をリリース前から考えておくのが大事。
・ゲームをやったことがないから専門用語（？）が出るところは話がわからなかった・・
・まとめ
・参考
垂直分割と水平分割の違いについて。
その他
VPNとの組み合わせの問題か、WIFIでの接続が重い＆切れやすかった。
