JAWS-UG京都#5 rebootでの発表資料

1. Ｊリーグ.jpの舞台裏
2015年10月21日
cloudpack 齋藤 康征
(saitara)

2. 自己紹介
☁ アイレット株式会社cloudpack事業部
☁シニアサポートエンジニア
☁過去の職歴
– ファームウェア開発(民生品・業務機器)
– ISP/IDC
– ポータルサイトのインフラ設計

3. いきなり余談
☁アイレット株式会社には「さいとう」が6
名在籍
☁苗字だけでは判別不能
☁フルネーム or ニックネーム必須
☁「さいたらさんお願いします」でおｋ

4. 今回のお題
☁「Ｊリーグ.jpの裏側」構築運用あれこれ
☁お詫びというかご注意というか
– 使用サービス地味です
– 使用テクノロジ地味です
– 技術ネタ少なめです
– 故にカジュアルに試しやすいお題だと思います

5. Ｊリーグとは
☁日本語表記では「Ｊ」は全角でお願いし
ます
☁公益社団法人日本プロサッカーリーグが
主催するサッカー大会
☁日本国内の37都道府県に本拠地を置く52
クラブが入会、大会規定に基づき対戦
☁上記大会情報を「Ｊリーグ.jp」にてお届
けします

6. Jリーグ公式サイトって
何やってるの?
☁平時
– 大会日程・順位表などの公式データ
– コラム・写真などファン向けコンテンツ
☁試合開催時
– ライブ速報(スコア・選手交代等)
– テキスト速報(詳細情報)

7. 事例許可いただけました

8. お客様のご要望
☁落とさない
– 安定性の向上
– 「止まる・落ちるという状態は存在しません」
☁コストの適正化
– 通常時と試合開催時の負荷の差を埋める
☁お客様との共有
– 事後対応ではなく事前対応や報告

9. ご要望を実現した構成

10. 落とさない
☁平時と試合開催時の要求リソース量の差
– おおむね20倍程度
– AWSご利用前はオンプレミス
­ 普段はリソース余剰が大きかった
­ 試合開催時はリソースが逼迫
☁スケールアップ・スケールアウト
☁Multi-AZなどの多重化

11. コスト適切化
☁試合開催日以外は最小構成
– EC2/ELB/RDSを最小限に
☁試合開催日は設備拡張
– 負荷を受け止められるだけ準備!
– J1/J2/J3/ACL/ナビスコ/天皇杯で違う
­ RDS/EC2
☁人力ラーニングへ

12. 人力ラーニング
☁想定訪問者数の推測
– カテゴリー
– 対戦カード
– 天候
– その他要因(昇降格/優勝など)
☁訪問者数に合わせた構成の算出
☁自動制御ではなく人が判断
– 現在はラーニングは完了、定型化

13. 人力のその後
☁拡張計画を入力
– 拡張実施(cron)
­ RDSリードレプリカ生成
­ 準備済EC2起動
­ コンテンツ同期
­ レプリカ遅延確認
­ curl+αでコンテンツ同期確認
­ ELBに接続
­ 途中経過はslackへ通知

14. お客様との共有
☁試合後の稼働状況報告
☁(問題になる前の)気付きの共有
☁お客様より先に気付く・準備する

15. 余談:きつかった試合
☁J1開幕戦
– 手元にあるデータがまだ少なかった
– 設備には余裕あり、人に余裕なし
☁ACL G大阪vs全北現代
– アウェイゴールこわい…
☁2015年10月17日J1
– 降格確定するかも?→順位表に殺到
– 確定するのがナイトゲーム後
– 延々と高止まり

16. 技術的なポイント
☁LAMP構成
– Apache+PHP
– RDS(MySQL)
– チューニング
­ Linuxカーネルの設定調整
­ HVM/SR-IOV/RPS/XPS
­ Apacheのモジュール調整
­ EC2とRDS-RRを同一AZに
­ AutoScalingではなく自前スケーリング
­ RDSクエリキャッシュ

17. 似たようなこと出来る?
☁基礎的なAWSサービス利用で出来ます
– EC2/ELB/RDSでも相当できます
☁順次半投げ・丸投げに移行?
– AWSのトレーニングを受けましょう
– JAWS-UGとかで聞いてみましょう
☁そもそもめんどいやん誰かやってーや
– APN(パートナー)に聞いてみましょう

18. 結論
☁要素要素は非常にシンプル
☁よく知られた手法でもなかなか出来る
☁予測(P)→実践(D)→確認(C)→調整(A)
☁準備8割

19. We're hiring!
☁たっぷりAWS使えます
☁(様々な意味で)キレる同僚/役員
☁服装髪型(スキンヘッド以外)自由
☁戦力になるなら犬でもおｋ(実話)
☁案件山盛り(量も質も)
☁謎の福利厚生

20. 福利厚生例