YAPC::Asia TOKYO 2015 で発表してきました
YAPC::Asia TOKYO 2015 に前夜祭から参加してきました。
謝辞
トークを採用してくださった YAPC::Asia Tokyo 2015 実行委員会・運営の皆様、
足を運んでくださった皆様に厚くお礼申し上げます。
発表内容
ソーシャルゲームにおける AWS 移行事例 - YAPC::Asia Tokyo 2015 というタイトルで発表してきました。
AWS 移行時の小ネタ集のような内容です。
各種 perl の話しは AWS 以外でも使える話しになっているかと思います。
MySQL のデータ移行も使えないことはないかと思いますが、
AWS 以外(MySQL のマネージドサービスを使わない)の場合は、
mysqldump 以外の方法を使ったほうが早いケースがほとんどですね...
発表時は時間がなくて省略しましたが、Zabbix の監視周りの話しも参考にしていただける内容になっているかなと思います。
Consul については、いきなり本番投入するのはおすすめできませんが、
しっかり検証して内部 DNS から導入していただくと、
強力なツールになるのではないかと思います。
発表では、mysqldump の実行時間はふれませんでしたが、
40 分ほどでしたのでトータルで 249分 から 133 分に短縮できました。
また、発表時は省略しましたが、事例 2,3 は MySQL 5.1 と 5.5 でしたので、
それぞれの最速手順でデータ移行を行っていたりします。
dnsmasq とUnbound を使っているという内容について、 Unbound に forward も行わせて、
各サーバに DNS のキャッシュを持てばいいのではないかと思った方もいらっしゃったと思いますが、
最初は dnsmasq だけで運用していて、VPC の DNS resolver が応答を返さなくなるという問題が発生してから Unbound を入れたという経緯があったため dnsmasq + unbound という構成になっています。
また、資料を作成している時に Unbound に forward させようと色々試してみたのですが、
うまく動作させることができず断念してしまいました。
こちらについては後ほどもう少し検証して記事を書きたいと思います。
スライドについて不明な点などございましたら、
@tkuchiki に連絡いただければお応え致します。
発表の補足
発表時に MySQL のデータインポート時間がどのくらい短縮されたかのスライドが抜けていたため、
口頭での説明になってしまいました... 申し訳ございません。
発表後に追加したものが以下のスライドです。
あとから振り返って、説明が不足していたと思ったところを、
以下の twitter まとめを元に補足しようと思います。
dev サーバ
これは、当日まで開発環境と書くか迷って、そのままにしてしまいました...
@mix3 さんが補足してくださっていたとおりです。
ありがとうございます！
ElastiCache for Redis で FLUSHALL を使って無理やり Failover させる
FLUSHALL が終わらないという状況は、詳しく説明すると以下の様になります。
1. 10GB くらいのデータを import
2. FLUSHALL
3. 30 ~ 60sec くらいブロック
4. Failover
5. Slave が Master に昇格
6. Master(昇格した Slave) のデータ容量が import 時の状態(10GBくらい) になる
7. もう一回 FLUSHALL
8. また Failover して Slave が Master に昇格
9. 最初の import 時の状態(10GBくらい)に戻る
10. 以降 7 ~ 9 繰り返し
のような状況になりました...
途中で諦めてインスタンスを削除して作りなおしました。
Failover しない程度に細かく削除していけば良いと思いますが、
時間がかかりそうでしたので楽な方法を取りました。
Multi-AZ にすると書き込み速度が2倍になる
こちらは @fujiwara さんが補足してくださっていましたが、
以下のドキュメントを引用すると、
マルチ AZ 配置を使用する DB インスタンスでは、同期データレプリケーションが発生するため、シングル AZ 配置より書き込みとコミットのレイテンシーが増加する可能性があります。
となります。
ということで書き込み速度が2倍になるというのは適切な表現ではありませんでした。
失礼致しました。
HW スケールアップでレスポンスタイムを改善
HW スケールアップというと、CPU のコア数やメモリが増えたということをイメージされる方が多いと思いますので補足しておきますと、
コア数は移行前より減少しましたが、 1 core あたりの性能が向上したことでレスポンスタイムが改善されました。
発表を聞いての感想
前夜祭を含め、ほぼすべての時間の発表を聞くことが出来ました。
どの発表も大変興味深い内容で、充実した時間を過ごすことが出来ました。
発表者の皆様、ありがとうございました。
発表してみての感想
7月 にとある勉強会で LT をしたのが初めてで、
2回目の発表が YAPC という状況でした。
資料は 7 月の 3 連休から作り始めて、
細かい修正は当日の 10 時くらいまで行っていました。
練習のために何回も資料を見ていると、
このスライド全然面白くないな... と思うようになってきて、
かなり暗い気持ちで 2 日目の発表を聞いていました。
しかし、発表前にプロジェクタへの接続テストを終えて 5 分くらい席を外して戻ってくると、
満席状態で更に立ち見の方までいらっしゃりとても感動しました。
あまりにも感動しましたので、インターネットに載せるときはモザイクをかけるという前置きをして、
発表者視点の風景を写真を撮らせていただきました。
少しでも皆様の参考になるような内容になっていたのであれば幸いです。
改めて足を運んで下さった皆様ありがとうございました！
