この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
YAPC::Asia Tokyo 2015 Day 2に参加してきました。私が聴講したトークの中から、インフラよりのものを中心にごご紹介します。
ISUCONの勝ち方 by Masahiro Nagano
abstract http://yapcasia.org/2015/talk/show/86ebd212-fab3-11e4-8f5a-8ab37d574c3a
3行でまとめると
- ISUCON は実サービスを意識したパフォーマンス厨向けコンテスト
- 各システムの動作原理を具体的に理解すること
- コンテストなので競技ルールに則ること
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行でまとめると
- 冗長化は自前やることではない。外部サービスを利用すべし
- MySQL(mysqlfailover)とRedis(Redis Sentinel)の冗長化を目指したが、不具合を解決しきれず、各種シナリオでの検証が不十分のため本番投入できず
- 疑問点をなくすために完全に検証をやりきる
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行でまとめると
- AWS マネージドサービスを活用して運用負荷を軽減
- オンプレからAWSの移行により、リソースのコントロールが楽になった
- データ移行を伴うインフラ移設では、予行演習を何度もやること
オンプレ→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行でまとめると
- 自前運用せず、外部サービス(AWS でいえばRedshift, EMR など)を活用して分析基盤を構築すべし
- BI ツール・ダッシュボードも自前開発せず、ベンダーから購入すべし
- SQL は重要
データ分析基盤について
分析するには何をするにもデータを貯めこむのが必要。データがなければ何も始まらない。 今風にデータ分析基板を構築すると、
などたくさんの技術運用があり、(とりわけ Hadoop の)運用負荷がものすごく高い。
※画像は発表スライドから
データ解析したいのであって、インフラ運用したいわけではないではないので、外部サービスを利用すべし。
Amazon でいえば、Redshift, Kinesis, EMR, S3 などを活用して、分析基盤を構築できる。
※画像は発表スライドから
Google や Microsoft Azure にも類似のサービスがある。
BIツール・ダッシュボード
データ管理・可視化・分析など考えるべき要素がたくさんあるため、自前で一から作らないほうが良い。 Tableau のような優れた可視化・分析ツールがあるので、お金を払っていろんなベンダーに頼ったほうが良い。
関連サイト
- 発表スライド TODO
- Treasure Data http://www.treasuredata.com/
- Tableau http://www.tableau.com/
2
