スライド 1

Size: px

Start display at page:

Download "スライド 1"

りさこひがき
5 years ago
Views:

1 クラウドのサービスレベルを上げる運用管理フォースクーナ株式会社代表取締役三角正樹

2 会社紹介フォースクーナ株式会社 2003 年設立 9 年目システム運用サービスを中心にインテグレーションサービスを提供している

3 概要 1. パブリッククラウドのメリットとサービスレベル 2. パブリッククラウドの障害事例 3. パブリッククラウドを利用していたサービス事業者はどうしたか 4. 障害に対して何が必要か

4 パブリッククラウドのメリットすぐに使えてすぐに止められる資産ではなく損金スケーラビリティを持てる再構築の容易さ運用を任せられる

5 パブリッククラウドのサービスレベル nifty cloud 月間のサーバー稼働率 99.95% AWS EC2 年間使用可能時間割合 99.95%

6 障害可能時間 nifty cloud 月間 21 分以内 EC2 年間 4.32 時間以内良くある障害インスタンスが固まってしまうネットワーク遅延

7 現在パブリッククラウドを使用されている方? この中でパブリッククラウド側の障害にあった事があるという方はどのくらいいらっしゃいますか?

8 残念な事にパブリッククラウド側のオペミスでインスタンスが飛んでしまう事や長時間のネットワーク障害が発生したり SLA 以上の障害が起きる可能性もあります障害事例の研究が必要

9 2011 年 4 月 21 日に起きた AWS での障害米国時間 4 月 21 日に Amazon Web Services でネットワークの構成変更作業におけるミスを発端としてブロックストレージサービス Amazon Elastic Block Store(EBS) およびリレーショナルデータベースサービスの Amazon Relational Database Service(RDS) が約 4 日間にわたる障害が発生米国東リージョンにおける Amazon EC2 と Amazon RDS のサービス障害の概要

10 セカンダリネットワークシステム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へ AWS 構成 ( イメージ ) EC2 EBS コントロールプレーン EBS クラスタプライマリネットワーク EBS EBS EBS EBS EBS EBS EBS EBS

11 Heroku とは AWS の上に Ruby, Rails, PostgreSQL memcached などオープンな技術を用いて作られた PaaS を提供している会社 2011 年 1 月にセールスフォースに買収され現在は node.js など他の言語対応も進めている

12 2011 年 4 月 21 日に起きた AWS での障害 ~Heroku の例 ~ Heroku を 4 年間運用してきて最大の障害専用データベースを利用している大規模アプリケーションでは最大 16 時間のダウンタイム共有データベースを利用している小規模アプリケーションでは最大 60 時間のダウンタイムアプリケーションのデプロイについてはプラットフォームの広範囲にわたり約 76 時間 (3 日間以上 ) の間不可能となった Heroku のステータスページ

13 障害の発生 4 月 21 日午前 0 時 47 分 (PDT) AWS での障害発生午前 1 時 15 分 (PDT) 監視システムからの警告が届くステータスページに問題発生の一報を掲載 Issue: We are investigating high error rates. We'll post an update when we know more. ポイント AWS での障害発生から検知まで 28 分ちょっと遅く感じるがステータスページへの反映が同時行われているので検知はもっと早かったのではないか第一報の掲載が本当に早い ( 障害発生から 30 分以内 )

14 原因の調査と再構築 4 月 21 日午前 1 時 52 分 (PDT) 広範囲に渡るネットワークエラーによって Web やキャッシュルーティングサービスがタイムアウトしていることを確認 Update: The elevated error rates are due to connectivity issues. We're continuing to work with our network service provider to fully restore connectivity. Applications and tools are working intermittently at this time. 最初の数時間は挙動のおかしいインスタンスをシャットダウンして新しいインスタンスに置き換える作業を試みた Heroku のプラットフォームは通常であればこの方法で復旧しユーザーにとってはごく小さい障害で済む

15 原因の調査と再構築しかし今回は事態が悪くなっていっていることがわかった最大の問題は使用してる EBS ドライブだったポイントパブリッククラウドは問題が発生した場合通常は問題を修復するよりインスタンスを入れ替えるなど再構築した方が良い EBS が問題と特定できた

16 障害対応 EBS ドライブがどんどん予測できない挙動を示しはじめた一部のドライブは新しいインスタンスに接続し直しても完全に反応しなくなってしまった対処方法を聞くため AWS のテクニカルアカウントマネージャーと 1 日中連絡をとっていたが残念ながらそれらも役には立たず障害はどんどん拡大していったこれまでの前例から見てこのような場合に取るべき最善の方法はサービスを動かしつづけるようベストを尽くしつつ AWS が問題を解決するのを待つことだポイント問題は見えてきたものの出来ることは待つだけだった

17 障害対応 16 時間以内に大部分のアプリケーションが復旧したがいくつかのサーバーには問題が発生していたそれからの 48 時間はエンジニアが AWS と共に可能な限り早くサービスを復旧させることに費やされた EBS ディスクが応答を返し始めるとともにサーバーが徐々に稼働し始めるのをゆっくりではあるが確認できたポイント重要顧客のシステムはバックアップから別リージョンにリストアし AWS の障害復旧よりも早く復旧した模様プロバイダー側の問題が解決してからが勝負!

18 パブリッククラウドの障害に対して落ちないシステムはない障害は確実に起こる事を前提とし障害が発生したときにどれだけ早く復旧させるか

19 起こってしまうと出来る事が尐ないので事前に手を打っておくことが肝心システム的な対処を施しておく SPOF( 単一障害点 ) を無くす HA,DR 等の準備 Design for Failure( アプリケーションで可用性を担保する ) 体制や人的な対処を施しておく障害対応時間の短縮情報共有改善

20 障害検知システム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へ検知が重要如何に正しく早く検知するかここをミスすると復旧が遅れるし先にユーザーから指摘されるという事もユーザー視点で障害が発生していないか検知できるようにしておく http のステータスコードだけ見ていてページが真っ白になっていても気が付かないなんてこともある検知しようとしすぎて False alert( 障害ではないトリガによるアラート ) が沢山あがると本当の障害が埋もれるので閾値の調整や関連性を踏まえてアラートを上げるシステムが必要

21 障害対応システム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へパブリッククラウドの障害対応の基本は修復ではなく再構築 ( インスタンスの stop start スナップショットからの立ち上げなど ) 勘所がわかるエンジニアが必要クラウドインフラをわかっているエンジニア ( プライベートクラウドよりは楽なはず ) 自社内にいない場合はそのようなエンジニアがいる会社と組む

22 情報共有システム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へ原因追究をしていると作業者にとってはあっという間に時間が立つが待っている側は非常に長い時間に感じられる為作業者の状況を小まめに吸い上げる仕組みが必要ユーザーとも作業進捗を共有する必要がある稼働率 100% のシステムは世の中に無いのであいまいにせずに誠実な報告をする必要があるここの対応次第でユーザーとの信頼関係に差がつく

23 Heroku の体制 AWS テクニカルアカウントマネージャ緊急時 24 時間対応 (8 時間シフト ) Incident Commander ユーザーサポートエスカレーション on-call engineer エンジニアチームアラート監視システム

24 Heroku の考察障害検知監視システムは障害を素早く検知した緊急障害の体制 on-call engineer は素早く問題の大きさを判断し Incident Commander を起こすことが出来た Incident Commander は AWS にすぐに連絡をし内部の他のエンジニアを起こし緊急体制を確立できた

25 Heroku の考察障害対応金額規模が大きい顧客から対応をはじめそれらの顧客のシステムは障害を短く収める事が出来た情報共有何人かから障害対応状況の情報が足りないという指摘を受けたがバックアップからデータをリストアしたりシステムのリプレースを行っていたので 1 時間くらいの間隔では大きな進捗が無い場合もある障害対応状況の更新により我々が全力を尽くしているという事は伝わった

26 Heroku の考察改善点 IaaS のレイヤーの障害だったとはいえ顧客に対してこれらの心配を取り除くすべての責任は Heroku にある為下記の 3 点を検討しているマルチリージョン対応 EBS の影響を受けにくくするリアルタイムバックアップの導入

27 リージョン :US-East リージョン :US-West アベイラビリティゾーン A アベイラビリティゾーン A アベイラビリティゾーン B アベイラビリティゾーン B リージョン :Tokyo リージョン :Singapore アベイラビリティゾーン A アベイラビリティゾーン A アベイラビリティゾーン B アベイラビリティゾーン B

28 Heroku の考察システム的な対処を施しておく改善点あり SPOF( 単一障害点 ) を無くす HA,DR 等の準備 Design for Failure( アプリケーションで可用性を担保する ) 体制や人的な対処を施しておく障害対応時間の短縮情報共有改善問題なし

29 まとめシステム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へ落ちないシステムはない障害が発生したときにどれだけ早く復旧させるかが肝心パブリッククラウド側で障害は打つ手が尐ない事前にシステム的な備えと人的体制的な備えが必要

30 まとめシステム系ソフトウェアクラウドを中心としたプロフェッショナルサポート集団へ障害対応時間短縮の為に早く検知できるようにする勘所のわかるエンジニアを普段から意識して育てておく障害時のユーザー報告は素早く細かく行うクラウドのサービスレベル以上のサービスを提供できるように頑張っていきましょう!

アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2

アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2 をクラウドで利用しようオープンソースミドルウェア最新技術セミナー 2014/03/25 14:10-14:40 SRA OSS, Inc. 日本支社技術開発部正野裕大 1 アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2 をクラウドで利用しよう