AWSを活用して少人数で
複数のサービスを運用するコツ


    株式会社 ソニックガーデン
        安達 輝雄
自己紹介
@interu 安達輝雄

 アプリケーションの開発
      +
  インフラの構築/運用

http://interu.hatenablog.com


開発しているサービス
SonicGarden

    エンジニア:5名
開発/運用サービス一覧
            自社サービス




        パートナーシップモデル




  ・データ販売サイト        ・植物栽培キッド販売サイト
  ・ドキュメント配信        ・SEO関連サービス
  ・Flash動画生成サービス            ・・・etc
いくつものサービスを

たった5人のエンジニアで
   どうやって

開発 / 運用 してる?
Answer.
   DevOps
    and
 AWS/Heroku
    and
自動化/共通化/効率化
利用比率

  :
5 : 5
今日は
 JAWS-UG。
Herokuの話は
 すべて割愛!
そろそろ本題に


  SonicGardenは
 サービス運用について
どのように考えているか?
SonicGardenのMission




   開発 >    運用
SonicGarden流
サービス運用ポリシー



 構築/運用コストは抑えつつ
 安定したサービスを提供する
運用コストを
どのように抑える?
構築/運用コストを抑える



      航空業界の
      LCC的発想
構築/運用コストを抑える

 LCC
  ●   機体を1つのシリーズに統一
      ●   研修/教育コストを抑えれる
      ●   パイロットなら誰でも運転できる
          ※ 機体毎に免許取得が義務付けられている

  ●   システムの自動化
      ●   チェックイン等を全てシステム化
      ●   通常フローで人を介すサービスをしない
構築/運用コストを抑える

 SonicGarden
 ●   OS/ディストロを統一
     - ミドルウェア導入/設定
     - セキュリティ設定
     など基本設定を行ったテンプレートAMIを
     作成し、アプリのみを入れ替えてサービス


        構築/運用コストの削減
安定したサービスの提供

 SonicGarden
●   システムの自動化
    - EBSスナップショットの取得
    - 実データをS3にバックアップ
    - AMIの定期作成 ...etc


    安定した品質を全サービスで提供
LCC的発想以外にも...
新しいディストロの採用

2年で全乗り換え
●   新しいパッケージを利用可能
    ●   アプリケーションF/Wに追従しやすい
●   パッケージがメンテされている
    ●   Security Fix / Bug Fixをすぐに適用できる

              運用コストを削減
ディストロの
置き換えは大変では?
Railsのバージョンアップに伴い
APサーバを新しいディストロに
切り替え

 Ruby 1.8.7 ⇛ 1.9.3
リプレースまでの過程

(0)新環境構築   EC2の活用

(1)新環境単体でテスト
                    EBSの活用
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
リプレースまでの過程

(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
リプレースまでの過程

(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
           ELB/Route53/Elastic IPの活用
その他、
 効率化を目的に
いくつか取り組んで
 いることを紹介
① バックアップ
① バックアップ


  データ/ログのバックアップを
   取得するのは当たりまえ

  バックアップ処理中のエラー
     検出も当たりまえ
① バックアップ



    本当にバックアップを
     取得できてる??
① バックアップ
    バックアップしたものが
  存在するかを確認する方が確実


      だけど・・・
  複数サービスを運用していると
   全てを確認するのは一苦労
① バックアップ


 AWS Backup Checker
指定した期間内のバックアップが存在するかを
AWSのAPIを利用してチェック
 - EBS snapshot
 - S3
 - AMI
アプリケーションログ、システムログ、アプリケーションデータ




            データディスクのスナップショット
Coming Soon.
② AWS障害対策
AWSは障害が少なくて
  非常に助かってます!


      が、

障害を0にはできないのが現実
過去に遭遇した大規模障害

●   2011年4月
    us-eastでEBS障害
    http://interu.hatenablog.com/entry/20110425/1303731515

●   2012年6月
    us-eastで電源障害・API障害
障害からの学び

EBS障害が発生すると
 ●   EBS bootのAMIは起動不可
 ●   EBS上のデータへのアクセス不可
障害からの学び

●   Instance storeタイプのAMIを
    別Regionに作成しておく
●   データも別RegionのS3にバックアップ


 ⇛ DR対策できあがり
で、何を効率化したの?
●   定期EBS snapshot取得スクリプト
●   EBS boot型AMI作成スクリプト
●   Instance store型AMIを別Regionに
    作成するスクリプト              ※要AKIの準備



    https://github.com/interu/management_utilities
Fin.

「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜