Ｊリーグ.jpの舞台裏

2015年10月21日cloudpack 齋藤 康征

(saitara)

自己紹介

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

いきなり余談

☁アイレット株式会社には「さいとう」が6名在籍

☁苗字だけでは判別不能☁フルネーム or ニックネーム必須☁「さいたらさんお願いします」でおｋ

今回のお題

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

Ｊリーグとは

☁日本語表記では「Ｊ」は全角でお願いします

☁公益社団法人日本プロサッカーリーグが主催するサッカー大会

☁日本国内の37都道府県に本拠地を置く52クラブが入会、大会規定に基づき対戦

☁上記大会情報を「Ｊリーグ.jp」にてお届けします

Jリーグ公式サイトって何やってるの?

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

事例許可いただけました

お客様のご要望

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

ご要望を実現した構成

落とさない

☁平時と試合開催時の要求リソース量の差–おおむね20倍程度– AWSご利用前はオンプレミス-普段はリソース余剰が大きかった-試合開催時はリソースが逼迫

☁スケールアップ・スケールアウト☁Multi-AZなどの多重化

コスト適切化

☁試合開催日以外は最小構成– EC2/ELB/RDSを最小限に☁試合開催日は設備拡張–負荷を受け止められるだけ準備!– J1/J2/J3/ACL/ナビスコ/天皇杯で違う-RDS/EC2

☁人力ラーニングへ

人力ラーニング

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

人力のその後

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

お客様との共有

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

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

技術的なポイント

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

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

結論

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

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

福利厚生例