障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
マネージドサービスについて
マネージドサービスについて AWSなどが提供するマネージドサービスを使うかどうかは利用者側の状況にひとえに依存すると思う。 まず気にするべきポイントは、マネージドサービスを使うことで得られるメリットを明確にすることだ。一般に、マネージドサービスはインフラストラクチャからよりアプリケーションに近いレイヤ、多くの場合特定のミドルウェアまで、を抱合して提供してくれるため、運用面での負担が減る。できるだけ利用する方がよいと思う。一方で、運用のやり方やスタイルは提供者側の目線にあわせないといけない。ここにギャップが生まれやすい。理由としては、提供者側の気にする点が全体最適化のうえでベストエフォートで提供できるラインはどこか・そのうえで提示できるSLAがどこにあるか、なのに対して、利用者側の気にする点はミクロな視点で特定リソースが安全に継続可能性が十分にある状態で妥当なコストで利用できるか、の違いがあ
GCEのライブマイグレーションのすごさをまとめてみた #gcpja - Qiita
Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事＋個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です！ Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance（自動メンテナンス）という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや
AWSのデータセンターの中身を、設計総責任者が話した
AWSのデータセンターの中身を、設計総責任者が話した：「ここまで話していいの？」（1/2 ページ） Amazon Web Services（AWS）のバイスプレジデント兼ディスティングイッシュド・エンジニア、ジェームズ・ハミルトン氏は、AWSが11月11～14日に開催した「AWS re:Invent 2014」で、データセンターの構成、サーバーやスイッチの自社設計、SR-IOVなどについて語った。 [2014/11/21訂正]記事の初出時に、ハミルトン氏がAZ間の距離を「数キロメートル」と言ったと記述しましたが、数十キロメートルである可能性もあります。ハミルトン氏はAZ間が「multiple kilometers」であると表現しています。後出のハミルトン氏の議論では、例えばロサンゼルスとニューヨークの間の伝送遅延は74ミリ秒だが、これを1、2ミリ秒に抑えるためにAZ間は近くなくてはならない
AWSガチャは下手なチューニングよりも効果が出る？
Amazon EC2は立ち上げるインスタンスによって微妙なパフォーマンス差が出ると言われていて、複数回、インスタンスを立ち上げたり、捨てたりして、良いインスタンスを得ることを”Amazon EC2インスタンスガチャと”呼ばれています。 そのパフォーマンス差は、どれくらいなのか？気になったので測ってみました。 検証環境はこんな感じです。 AMI ID: CentOS 7 x86_64 (2014_09_29) EBS HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 (ami-89634988) Instance Type: c3.xlarge １）Magnetic(standard) ２）Magnetic(standard) + EBS-Optimized ３）General Purpose (SSD) + EBS-Optimi
「IaaSとPaaSの微妙な関係」 by 田中 慎司氏 #jawsdays – JAWS DAYS 2014 参加レポート Vol.07 | DevelopersIO
JAWS DAYS 2014 参加レポート、7本目です。株式会社はてなCTOである田中慎司氏の「IaaSとPaaSの微妙な関係」のレポートです！ 「IaaSとPaaSの微妙な関係」 by 田中 慎司氏 トラック入り口の張り紙に「タイトル未定」と書かれてしまったことがちょっと悔しそうな田中さんでした。 ※本発表のスライドが後日公表されれば差し込みます。 はてなについて まずははてなの現状について。はてなではデータセンタとAWSのハイブリッド構成になっているが、HatenaBlogはほぼ100%AWSで構成されているそうです。全サービスでトータルすると2000台規模であり、AWSがうち100台程度とのこと。はてなのサービスは古くから提供されていることもあり、既存のデータセンタに数多くの資産があるそうです。 IasSとPaaSの話 「IaaSとPaaSって、どうやって使い分けていますか？」という
#jawsdays の #最強のAWS で「ぜんぶ AWS でやらないワケ」という話をしてきた · takus's blog
@hirose31 さん経由で @con_mame さんからお話をいただき、 JAWSDAYS 2014 の「これで最強AWSに」というセッションで話をしてきました。 内容としては、オンプレも AWS も運用してる立場から両者を比較してみてどうなのといった感じのお話です。 2014/03/15 JAWS DAYS 2014 - 『これで最強のAWSに』セッション #jawsdays #最強のAWS にツイートまとめがあるので、資料と一緒にご覧いただければと思います。 こんな話も出ていましたが、 AWS は必ずしも銀の弾丸ってわけではなく、どこの会社も悩ましい部分を抱えながら運用しているわけで、 @sgwr_dts さんの Roadworker のようにユーザ側でイケてる仕組みにするようなアプローチもありますが、このような機会を利用して AWS の中の人に直接フィードバックできたという意味で
クラウド時代のIT新潮流 | 第6回 モノとモノが語り合う 〜クラウドはビッグデータ時代の情報基盤になる
第6回 モノとモノが語り合う〜クラウドはビッグデータ時代の情報基盤になる 今から7年前、「ビッグデータ」という概念が一大トレンドになるのを予見するかのように、日本のコンピューターサイエンス界では「情報爆発プロジェクト」と呼ぶプロジェクトが始まっていた。これは情報爆発時代に向けた新しいIT基盤技術を研究するもの。まさにビッグデータ時代を先取りするプロジェクトだった。今後の情報爆発の時代にクラウドがどう貢献できるのか、ビッグデータの成果をビジネスに生かすにはどうしたらよいのか――情報爆発プロジェクトの提唱者である東京大学の喜連川優教授に、日経コンピュータ編集プロデューサーの星野友彦が尋ねた。 “第4のメディア”が「情報爆発」をもたらす 星野 喜連川先生は、「ビッグデータ」が話題になるかなり前から、「情報爆発」という言葉で、ペタバイト（ペタは1000兆）級の超大容量データを収集、分析する時代の到
第56回 サーバークラウドとスケールアウトクラウドは別物
Forrester Research, Inc. フランク・ジレット バイスプレジデント兼プリンシパルアナリスト クラウドコンピューティングはIT企業の戦略立案者にとって混乱を招くトピックである。どういう事かと言うと、我々の大半は根本的に異なる二つのタイプのコンピューティング形態を示す“雲”を一つのものと混同しているのだ。具体的には「サーバークラウド」と「スケールアウトクラウド」と呼ぶものである。サーバークラウドは従来型のビジネスアプリケーションで求められるものをサポートするもの。一方スケールアウトクラウドは多数のマシンで巨大なワークロード処理するために設計されたもの。例えば、Webサイトやグリッドコンピューティングのアプリケーションが該当する。 スケールアウトクラウドがサーバークラウドと違う点は大きく五つある（表）。まず極めて大きなワークロードを扱うという点。そしてソフトウエアのアーキテ
スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance
これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの（そして今なお）Webアプリケーションの定番構成である、「ロードバランサ、ア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cookpad's deployment and auto scaling