aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。１年以上古いエントリは疑ってかかってください)

トップ > Ops

EC2: User Dataを使ってインスタンス起動時の処理を自動化する

AWS EC2 Ops

インスタンス起動時に目にするUser Dataって何？って感じなので取り敢えず。

 

f:id:understeer:20120719123009p:plain

#!/bin/bash -ex
yum -y install httpd php php-pear php-xml
yum -y install git
/etc/init.d/httpd start
pear channel-discover pear.amazonwebservices.com
pear install aws/sdk

といったように、「#!」(Hash-bang)から始まる文字列を User-data記述すると、Amazon LinuxのCloud-initによって、起動時に実行される。スクリプトを記述したファイルを指定することも可能。 

実行された様子は、起動したインスタンスの /var/log/cloud-init.log に記述される。

 User-dataは、16KB上限であれば、どんな文字列(JSON, プロパティ形式)でも大丈夫。

各インスタンスからは、 http://169.254.169.254/latest/user-data/ で取得することが可能。

インスタンスメタデータ  http://169.254.169.254/latest/meta-data/  と組み合わせると、より高度なスクリプティングが可能になる。

 

CloudInit - Community Ubuntu Documentation

Using Amazon's CloudFormation, cloud-init, chef and fog to automate infrastructure | Allan Feid

Automating Application Installation Using AWS CloudFormation and Cloud-Init - AWS CloudFormation

このあたりも

複数のデータセンターにMongoDBを配備する戦略

MongoDB Ops 訳 AWS NoSQL

MongoDB: Strategies for Multiple Data Center Deployment | Architects Zone

MongoDB NY 2012の資料から。

 

これ、普通にオンプレミスやってたら縁遠いけど、AWSだと複数のリージョンをまたがせてすぐに試せるので、グローバルなアプリケーション作る時の参考になるかも。

Multi Data Center Strategies

 

===

例として、3拠点（US,ヨーロッパ,オーストラリア）のユーザにサービス提供するソーシャルネットワークのシステムを考える。

チャレンジングなことは、データの一貫性、ユーザ体験の維持、スケールである。

USにDBがあると遅いのでユーザ体験が悪くなる。

USにR/WのDB,　それ以外にROのDBを置くと参照は速くなるが、ユーザのデータは局所的であるはずなので、データローカリティを意識し、グローバルな障害に耐えるようにし、リモートのデータも早く操作できるようにしたい。

MongoDBだと、Replica Setsを各拠点に設置することでクリアできる。

でも、アプリは参照先を意識する必要がある。将来的には　GeoAware Shardingができるようになる。シャードキーに、GeoAwareなキーを加えるらしい。

 

DevOps : 日本語で語る DevOps

Ops Develop 訳

Japanese Words for DevOps Practitioners | IT Revolution

もともと DevOpsは、リーン開発やアジャイル開発とも近いので、TPS (トヨタ方式)の哲学が入っていても不思議ではないですが、やっぱり大野耐一さんはすごい。そして、製造業におけるシステム運用ともいえる生産ラインの方法論こそ、Opsに一番必要な気がする。Devは、生産ラインそのものを建造することに近いし、継続的なDevは、生産ラインをどんどん変更・拡大・追加をしていくことに近いと思う。

====

Gemba

「実際の場所」を意味する。ビジネスでは「価値が生まれている場所」を意味し、リーン製造業では「工場」もしくは「店舗」を意味する。リーンシックスシグマ(LSS)では「現場へ行け(Going to Gemba)」というフレーズは一般的である。また、よくプロセスマッピングにも使われる。

この単語がDevOpsにおいて重要な理由は、DevOpsがLSSと制約理論(Theory of Constraints, TOC)から多くの考えを継承しちえるからであり、LSSとTOSの両方が、広域最適化( big picture)に強くフォーカスしているからである。全体を改善すること、個別にフォーカスしないこと、はLSSとTOC両方の中核をなす考えである。ボトルネックとフローを理解することは、バリューストリームを理解する上で重要な要素である。

DevOpsでは「Aha to the Ka-Ching」もしくは「left to right flow」について話をしている。「Going to Gemba」はフローを実際に見るためにとても重要であり、決して口上ではない。a)ムダを削除すること、b)例外・ばらつき(Mura)を最小化すること、の２つによってどのように改善されうるかを決定するためにGembaを歩くことが必要である。

Kanban

「サインボード」や「居酒屋のラストオーダーを知らせる板」を意味する。後のリーン製造業となるトヨタ生産方式( Toyota Production System, TPS)の父である大野耐一は、「last call」の種類としてKanbanを「Just in TIme, JIT」を実現する意味で使っていた。Kanbanカードは、新しく部品を補充・発注する際に在庫とフローを制御する手段の信号として使われた。2007年にDavid J AndersonはKanbanメソッドを、TPS製造モデルではなく、ソフトウェアデリバリパターンとして定義した。今日では、Kanbanはアジャイルチームにおいて有効なツールとして使われている。Kanbanに含まれている重要な考えの一つとして、a)Kanbanはプル型の仕組みで b)ワークフローの見える化によってスループットを改善し、 c) 特殊な作業の 「仕掛品 Work-in-process, WIP」を増やさないようにする。

KanbanがDevOpsで人気な理由は、割り込みが多い運用やサービス指向のグループで有用だからである。ScrumとXPが開発組織で有用であるように、DevOpsが哲学でDevとOpsが密に作業している組織の多くで、Kanbanの利用事例を見つけるだろう。

Kaizen 

WikipediaではKaizenは「improvement 」もしくは「change for the better」と表現されている。製造業、エンジニアリング, ゲーム開発、ビジネスマネジメントにおける継続的なプロセス改善の哲学・プラクティスとして言及されている。

カイゼンは日々のプロセスであり、常に前日より良くなっている。また、カイゼンはシンプルな生産性向上の考えに起因している。職場を人間的にしハードワーク(muri)を減らすし、科学的手法の適用と、ムダを検出し撤廃する方法を教えてくれる。

カイゼンはリーンと同じようにDevOpsでは大きな役割である。DevOpsでは常にフローの改善の考え方がある。フローのばらつき（バグ、性能問題）を見つけ、早期にフローのエンジニアリングを行う。また、改善は、ボトルネックを緩和(alleviating)し継続的に全体最適を行う。

Kata

文字通りの意味としては「フォーム、手順」である。この単語はマテリアルアートで一般的だが、それ以外では、文化的な条件を意味する。日本のビジネスにおいてカタは正しく実行する方法の概念である。弓の弾き方、名刺交換、謝罪の重要性、品質への執着等は全て、日本の文化に深く起因している。

ある組織の文化は、一貫した役割設計、ティーチング、コーチングを通して、カタとして特徴づけられる。 Mike Rotherは「Toyota Kata」という本でカタとリーンの観念を普及させた。Toyota Kataは改善のカタと、コーチングのカタという2つの領域に分けられる。改善のカタは継続的な改善・適用・革新の熟達を教えている。コーチングのカタは、継続的な観測とガイドの側面を強調している。この理論は、難しい何かや慣れてない何かをしようとした時に、コーチ無しでも怠けないようになる。ある組織が改善に最適化されている場合、それは彼らのカタであると言える。

Muda

Mudaは不要物である。トヨタ生産方式(TPS, Leanとも呼ばれている)の父であるトヨタの大野耐一によると、価値を産まない活動はすべて無駄である。大野耐一は有名な7つのムダを指摘した（作りすぎ、手待ち、運搬、加工、在庫、動作、不良を作ること）。この概念は、すべての活動を2つに分類する。つまり、価値を生む活動と、価値を産まない活動である。

DevOpsでムダを減らすことは、重要な原則である。Ka-chingについて語るときは、顧客へデリバリするサイクルタイムを邪魔するムダな壁をいつも探している。

Mura

Muraは一貫性がない、もしくは過剰な変動を意味する。作業が標準化されていない場合、無駄な動きによって無駄が生じる（例えば、明確な工程や手続きが無い場合）。Muraは品質の問題を引き起こしかねない。

Kanbanのコア原則の一つが、工程の方針を明示的に作ることである。Kanban はMuraを削減する素晴らしいツールである。Chef, Puppet, CFEngineといった構成管理ツールは、インストール・設定の標準化プロセスを作ることでMuraを制御する、という議論がある。Leanは　無駄(muda)を除去し 、 Six Sigmaは変動(Mura)を削減する。DevOpsでは、3M (Muda,Mura,Muri)を削減するよう努める。

Muri

Muriは TPSにおけるMura, Muraに続く3つ目の廃棄すべきものである。日本語では、過負荷、理不尽、不条理を意味する。Muriは、工程・人間・機械が許容範囲内で活動することを表している。

Pola-yoke

フェールセイフ、もしくは人的ミスの対策。 Poka-yokeは、製造現場にて、欠陥を防止することとヒューマンエラーへの注意を促進する。この単語はTPSの一部として新郷重夫が追加した。

現実世界でのPola-yokeの素晴らしい例として、氷入れが満タンの時には冷蔵庫内の製氷機は製氷しないので、冷蔵庫が氷であふれることはない、といったもの。 Poka-yokeは明らかに DevOpsと関係が深い。DevOpsの作業の多くが人間の活動をベースとしていることは、殆どの人が同意するだろう。ソフトウェア開発と運用は人間の努力とであり、インフラをPola-yoke化すること(Poka-yoke'ing) は、DevOpsのゴールのひとつである。テスト駆動開発(Test Driven Development, TDD)は、ソフトウェア版Poka-yokeの一例である。セルフサービスの運用やPaaSも別の Poka-yokeの形態ともいえる。監視は、素晴らしいPoka-yokeの例である、というのも、エラーが発生する前にエラーを見ているのだから。

 

訳：Netflixが 6.29のAWSと嵐から学んだこと

AWS ELB EC2 訳 Architecture Ops

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で高可用性を実現するベストプラクティス

訳 Architecture Ops AWS AutoScale EC2 RDS

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 Cloud World Data Centers

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・同じリージョンにある。これがアプリケーションをセットアップする最も単純で安い方法になるが、もしどれか一つのノードがダウンすると、アプリケーション全体がダウンしてしまう！

Cloud Application deployment schema

そこで、アプリケーションの障害許容力( resilience)を改善するために、オートスケーリング(青い箱）を各層に追加し、トラフィックを分配するためにElastic Load Balancer(ELB)をWeb層に追加し、自動的にデータを同期しながらマスタDBに何か起きた場合にはフェイルオーバーするスレーブDBを加えてみよう。

Cloud application using auto-scale

これは良い方法だ。もしどこかの層の１つのノードがダウンしても、自動的に置き換わる。しかし、同一リージョンの同一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

AWS NoSQL EC2 MongoDB Ops Architecture

MongoDB Casual Talks で発表された、MongoDB onAWSの資料。

元ネタは、MongoDB on AWS White Paper (PDF)

MongoDB on EC2 #mongodbcasual
議事メモブログエントリ
その他の方の発表資料
LT Casual MongoDB Sucks by  @repeatedly

DevOps: Netflixが、Webベースのクラウド管理・デプロイツール AsgardをOSS化

AWS AutoScale 訳 Architecture Ops Develop

NetflixがWebベースの管理・デプロイツール Asgard をOSS化した。

The Netflix Tech Blog: Asgard: Web-based Cloud Management and Deployment

AWS Management Consoleよりも、直感的かもしれないし、AutoScaleもGUIで設定できたり、自動化をGUIから設定できたりする。

 

これがOSSなのはすごい。

とりあえず、Amazon Linuxにて

$ wget https://github.com/downloads/Netflix/asgard/asgard.war
$ wget http://www.fightrice.com/mirrors/apache/tomcat/tomcat-7/v7.0.28/bin/apache-tomcat-7.0.28.tar.gz
$ tar xvf apache-tomcat-7.0.28.tar.gz
$ vi apache-tomcat-7.0.28/conf/server.xml 
$ sudo apache-tomcat-7.0.28/bin/startup.sh
$ cp asgard.war apache-tomcat-7.0.28/webapps

そのあと、 http://example.com/asgard/ にアクセスすると、アクセスキー・シークレットキー・アカウント番号を入力する画面が出て、その後初期化が数分走る。

 

インストールツールもGitHubに転がってた。

kaldrenon/install-asgard · GitHub

＝＝＝