Upgrade to Pro — share decks privately, control downloads, hide ads and more …

物理サーバとクラウドの運用管理の違い 2010 03 24 馬場

物理サーバとクラウドの運用管理の違い 2010 03 24 馬場

クラウド勉強会で話した内容です。

(スライドのホストをSlideShareから引っ越し)
https://www.slideshare.net/toshiak_netmark/2010-03-24

Toshiaki Baba

March 24, 2010
Tweet

More Decks by Toshiaki Baba

Other Decks in Technology

Transcript

  1. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. 株式会社ハートビーツ MSP(Management

    Service Provider) • OSSを活用したインターネットサービスが得意 • ビジネスが成功すること • システムがサービスを提供し続けられること • 24時間有人監視+一次対応、サーバ管理 • 障害対応エクスプレス • インフラ診断コンサルティング • アーキテクチャ検討 • インフラ見直し、仮想化・クラウド活用 • インフラ無料相談 • フルマネージドロードバランサ
  2. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. 自己紹介 •

    馬場 俊彰(ばば としあき) @toshiak_netmark • 株式会社ハートビーツ 技術統括責任者 • 現職: インフラエンジニア 前職: Webシステム開発(Java) 前々職:インフラエンジニア • 得意分野 • Webシステムのアーキテクチャ全般 • 主にWebシステムのインフラ全般の構築・設定・チューニングなど (ハードウェア、ネットワーク、OS、ミドルウェア) • インターネットサービスに関わる技術要素全般
  3. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. クラウド コロケーション

    ネットワーク ハードウェア OS ミドルウェア アプリケーション 実行環境 アプリケーション IaaS PaaS SaaS ベンダー ベンダー ベンダー ユーザ ユーザ エンドユーザ
  4. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. 前提 基盤:

     Amazon EC2 載せるシステム:  webスケールほどでもない  規模(数台~十数台)のシステム。  冗長化・負荷分散構成
  5. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. 柔軟さ •

    起動が簡単・停止が簡単 • マシンイメージを使える • 課金時間単位が細かい
  6. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ1 web(AP)サーバのうちの1台で原因不明の遅延が継続

    <物理サーバの対応> • 原因箇所の特定・対応 • デーモンやサーバの再起動 • ハードウェアトラブルの場合、交換など…
  7. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ1 web(AP)サーバのうちの1台で原因不明の遅延が継続

    <物理サーバの対応> • 原因箇所の特定・対応 • デーモンやサーバの再起動 • ハードウェアトラブルの場合、交換など… <クラウドの対応> • 原因箇所の特定・対応 • デーモンやサーバの再起動 • 時間がかかりそうなら… – 別インスタンスを起動・投入 – 不調インスタンスを破棄
  8. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ1 web(AP)サーバのうちの1台で原因不明の遅延が継続

    <物理サーバの対応> • 原因箇所の特定・対応 • デーモンやサーバの再起動 • ハードウェアトラブルの場合、交換など… <クラウドの対応> • 原因箇所の特定・対応 • デーモンやサーバの再起動 • 時間がかかりそうなら… – 別インスタンスを起動・投入 – 不調インスタンスを破棄 暫定状態なしで 本番稼働環境が復活
  9. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ2 Master

    DBサーバがダウン <物理サーバの対応> • 起動をトライ • 起動しなければ、更新遅延がないSlaveを特定 • SlaveをMasterに昇格 • 接続先設定変更
  10. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ2 Master

    DBサーバがダウン <物理サーバの対応> • 起動をトライ • 起動しなければ、更新遅延がないSlaveを特定 • SlaveをMasterに昇格 • 接続先設定変更 <クラウドの対応> • 別のインスタンスにMasterDB用EBSをアタッチ • 新Masterを稼働 • 接続先設定変更
  11. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. ケーススタディ2 Master

    DBサーバがダウン <物理サーバの対応> • 起動をトライ • 起動しなければ、更新遅延がないSlaveを特定 • SlaveをMasterに昇格 • 接続先設定変更 <クラウドの対応> • 別のインスタンスにMasterDB用EBSをアタッチ • 新Masterを稼働 • 接続先設定変更 迷う時間が少ない
  12. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. まるごと捨てる! •

    見切りをつける • 必要なのはマシンではなくてマシンリソース • インスタンスを捨てることを常に視野にいれる
  13. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. 実現するための工夫 •

    AMIパターンを増やさない • 起動パラメーターで場合分け • 自動化する • ◦◦を見て判断して、△△して▪▪するだけ →たいていは「だけ」が大変。そこを自動化! 例:アプリからの参照先DB切り替え、スレーブの追加をアプリに通知 • 起動を高速化 • 自動化・EBSからの起動 • AMIの鮮度維持(起動後のupdateを少なく) • リポジトリからのアプリケーションデプロイを高速化 • EC2にリポジトリを配置 • S3にアプリケーションを配置
  14. Copyright (C) 2005-2009 HEARTBEATS Corporation. All Rights Reserved. アーキテクチャ 柔軟さを活かすためのアーキテクチャ

    • データをロストしないしくみをつくる • インスタンスは揮発型。S3・EBSは永続型。 • キューイング・キャッシングを活用した非同期処理中心の構成。 • ボトルネックを回避できるしくみを作る • 負荷を分散 • データを分散