2015/10/31 Innovation egg 第五回　クラウド運用の本音

1. いけてないオンプレ環境のインフラを
クラウドへ移設
冨田修平

2. アジェンダ
 自己紹介
 ロックオンの紹介
 インフラの現状と課題
 対策
 IaaS環境
 メール、DNS
 実際の移行の流れ
 発生した事件
 同じ事態を繰り返さないために
 今後の展望

3. おことわり
このプレゼンはレガシーなシステムを改善するための日々
の業務を淡々と描くものです。
過度な期待はしないでください。

4. インフラの現状
 全体構成
 台数 数十台
 メーカー
 IBM又はHP
 1U～2U/ブレードの普及帯のラックマウントサーバ
 仮想化の状況
 1/3程度が仮想化(VMware)
 ストレージはサーバ内蔵HDD
 大阪市内某データセンタのハウジングスペースに設置

5. インフラの現状
 Web/DBサーバ
 OS
 Redhat/CentOS 5～6
 一部FreeBSD
 ミドルウェア
 Apache
 PHP
 PostgreSQL
 Postfix
 MySQL
 各サーバの状況は構築手順書などの作業記録で管理されている
 多分
 ECサイト毎に個別にサーバを割当
 いわゆるレンタルサーバ的運用

6. インフラの現状
 メールサーバ(POP3/SMTP)
 ECサイトのお客様との問い合わせ対応などの送受信用
 SPAM対策はあるがウイルス対策はない
 SMTP-AUTHによるメール中継機能を持つ
 過去にSPAMの踏み台にされたことがある
 DNSサーバ
 ECサイトの名前解決用
 キャッシュ兼コンテンツサーバ
 過去にオープンリゾルバでISPから警告されたことがある

7. インフラの課題と対策(1)
 ハードウェア面の課題と対策
 老朽化と運用コスト
 各サーバ毎のハードウェア差異が大きく運用コストが高い
 ソフトウェア(OS以上)とハードウェアが結びついているためリプレイスが
困難
 ミドルウェアの課題と対策
 開発担当者が手動で本番環境構築していた
 ディレクトリ配置が違ったりして自動化が困難
 構築済み共通サーバテンプレートを使用する
 ミドルウェアのバージョンが上げにくい
 テンプレートを使用することでアプリケーションと環境(OS)を切り離す
 物理環境から仮想環境へ

8. インフラの課題と対策(2)
 補助サービス(DNS/SMTP/POP)の課題と対策
 本業（ECサイトの受託開発）と世界が違うため理解が浅い
 とりあえずサーバは構築できるレベル
 本業の受託開発で使わないのでレベルアップする機会も少ない
 特に日進月歩のセキュリティ面の課題が大きい
 オープンリゾルバ?、SPF?、DKIM?、STARTTLS?
 最早一般的なサービスで対応可能な内容のためSaaSへ移
行

9. インフラの課題と対策(3)
 人的課題と対策
 専任のインフラエンジニアが不在
 分野毎に開発担当者で分担のため、個々人のスキルの差が大きい
 慣れている人に集中する傾向があり属人化しやすい
 長期的に安定した水準を維持するのが難しい
 オンプレミスでの再構築は長期的な維持が難しいため断念
 ECサイト特有のビジネス的課題と対策
 急なアクセス増があっても、ハードウェアの調達と環境構築に時間
がかかり迅速な対応が難しい
 運用コストの高いオンプレミスのインフラを切り離すことで、要件定
義や開発など本業に専念できる体制へ
 IaaSとSaaSを組み合わせた環境へ移行

10. IaaSサービス選定
 条件
 ハイパーバイザーはVMware
 ネットワークについては原則SPOFなし
 サーバのハードウェア障害時にユーザ側の対処不要
 インスタンスのリスタートなど障害時ユーザ側の対応なしでも最低限
Webサイトは動作する
 インスタンス再起動に伴う短時間の停止は許容
 VMイメージのインポート/エクスポートが可能
 構築済みのサーバはP2Vツールを使って移行することが前提
 仮想コンソールが使用可能
 移行に伴ってブートローダやNICの設定変更が想定されるため
 IPエイリアスが使用可能
 ガラケー向けECサイトがあるためIPベースバーチャルホストを多用

11. vCloudDirector
 vCloudDirectorベースのIaaSサービスを選択
 VMWareのパブリッククラウド統合管理ツール
 WebブラウザからVSphereClient相当の機能が利用できる
 細かい仮想ハードウェアや仮想ネットワーク設定が利用可能
 コンソールにもアクセス可能
 VMイメージのインポート/エクスポートにも対応
 開発環境からVMイメージごとデプロイなどハイブリッドクラウド的運用も可
 仮想化基盤はVSphereのため、オーバーコミットやライブマイグ
レーション等の機能が活用できる
 仮想ネットワーク、仮想ハードウェアも細かく設定変更可能
 マルチキャスト、ブロードキャスト、IPエイリアスなどやや特殊な通信
 レガシーなカーネルでも対応している古い仮想デバイス
 既存の基盤の構成を変えずに移行する場合に向いているサービス

12. メール/DNSサービス選定
 メールサービス
 SPAMやウイルス対策の自動化が必須
 マネージドサービスである必要がある
 現行サーバから移行のためアカウント情報のインポート機能
 将来的なサービス規模拡大に備えて柔軟なリソース増強が可能
 HDDやメモリ容量など
 リソース増強とインポート機能からFirstServer ZenLogicを選択
 DNS
 他サービスの依存関係からセキュリティ（特に可用性）重視
 移行を想定するとゾーンデータのインポート機能が必須
 AWS Route53を選択
 SLA 100%

13. 実際の移行の流れ(P2V/V2V)
 客先調整
 停止日、移行日など
 VMイメージの取り出し(P2V/V2V)
 データセンタにてP2V/V2VツールでVMイメージを取り出し
 VMWare VCenterConverter を使用
 VMイメージの運搬には外付けHDDが活躍
 IaaS環境にデプロイして動作確認
 P2Vの場合物理サーバとハードウェアが異なるためinitrdやgrub設
定の変更が必要
 初回起動時に設定変更するためここでコンソールが必要
 基幹連携や決済サービスとの通信確認があるので数日程度
 DBのデータ等動作確認の間更新されたデータの転送
 最後にDNSを切り替えて移行完了

14. 同じ事態を繰り返さないために(1)
 ミドルウェア的課題の対策
 共通VMテンプレートの構築方法も可視化
 秘伝のタレにしない
 VMテンプレートの作成手順はChefでコード化して履歴管理
 サーバ設定の履歴化
 サーバ毎に修正するファイルはChefでは管理せずetckeeperで履歴
管理
 /etcをgitで履歴管理するツール
 どうしてもチューニングやカスタマイズしたアプリケーション固有の設定な
どのためhttpd.confやmy.cnfを修正することがあるため
 リポジトリをGitlabなどに取り込むことで差分や履歴をブラウザから
確認

15. 同じ事態を繰り返さないために(2)
 人的課題への対策
 一定の水準を保ち属人化を防ぐためにIaaS基盤の移行時に
合わせて開発メンバーへの教育を実施
 各自最低一回は移行案件を担当することで、IaaS環境の基本操作
を習得
 仮想化されていることで教育もオンプレミスより容易
 ハードウェアの差異が抽象化されている
 Webブラウザ上でほぼ全ての操作が可能
 間違った操作をしてもハードウェア的に壊す心配がない
 全員がDevかつOpsの体制を目指す

16. 事件(1)
 帯域制御でサーバダウン
 過去にDDOS攻撃やバーゲンセール等で特定のECサイトが回線
帯域を異常に消費して他ECサイトへ影響するがあった
 対策として各ECサイト毎の上限帯域制御を実施
 移行前はFW(Juniper NetScreen)で制御していたが、移行に伴い
Linuxカーネル内蔵の帯域制御(cbq)へ変更
 ランニングテストでは問題なかったのに本番投入後数時間でダウン
 前触れなしにコンソールからも一切操作を受け付けない状況に
 カーネルパニックも表示されずクラッシュダンプも取れない
 カーネルのバグを踏んでいたらしい
 ベンチマークツールで静的ファイルをGETする場合は全く問題なし
 実際のリクエスト状況を模して、レスポンスサイズとレスポンスタイムをラ
ンダマイズすると再現
 実環境に近いテストが重要

17. 事件(2)
 共有ディスク光ケーブル劣化
 リリース後数ヶ月して数台のサーバのHDDの読み書き性能が低下
 夜間バックアップ処理が通常の10倍以上時間がかかるなど
 全VMを調査してみると同一の挙動のサーバが複数ある
 遅いサーバ/早いサーバに全く相関がない
 全く同じテンプレートから作成したサーバでも挙動が違うなど
 調査依頼したら「VMが稼働しているホストごとに傾向が違う」
 VMをホスト間でライブマイグレーションしたら挙動が変わる
 一部のホストと共有ディスクの間の光ケーブルが劣化していて通信
速度が上がるとパケットロスで速度低下
 完全に切れなかったので待機系に切り替わらない
 障害時の切り分け（ユーザ側とサービス側）が難しい
 切り分けるためにはある程度内部構造を理解している必要がある

18. 今後の展望とまとめ
 IaaS/SaaSへ移行することで自社の得意な分野な分野
に集中することができる
 餅は餅屋
 IaaSからPaaSへ
 IaaSはカスタマイズ性は高いがOS以上のレイヤーのメンテナ
ンスコストがかかる
 そこまで必要な案件は比較的少数
 WebサイトがTVで紹介されるなど前触れなしにアクセス増が
ある
 IaaSでは前もってリソースを増強しておくことが困難
 オートスケールさせたい
 カスタマイズの少ない案件からPaaSへ移行を検討