カジュアルに鯖を監視するNewRelic をAmazon Linux に導入
今っぽい感じのSaaS型監視サービス NewRelicを Amazon Linuxに入れてみる。( Newvem とか Server DensityとかPingdomとかもある）
New Relic は、エージェントを監視対象ノードに入れておく点は Zabbix等と変わらないが、監視サーバを構築しないですぐに(無料で)始められる、という点がメリット。
監視対象サーバが少ないシステムだと、監視サーバのコスト・運用負荷がデメリットになるので、CloudWatchを補助する目的で、CloudWatchで取れない Load Average, free memory, Disk UsageといったOS内部の情報をカジュアルに一元管理するのに向いている。
特徴を説明したページはこちら。
で、Amazon Linuxに導入する手順。
そのまえに、 New Relicの無償アカウントを作り、License Keyを取得しておく。AWSでnewrelicを使う場合は、こちらからサインアップ。
AWS & New Relic Server & User Monitoring, Website Optimizer, : New Relic
sudo rpm -Uvh http://yum.newrelic.com/pub/newrelic/el5/x86_64/newrelic-repo-5-3.noarch.rpm sudo yum -y install newrelic-sysmond sudo nrsysmond-config --set license_key=xxxxxxxx sudo /etc/init.d/newrelic-sysmond start
とすれば、監視エージェント nrsysmondが起動し、NewRelicサーバに定期的に監視データを送信し始める。あとは NewRelicのダッシュボードでサーバの情報を見るだけ。
登録されていないサーバからのデータを受信すると、自動でサーバ一覧に表示される。
各サーバをクリックすると、詳細情報が見れる。
アラートの閾値を設定すればメモリやディスクも監視可能。Freeアカウントだと30分しか統計データを保持しないが、通知と割り切れば十分使える。
アプリケーションサーバの場合、各言語毎の監視モジュールを追加で入れることでさらに詳しい情報を監視可能。
PHPの場合は,エージェントがapacheモジュールとして動作し、Proxyデーモン newrelic-daemon を経由してNewRelicサーバにデータが送信される。
sudo yum -y install newrelic-php5
sudo /usr/bin/newrelic-install install
sudo cp /etc/newrelic/newrelic.cfg{,.bak}
sudo sed -e "s/REPLACE_WITH_REAL_KEY/xxxxxxxxxxxx/" /etc/newrelic/newrelic.cfg | sudo tee /etc/newrelic/newrelic.cfg
sudo /etc/init.d/newrelic-daemon restart
sudo /etc/init.d/httpd restart
とすると、以下の様な画面を閲覧できる。PHP/DBの処理時間の割合も見える。
DBアクセスの内訳も見える
呼び出しからバックエンドの各処理でどのくらい時間がかかっているか、も可視化できる。
Neo4j インターナル
代表的なOSS GraphDB であるNeo4jの内部データ構造などの解説資料。
これである程度イメージしてからコードにあたると読みやすいかも。あと、そもそもNeo4jのおさらいしなきゃ（汗）っていう自分向けのこっちの資料もわかりやすい。
EMR: EMRで集計してiOSで可視化する手順
Using AWS Elastic MapReduce Results with Mobile BI Analytics | Architects Zone
EMRの解析結果を、Roambi Analyticsという iOS向け BI 可視化ツールのクラウドサービスに食わせて、そちらで見る手順。
Roambi は、無料のLite（CSV, Excel, html対応)、Pro (Google Docs, SFDC対応)、Enterprise( Oracle, SAP, BusinessObjects, SAS, MS, IBM Cognos対応)の３エディション。
====
MongoDB: foursquareは EC2上で MongoDBが動いている
訳：Netflixが 6.29のAWSと嵐から学んだこと
2012年6月は、立て続けにUS EASTリージョンでダウンタイムが発生している。
NetflixのようにマルチAZの構成にして、常に擬似的に障害を発生させる仕組み( Chaos Monkey)を導入していても、ダウンする場合があることが明らかになった。さらなる可用性向上のためのツール(Chaos Monkey Family)やアーキテクチャ設計ノウハウがNetflixから出てくることを期待。
The Netflix Tech Blog: Lessons Netflix Learned from the AWS Storm
＝＝＝
概要
2012年6月29日(金)、ここ1年で最も大きな停止障害を経験した。太平洋時間午後8:00に始まり、復旧まで約3時間かかり、アメリカのNetflix会員に影響を及ぼした。弾力性のあるインフラに向けた努力にとAmazonクラウドでの経験をよく書いている。過去にも、AWSのAZ停止障害に対して最小限の影響で済むようにしていた(withstand)。なぜ特定ゾーンの停止障害がこのような影響を与えたのか？について分かったことを共有する機会としたい。
背景として、まずはAmazonが出している停止障害の原因分析(http://aws.amazon.com/message/67457/ )を読んでほしい。簡単にまとめると、非常に激しい嵐による停電の影響でAmazonのAZが停止した。電源は20分後に復旧したが、Elastic Load Balancer(ELB)がキャパシティ問題に直面し、APIのバックログが溜まり、復旧が遅れた。
興味深い我々独自の原因分析結果としては、内部の中間層ロードバランサーも含まれていた。不正常なインスタンスがロードバランサーから切り離され、膨大なトラフィックが、不正常なゾーン(unavailable zone)に吸い込まれた(black-holed)。更に、不正常なゾーンにあるインスタンスへのネットワーク通信が、no routeではなくハングした。
この停止障害を通して、我々とAmazonで改善できる多くの点を見つけ、その改善に取り組んでいる。
中間層ロードバランス
中間層のロードバランスで、別種類障害の原因となる機能により連鎖的な障害が起きてしまった。同時にダウンするような特殊な障害時に、非正常なインスタンスを切り離さないようなフェイルセーフ状態を維持していた。ネットワーク分断によって発動し、大規模障害時には誰かが原因調査するまでの間はフリーズしてしまう。不幸なことに、この状態を解析するのがやっかいで時間を浪費してしまうことが分かり、電源障害でサーバが使えなくなってしまった。
Gridlock
クライアントが使えないサーバに接続しようとしていることが、2番めの問題として導出された。全クライアントスレッドが、不完全な接続で実行され、ほんの僅かなスレッドがリクエストを処理していた。内部システムで複数層をトラバースしようとするgridlockを引き起こしていた。このような種類のケースに対して対応できるようにシステムを改善している。これらの接続が、接続できないと即座に判断せずに、タイムアウトするまで接続を維持したか？を解析している。
まとめ
Netflixは数年前に、自前のデータセンターからクラウドに移行することを決めた（http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html）。
クラウドの障害は制御できないので、クラウドの障害を批判することはとても簡単で一般的だが、ここ数年の可用性に対する取り組みから、安定した改善できる事がわかっている。最も大きな停止障害の原因を掘り下げると、サービス障害を軽減するためのアーキテクチャパターンを見つけることがわかっている。
我々の弾力性のあるアーキテクチャが正しく動作したという側面はある。リージョン隔離には、会員がUS-EASTリージョンにアクセスしている、という問題も含んでいる。ヨーロッパの会員には影響がなかった。 分散クラウド永続化ストアとして全ゾーン・全リージョンをまたいで使っているCassandraは、1/3のノード喪失があっても、データや可用性を失わないようにしている。
あるAZを無くすシミュレーションを行うChaos Gorillaというサル軍団(Simian Army)の１つは、まさにこの目的のために作られた。今回の停止障害で、さらなるツールの追加が必要であることと、Chaos Gorillaやその他のSimian Army用のユースケースが必要であることが強調された。
クラウドの状態は成熟を続けるだろうし、時間とともに改善するだろう。Amazonがシステムを改善する方法について、Amazonと密に動き続けている。我々は、リージョン全体の停止障害になるような単一障害点を無くすことと、特定のゾーンの障害を隔離することに注力する。
我々にとって可用性はとても重要(seriously)であり、全会員に途切れないサービスを提供することに努力(strive)している。我々は未だにクラウドに期待(bullish)しており、我々のインフラで提供するサービス障害から会員を守るために努力を続けている。
クラウド運用・信頼性向上チームを作り、今回のような多くの問題に取り組んでいる。各サービスチームもサービスの可用性に対応している。
訳： AWSで高可用性を実現するベストプラクティス
AWS Cloud Best Practice: Introduction to High Availability Deployment | Newvem
AWSのアーキテクチャセンターにも図があるが、解説が少ないので、このシナリオ・ステップは参考になるだろう。
しかし、インフラがRoute53でリージョン間冗長性を考えるグローバルスケールになりつつある中、1台のサーバのRASとか1ラック内のサーバ2台の可用性という小さなインフラしか考えられないガラパゴスな日本人は間違いなく置いて行かれるな。。
＝＝＝
最初にAWSにアプリケーションをデプロイすることは難しい。たくさんの新しい用語と概念を理解する必要がある。AWSに最初のインスタンスを起動する前に、全てのAWSの選択肢を理解する必要がある。
本稿は、AWSのインフラで高可用性( High Availability , HA)を実現するアーキテクチャ設計を簡単に紹介する。まず、単純（かつ障害に弱い）アーキテクチャ設計から始めて、複数リージョンの複合構成までステップを進める。どこまでステップを進むかは、uptimeの要件(SLA)や予算に依存するので、あなた次第である。
（注：以降の図は、AWS上のアーキテクチャを設計・配備する支援ツールであるMadeiraCloudで書かれている）
Amazonクラウドは世界にDCをいくつ所有しているのだろうか？一般的な答えは、上の図に示すように7つのリージョンであるが、正確ではない。顧客、特定の法律、その他の要件によって、近くにあるリージョンを選択するだろうが、リージョンはデータセンターを地理的にグループ化したものである。
アベイラビリティゾーン(AZ)は、リージョンよりはデータセンターに近い考え方である。各AZはリージョン内で独立した場所にあり、単一障害点(SPOF)を共有しないように実装されている。なので、Amazonクラウドは18のデータセンターを持っており、地理的に近いものがグループ化されてリージョンを形成し、同一リージョン内のAZ間は低遅延・安価なネットワークで接続されている、と考えると良いだろう。
興味深い点は、AmazonがAZに与えている名前が、全てのユーザで同一ではないことだ。例えば、もしあなたと私が US Eastリージョンでそれぞれインスタンスを立てたとすると、両方のインスタンスは Virginiaにあることはわかるので、その2台で通信するのは低遅延・低価格になる。しかしもし我々が US-East-1Aにそれぞれインスタンスを立てた場合、2台が必ずしも同じAZにあるとは限らない。あるユーザが、複数のインスタンスを同じAZに立てた場合はそのようなことは発生しないが、異なるユーザのインスタンスでは発生しうる。
高可用性を最大化させるために、どのようにアプリケーションを配備するか？を示す。
下図は、1台のウェブサーバ、1台のアプリケーションサーバ、そして1台のDBサーバで構成される単純なアプリケーションのアーキテクチャ設計図である。オレンジの箱は全てEC2とRDSインスタンスで同じAZ・同じリージョンにある。これがアプリケーションをセットアップする最も単純で安い方法になるが、もしどれか一つのノードがダウンすると、アプリケーション全体がダウンしてしまう！
そこで、アプリケーションの障害許容力( resilience)を改善するために、オートスケーリング(青い箱）を各層に追加し、トラフィックを分配するためにElastic Load Balancer(ELB)をWeb層に追加し、自動的にデータを同期しながらマスタDBに何か起きた場合にはフェイルオーバーするスレーブDBを加えてみよう。
これは良い方法だ。もしどこかの層の１つのノードがダウンしても、自動的に置き換わる。しかし、同一リージョンの同一AZ内にあるので、もしAZがダウンすると、アプリケーションもダウンしてしまう！
AWSアベイラビリティゾーン(AZ)はほとんどダウンしないが、それでもダウンする。あるAZが完全にダウンした場合に備えるためには、アーキテクチャを2つのAZに冗長的に持たせて完全なバックアップを他のAZに保持することだ。
AWS Elastic Load Balancer (ELB)を使うことで、2つのAZにトラフィックを振り分けることができる。マスターDBがある一つのAZに立てていても、複数のAZに立てたスレーブDBと同期をとっているのであれば、何が発生しても問題ない。
これは、1つのAZを使うよりさらに良い。というのも、各AZはSPOFを共有しないようAWSが実装しているので、両方のAZがダウンする確率は非常に低い。しかし両方のAZは同じリージョン・同じ地理的場所にあるので、地震のような悲劇的な出来事によって両方がダウンする可能性が潜在的に存在する。リージョンがダウンするような起こりそうもない出来事の中で、それでもあなたのアプリケーションは必要だろうか？
それでも、もし究極のHAデザインが必要なら、複数リージョンにアーキテクチャを複製し、さらに、各リージョンのELBにトラフィックを振り分けるために、AWSが提供しているDNSサービス Route53を使う必要がある。また、世界中34拠点にある全エッジロケーションからコンテンツを配信するCloudFrontも使える。そう、アーキテクチャの観点からみて、我々は防弾チョッキを手にしている。
まとめ
高可用性の肝は、単一障害点SPOFの数を減らすことであるが、各ステップでアーキテクチャの要件が2倍になり、よって（すべてを常に稼働させれば）コストも2倍になることに気づく。0.09%稼働時間伸ばして99.9%SLAにすることよりも1%稼働時間を伸ばして95%のSLAにすることは、 大幅に安く上がる。SaaSベンダーは、99.9xx%のSLAを実現するための追加リソースに注意を払う必要があるし、価格プランにも組み込むことになるだろう。
すべての課題の中で、クラウドデプロイは本来、最も議論されている。その中で最も重要な見地は、HAの要件に合った堅牢なデプロイによる障害を前提としたアーキテクチャ設計「Design for failure by architecting」である。Sholomo Swidlerの有名な「10個のクラウドデザインパターン」(勝手訳)は、AWSのMiles Wardも是非見るべきだと言っている。HAのエキスパートであるNetflixとSmugMugも 2011年のAWSの障害を避けるための素晴らしいアドバイスをしている。
これは、クラウドによって作られた問題ではないが、新しいソリューションである。Amazonクラウドのリージョンは、複数のアベイラビリティゾーンとリージョンに
またがってアプリケーションを簡単にスケールできる。従来のホスティングでは実現困難だったHAアプリケーションに、新しい機会を与えている。少しの時間を使ってAWSでHAアプリケーションを作る方法を習得することでUptimeと顧客満足度を大幅に増加させることが出来る。
MongoDB: AWSでのTips
MongoDB Casual Talks で発表された、MongoDB onAWSの資料。
元ネタは、MongoDB on AWS White Paper (PDF)
MongoDB on EC2 #mongodbcasual
View more PowerPoint from Yasuhiro Matsuo
議事メモブログエントリ
その他の方の発表資料
MongoDBのアレをアレする by @kuwa_tw
LT CasualにMongoDBのBackup機能説明 by @matsukaz
LT CasualなMongoDBのサービス運用Tips by @nsega
LT Casual MongoDB Sucks by @repeatedly
