9/9に都内某所にて発表したLT資料です。

1. 5年目に突入したAWS運用
振り返り
株式会社ネットマーケティング 管理本部インフラチーム
久松 剛

2. 話者紹介
• 管理本部インフラチーム シニアマネージャー 久松 剛
• Omiaiのインフラ担当として入社
• 全てのITインフラの責任者
• 慶應義塾大学大学院政策メディア研究科博士
• 在学時のテーマ
• インターネットを用いた高画質リアルタイム動画配信
• オーバーレイネットワークを用いた次世代インターネットの基盤技術研究
• 事業仕分けを経て現職
好きなAWS Service：EC2

3. • 広告事業
• アフィリエイト広告の専業代理店
• ダウンタイムに拘る
• メディア事業（Omiai）
• Facebookを活用した恋愛マッチングサービス
• やんちゃなトラフィックとMySQL Query
• Switch事業
• Facebookを活用したスカウト型転職アプリ
• Apache Tomcatを初めて導入
とは

4. と
• 2012年6月18日 久松入社、オンプレミスの環境を棚卸
• 2012年8月 AWSセットアップ開始
• 2012年10月3日 Omiai オンプレミスからAWSへの移行
• 2015年1月8日 Switch. AWSを使ってサービスイン
• 2015年11月11日 ALLADiN オンプレミスからAWSへの移行

5. 非VPC(EC2-Classic)の苦悩
• 2011年8月 AWS VPC正式サービス開始
• 2013年12月4日移行、VPCデフォルトに
→古くからのアカウント
• EC2-ClassicとVPCの苦悩を抱えている
• 具体的な苦悩
• EC2-classicでは利用できないインスタンス
タイプの登場
• VPC Classic Linkに感謝しながら移行
• 最近入社したAWS Supportの人に伝わら
ない
→移行だけで勉強会行ける

6. インスタンスタイプはよく考えよう
当初の予定
• （当時の）EBSの信頼性に疑問
• Auto Scaling前提で設計
• ディスクアクセススピード
• /media/ephemeral0 > EBS
• WEBサーバはS3-backed Instanceで
無慈悲な現実
• いつの間にかEBS-backed Instanceが主流
に
• 高いAuto Scaling化のハードル（後述）
• /media/ephemral0
• アクセススピードは良い
• IOベースのコストも心配しなくてよいが・・・
• I/Oエラー 1回をどう見るか

7. Auto Scalingの是非
• 高負荷時・ピーク時のみ立ち上げることによるコスト削減のクラウドの理想郷
• まとめ
• 不慮の時に対応できる人員
• 監視
• 折れない心
• インスタンスタイプが売り切れることは“ある”
→AutoScalingだけで勉強会行ける

8. 過去一番辛かったMaintenance Events
• 2014年9月28日（日） 3:00-7:00 NEAR-TERM AWS Maintenance EVENT NOTICE
• 9月25日（木）に通知が届く
• “You will not be able to stop/start or re-launch instances in order to avoid this
maintenance update.”
• ただ十数台のインスタンス再起動を見守るしかできない・・・
• 以降は同様の状況はなし

9. 最も辛かったインスタンス移行
• その昔、TokyoにAZは3つあった
• そしてそこにはNFS on EC2があった・・・
• 当時のnfsが抱えるジレンマ
• Magneticしかなかった頃の1TB EBS
• 拡張できない
• IOPS遅い
• lsyncd超遅い
• SnapShotBackup超遅い
• 同一AZでSSD選べず
• （DDとかmvが不可）
→低負荷時（2時-7時）に並列でrsync
• 増えるファイル変更
• EBS・ネットワークパフォーマンスにバラつき
• 時間帯を変えて複数回テストして見積

10. RDSかMySQL on EC2か
• NMでの使用状況
• Omiai: MySQL on EC2
• それ以外: RDS
• RDSで十分なケース
• 負荷が高くないサービス
• 生い立ちが複雑でないプログラム
• MySQL on EC2の利点
• slow_query_logだけではお手上げ
• DB側でのpt-query-digest
• cactiやZabbixで細かくモニタリング
• http://www.slideshare.net/makaibito
/mysql-on-ec2

11. AZを跨ぐか跨がないか
• MAZ
• 対故障性の面で優位
• AWSのパッチ・メンテナンスはAZ単位
• SAZ
• (MAZの場合) ある時を境に大容量データのやり取り時に伝送遅延時間が大きくなる
• レプリケーションなどに影響
• DBについて高トラフィックが発生するケースではSAZもやむなし
• だがしかし
• 同一AZ内よりAZを跨いだ方がTTLが短いケースも確認

12. まとめ
• 低負荷なサービス・単発的なイベント
• Managed Serviceで十分
• 高負荷なサービス・プログラム起因の障害が多いサービス
• CloudWatchだと粗い→cacti / Zabbix等を導入
• 負荷となる原因が分からない場合、低レイヤに踏み込めるUnmanaged Serviceの方がよいケース
も
• 息の長いサービス
• 絶えず情報収集をする必要性
• インスタンスタイプは常に最新を追いかけた方が良い