[レポート]YAPC::Asia TOKYO 2015 Day 2(インフラ系) #yapcasia

YAPC::Asia Tokyo 2015 Day 2に参加してきました。私が聴講したトークの中から、インフラよりのものを中心にごご紹介します。

ISUCONの勝ち方 by Masahiro Nagano

abstract http://yapcasia.org/2015/talk/show/86ebd212-fab3-11e4-8f5a-8ab37d574c3a

3行でまとめると

1. ISUCON は実サービスを意識したパフォーマンス厨向けコンテスト
2. 各システムの動作原理を具体的に理解すること
3. コンテストなので競技ルールに則ること

ISUCON について

ISUCON はWebアプリの高速化コンテストです。 アプリのコードをいじる事ができないチューニングコンテストへのアンチテーゼでもあり、 レギュレーション範囲内であれば、どんなチューニングもOKです。 ベンチマークのためのベンチマークではなく、実際にありそうな Web アプリに対して、サービスの特性を考慮したベンチマーク方法が採用されています。

裏の狙い

バックグラウンドや言語、ロールに関係なく、オープンに競いあうことで、エンジニアと業界の技術力の向上に寄与。

Web アプリのパフォーマンスはなぜ重要か

Webページのレスポンスが遅いと、ユーザーにサービスをしてもらいにくい。 サーバがチューニングされると、より低いサーバスペック、サーバ台数でサービス運営できることになり、ランニングコストが下がる。特に大規模インフラではインパクトが大きい。

ISUCONの勝ち方

• ルール・ベンチマークの計算方法は最初に目を通すこと
• 2−3人が7時間の短期決戦でチューニングするため、コミュニケーションコストが下がるように、メンバー、コミュニケーションツールを選ぶ
• 言語・ミドルウェア・OSノプロファイルツールに慣れ親しむ
• ネットワーク通信は遅い。できるだけ通信が発生しないようにする
• B+treeの気持ちになって、データベースのデータ走査を思い描くこと
• CPUの気持ちになって、プロセス・スレッドのコンテキストスイッチのオーバーヘッドを思い描くこと

など

関連サイト

• スライド TODO
• ISUCON http://isucon.net/

我々はどのように冗長化を失敗したのか Kenji Naito

abstract http://yapcasia.org/2015/talk/show/f2816038-10ec-11e5-89bf-d7f07d574c3a

3行でまとめると

1. 冗長化は自前やることではない。外部サービスを利用すべし
2. MySQL(mysqlfailover)とRedis(Redis Sentinel)の冗長化を目指したが、不具合を解決しきれず、各種シナリオでの検証が不十分のため本番投入できず
3. 疑問点をなくすために完全に検証をやりきる

Master/Slave 構成での Master の切り替え

Consul を DNS サーバとして利用 dnqmasq を使って、.consul ドメインは Consul のIP:PORT で名前を引くようにする Master 障害時には Consul の IP アドレスを書き換える

QA から

Master の IP をインスタンス間で付け替える Floating IP パターンのほうが素直だと思う(QAから) 用途に適しており、Packerなど他のプロダクトからの Hashicorp への信頼から Consul を採用した

関連サイト

• スライド https://speakerdeck.com/kenjiskywalker/yapcasia2015
• Redis Sentinel http://redis.io/topics/sentinel
• CDF : Floating IP パターン http://aws.clouddesignpattern.org/index.php/CDP:Floating_IP%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
• Consul https://www.consul.io/

ソーシャルゲームにおける AWS 移行事例 by tkuchiki

abstract http://yapcasia.org/2015/talk/show/32a684e8-fd21-11e4-94eb-bdc07d574c3a

3行でまとめると

1. AWS マネージドサービスを活用して運用負荷を軽減
2. オンプレからAWSの移行により、リソースのコントロールが楽になった
3. データ移行を伴うインフラ移設では、予行演習を何度もやること

オンプレ→AWS移設について

10数台程度のシステムでは1ヶ月、実稼働2−3人のリソースでAWS移設できた。 ロードバランサー(HAProxy)、MySQL, Redis はマネージドサービスに移行して運用負荷を削減 データ移行時には RDS を Single AZににすると、マルチAZに比べて書き込み負荷が減るので、データ移行時間を削減できる 新本番環境でデータ移行試験を実施 インフラ移設は構成を見直し、システム改善するいい機会

DB の冗長化について

MySQL/Redis

• AWS 丸投げ
• フェイルオーバーは3-5分で完了するので、ユーザーに我慢してもらう

yrmcds

• AWS 移設のタイミングで Kyoto Tycoon からサイボウズ製の Memcached 互換な yrmcds に変更
• Consul の分散ロックを使って Master を決定
• Master が落ちた時は、新規にロックを取得した Slave に VIP を付け替え、Master 昇格させる
• 本番導入後のトラブルにより、 Consul を使うのをやめ、ベストエフォードで手動切替

関連サイト

• スライド https://speakerdeck.com/tkuchiki/sosiyarugemuniokeru-aws-yi-xing-shi-li
• yrmcds http://cybozu.github.io/yrmcds/

データ分析基盤を支える技術 Masahiro Nakagawa

abstract http://yapcasia.org/2015/talk/show/dd8ce20e-fad2-11e4-b6e7-8ab37d574c3a

3行でまとめると

1. 自前運用せず、外部サービス(AWS でいえばRedshift, EMR など)を活用して分析基盤を構築すべし
2. BI ツール・ダッシュボードも自前開発せず、ベンダーから購入すべし
3. SQL は重要

データ分析基盤について

分析するには何をするにもデータを貯めこむのが必要。データがなければ何も始まらない。 今風にデータ分析基板を構築すると、

• fluentd
• hadoop
• Kafka

などたくさんの技術運用があり、(とりわけ Hadoop の)運用負荷がものすごく高い。

※画像は発表スライドから

データ解析したいのであって、インフラ運用したいわけではないではないので、外部サービスを利用すべし。

Amazon でいえば、Redshift, Kinesis, EMR, S3 などを活用して、分析基盤を構築できる。

※画像は発表スライドから

Google や Microsoft Azure にも類似のサービスがある。

BIツール・ダッシュボード

データ管理・可視化・分析など考えるべき要素がたくさんあるため、自前で一から作らないほうが良い。 Tableau のような優れた可視化・分析ツールがあるので、お金を払っていろんなベンダーに頼ったほうが良い。

関連サイト

• 発表スライド TODO
• Treasure Data http://www.treasuredata.com/
• Tableau http://www.tableau.com/