目的 2017/3/1 に us-east-1 の S3 大規模障害がありました。過去にもいくつか発生しているのと、いつ使っているリージョンで同じ事態が起きてもおかしくないと思い、これを機に過去どのような障害があったのか遡って調べました。 所感 毎年どこかのリージョンで大規模な障害が起きている ap-northeast-1 で起きていないのはたまたま、運がいいだけ AWS は復旧時間の改善・可用性向上に全力を尽くしているものの、未知の障害はいつかどこかで起きるもの ステータスダッシュボードは時に嘘をつく クラウドシェアトップである AWS はインターネット全体の SPOF になりつつある Chaos Monkey の思想は必須 報告書読むの面白い AWS の中身がすこし透けて見えてきます 前回データセンターについて調べたことが役に立った AWS のデータセンターに侵入する（妄想で） - Q

update terraform v0.9 アップデート内容については、ここに書いてあります。 https://www.hashicorp.com/blog/terraform-0-9/ やはり個人的には、 env による複数環境の構築・運用のしやすさがどうなるのかが気になったのでさっそく試してみました。 サンプルで作成したレポジトリ 今回作成したレポジトリはこちらにあります。 https://github.com/Twinuma/terraform0.9-sample 説明 env に関してはここにドキュメントがあるのでこちらを見てください。 https://www.terraform.io/docs/state/environments.html 簡単に説明すると、 terraform env new dev と実行すると、カレントディレクトリに terraform.tfstate.d

Datadog 上の原典ポストへのリンク: https://www.datadoghq.com/blog/3-clear-trends-in-ecs-adoption/ 以下は、Datadog が 2016 年末に公開した、”3 clear trends in ECS adoption” のポストを @jhotta が日本語化にしたものです。プロの翻訳ではなく、 もっぱら素早く ECS の普及状況を共有することを目的としています。技術的な要素で日本語の表記に問題がある場合は、コメントなどにより連絡をもらえますと助かります。 Last year, we published a study of Docker usage across our broad customer base. The data, which we then updated in June 2016, shows tha

AWSとGCPでマルチクラウドインフラを始めた話。複数回連載予定の第一回です！

はじめまして。 「ボーイフレンド（仮）きらめき☆ノート」（以降、ボイきら）でサーバサイドエンジニアをしております、伊藤です。今回はAWS（主にAurora周り）とPHPを使用して高信頼性かつハイパフォーマンスなシステムを構築するためのノウハウを共有させて頂きたいと思います。 目次 はじめに キャッシュの話 自動化・自動生成の話 Auroraの話 Zephirの話 おわりに はじめに まずはじめに、ボイきらのサービスとシステムの概要を簡単にご紹介します。 サービスの概要 ボイきらは2016年11月15日にリリースした女性向けリズムゲームです。事前登録は24万人を突破し、リリース後はAppleStoreの無料ランキングで1位を獲得しました。サービスの運用で特徴的なのはリリースが約2ヶ月で以下の5種類の新イベントを計11回も開催していることです。 マラソンイベント レイドイベント ハイスコアイベ

イントロ 2013年の3月頃にこんな記事を書いたのを思い出したのだが、最近事情でまた動かしてみたら気づいたことがあったのでメモ。 「GNU ld の--no-as-neededと--as-neededオプションについて」 最初によくわかっている方向けの言い訳説明をしておくと、上記はLD_PRELOADを使って hook を行う場合に準備する shared object を作る際に使用するリンカ(GNU ld)の挙動がUbuntu 12.04 前後で若干変更され、ld の option 指定に注意が必要になったという話だった。当時は上記記事の例に書いた通りに動いていたのだが、どうも今は少し事情が変わっているらしいという話である。 まず、やりたいことはこの記事のタイトルの通りである。各種事情により、system call (やlibrary関数)の処理を入り口で横取り(hook)して動きを変え

概要 2017年1月18日にリリースされた Docker v1.13 以降（今日現在の v17.03.0-ce ）は、 docker コマンドラインの命令体系が再編成されました。本記事では変更に至った背景と、新旧コマンド体系の比較情報を整理します。 新しいサブコマンド体系の導入と背景 新しいコマンド体系の導入に至ったのは、docker のトップレベル・コマンド群が 40 を越える状況（当時）となったためです。コマンドには頻繁に使うものもあれば、使わないものもあり、再編成されることになりました。 v1.13から論理オブジェクト単位にコマンドが再編成されました。これは、「何」（コンテナやイメージ、ネットワーク）を、「どうするか」（作成、一覧、起動、停止）で扱います。そのため、従来よりもコマンドの利用目的が分かりやすくなります。たとえば、コンテナを管理する docker container サブ

自社で構築した数エクサバイトのストレージシステム、 Magic Pocketを発表 して以来、多くの好意的なフィードバックをいただいています。この発表に続きまして、舞台裏からシステムの興味深い側面を見ていただくことができる技術ブログシリーズを投稿していこうと思います。保護の仕組み、運用ツール、ハードウェアとソフトウェアの境界線上の革新などです。しかし、まず、背景を説明する必要があるでしょう。本稿では、Magic Pocketのアーキテクチャ概略と設計で使われた基準についてお話しします。 紹介の投稿 で説明しましたように、Dropboxには、ファイルの内容と、ファイルやユーザについてのメタデータという2種類のデータが保存されます。Magic Pocketは、ファイルの内容を保存するのに使われるシステムです。保存するファイルは、ブロックに分割されて耐久性のためにレプリケーションされ、複数の地域