Revisit the DevOps Origin: 10+ Deploys Per Day by Flickr

DevOpsDaysの活動のきっかけになった (そして DevOps という言葉ができることにつながった)、2009年のFlickr社の発表について、文字起こしして日本語をつけてみました。

DevOpsDays Tokyo 2022
https://confengine.com/conferences/devopsdays-tokyo-2022/proposal/16208/devops-flickr-10-deploys-per-day-2009

Original Video:
Velocity 09: John Allspaw and Paul Hammond, "10+ Deploys Per Day
https://www.youtube.com/watch?v=LdOe18KhtT4

Original Slide Deck:
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

Transcript

1. DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年) を再訪する https://www.slideshare.net/jallspaw/ 10-deploys-per-day-dev-and-ops-cooperation-at-flickr https://www.youtube.com/watch? v=LdOe18KhtT4
2. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 株式会社ホロラボ シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
3. 10 deploys per day Dev &ops cooperation at Flickr John Allspaw &Paul Hammond Velocity 2009
4. John Allspaw 00:11 皆さん、聞こえていますか？はい。私の 名前はジョン・アルスポー、Flickrのオ ペレーショングループを担当しています。 Paul Hammond 00:22 Flickr社でエンジニアリンググループを 担当しているポール・ハモンドと申しま す。 John Allspaw 00:29 今日の話は、実際には様々なトピックを 扱う予定ですが、開発と運用がどのよう にフィットして仲良くなり、実際に協力 して、お互いに大馬鹿者ではないことを 説明するための手段とでも言いましょう か。 Flickrで。
5. Paul Hammond 00:51 しかし、始める前に、Flickrとは何 かについて少し話しておきましょう。 Flickrについて聞いたことがある人 は手を挙げてください。さて、 Flickrを知らない人のために説明し ますと、 Flickrは写真共有サイトで す。現在、約30億枚の写真を保存し ています。そして、1日の任意の時点 で、1秒間に約40,000枚の写真を提 供しています。これらの写真は、約6 ペタバイトのストレージを占めてい ます。子猫がたくさんいるように見 えるかもしれませんが、実はとても 大きいのです。
6. John Allspaw 01:26 そうそう、今回は歴史的、伝統的に 開発(Dev)と運用(Ops)についてお話 します。 今でも、これは通常、開発vs 運用と 考えられています。基調講演では、 このような二人の男がいるという図 式がありました。よく耳にする言葉 ですね。
7. John Allspaw 01:26 「それは私のマシンではなく、あな たのコードだ。」 Paul Hammond 01:54 「私のコードではなく、あなたのマ シンだ」 と言っているのが聞こえてきます。
8. John Allspaw 01:59 そして、ステレオタイプは、開発者と 運用者の典型的なタイプを作ります。 開発者の中には、ちょっと変わった人 もいるでしょう。開発者の中には、 ちょっと変わった人もいるかもしれま せん。彼らは数学の分野では本当に優 秀で、運用担当者は何か問題が起こる たびにパニックになります。興奮しや すいのです。お酒を飲みすぎることも あるし、飲まないこともある。このよ うに、真面目な話をすると、「どう ぞ」というステレオタイプになってし まうのです。
9. Paul Hammond 02:45 運用担当者というと、もうひとつのス テレオタイプは、「不機嫌な老人」で す。そう、いつも「ノー」と言う不機 嫌なおじさんです。彼らは、これらの 新しい機能がサイトを壊すのではない かと恐れています。とてもとても指摘 好きで、批判ばかり。
10. John Allspaw 03:00 そうそう、彼らはいつもノーと言いま す。だってサイトが予期せず壊れちゃ いますよ。ステレオタイプのOPSのマ ネージャーは、こんな不機嫌な男のよ うに、「いや、それはやりたくない」 と言うんでしょうか。いや、私はそう はなりたくありません。そんな人とだ れが働きたいんでしょう？誰もいませ んよ、嫌な奴だから。
11. Paul Hammond 03:24 このような固定観念の根源を探ると、 それは開発者(Dev)の役割と運用 (Ops)の役割に関する伝統的な考え方 に帰着します。
12. Paul Hammond 03:24 多くの人が考えるのは、開発者(Dev) の仕事はサイトに新しい機能を追加す ること。そして運用者(Ops)の仕事は、 サイトの安定性と高速性を維持するこ とです。
13. Paul Hammond 03:24 多くの人が考えるのは、開発者(Dev) の仕事はサイトに新しい機能を追加す ること。そして運用者(Ops)の仕事は、 サイトの安定性と高速性を維持するこ とです。 ですよね？違いますか？運用(Ops) の 仕事は、サイトを安全かつ高速に保つ ことではないと思います。それは彼ら の仕事ではありません。
14. John Allspaw 03:44 これは、ある人にとっては新しい発見かも しれませんが、運用(Ops)の仕事はビジネ スを可能にすることですよね？もしビジネ ス要件として、2週間ごとにサイトを停止 しなければならないとしたら、たとえあな たが最大のオンラインゲームプラット フォームであり、何百万人もの有料顧客を 抱えていたとしても、その銀行顧客は可用 性が97%を許容します。 99.999%でな く。これは真実です。このサイトの安定性 と高速性を維持することは、よくあるビジ ネス要件です。ビジネス要件の話なんです。
15. Paul Hammond 04:34 ビジネス、特にオンラインビジネスで 働く上での現実の一つは、ビジネスに は変化が必要だということです。もし あなたのビジネスが立ち止まっていた ら、TwitterやFacebookのような新 興企業に乗っ取られ、追い越されるこ とになるでしょう。
16. Paul Hammond 04:34 もちろん、問題はその変化です。ほと んどの障害の根本原因を調べて一般化 すると、「変化」という結論に至りま す。 ほとんどの障害の根本原因は「変 化」なのでしょうか？数日前、数時間 前、数週間前に変更がなければ、ほと んどの障害は起こりません。
17. John Allspaw 05:09 つまり、2つの選択肢があります。安 定性を重視して変化を阻止するか。そ れとも、賢くなって、必要に応じて変 化を起こせるようなツールや文化を構 築するかです。
18. Paul Hammond 05:29 今日お話しする内容のほとんどは、上 手なツールの使い方と、チーム内での 優れた作業文化によって、変更のリス クを低減することです。これらのツー ルを使ってやろうとしていることは、 ある変更がシステム停止や現場での問 題を引き起こさないという確信を高め ることです。また、万が一、障害が発 生した場合の復旧能力を高める方法に ついても検討しています。
19. Dev and Ops
20. John Allspaw 06:03 もちろん、開発者と同じような考え方 をする人たちがオペレーションをして くれれば、それはとても助かります。
21. Paul Hammond 06:11 会場にいる皆さんの中で、自分はDev だと思っている人は何人いますか？自 分はOps側の人間だと思っている人は どれくらいいるでしょうか？また、両 方の仕事をしている人はどのくらいい るでしょうか？では、会場にいる運用 担当者の中で、最近、ユーザー向けの アプリケーションコードを変更したこ とがある人は何人いますか？ John Allspaw 06:51 一握りですね。その変更をしたことを 喜んでくれる開発者と一緒に仕事をし ている人はどれくらいいるでしょう か？はは、何かおかしいですね。
22. Paul Hammond 07:02 開発者の皆さんの中で、サイトに何ら かの問題が発生して、週末の夕方に見 つかったために、家で仕事をしたこと がある人はどれくらいいるでしょう か？この会場にいる開発者の3分の1 くらいでしょうか。ポケベルを持って いる人はどれくらいいますか？あるい はオンコールで、開発者である開発者 と開発者である開発者がいますか？サ イトが完全に落ちてしまうまでに、何 台のウェブサーバーを失っても大丈夫 かを知っている人は何人いるでしょう か？
23. John Allspaw 07:29 これは常にいい質問ではないのでしょ うか？その答えは、常に彼らのように もっと考えることができるということ だと思います。ねぇ。
24. Tools
25. Paul Hammond 07:42 そこで今回は、ツールについて少しお 話ししましょう。そして、このツール の議論でやりたいことは、これらは私 たちに有効なツールの一部です。必ず しもすべての人に使えるわけではあり ません。全体を通して、私たちが使っ ている具体的なツールの例を挙げてい きたいと思います。しかし、私たちが 伝えようとしている重要なことは、こ のカンファレンスの共通テーマになる でしょう。
26. 1.Automated infrastructure If there is only one thing you do…
27. Paul Hammond 07:42 自動化されたインフラとは、そのよう な技術であり、オペレーションの仕事 を可能にするものです。1,000台以上 のサーバーがある場合、個々のサー バーを手動で管理することは現実的で はありません。開発者の視点から見る と、アプリを構築するための一貫した 予測可能なプラットフォームを提供し ます。
28. .Automated infrastructure If there is only one thing you do… Chef Puppet CFengine FAI System Imager Cobbler BCfg2
29. Paul Hammond 07:42 つまり、Apache 1.3を実行している 10台のウェブサーバーと、 Apache 2.ｘを実行している3台の ウェブサーバーは、アップグレードの 最中でなければ、それが動いているこ とを、知ることができます。しかし、 このような一貫したプラットフォーム がなければ、開発者が仕事をするのは 本当に難しいのです。
30. John Allspaw 08:45 私たちはあらゆる種類のツールを持っ ていますが、この講演はそのことにつ いてではありません。このテーマにつ いては、AdamとEzraがもう少し後に 講演をする予定ですし、もっと良いプ レゼンテーションが6つほどあります。
31. Paul Hammond 09:35 しかし、ここでの重要なポイントは、 iOSのイメージを持っているというこ とです。そして、このサーバー、イン フラの一部、またはクラウドのビット が実際に行う何らかの役割があり、そ れはタスク駆動型のインフラです。実 際には何の違いもありません。
32. Paul Hammond 09:35 このサーバーとクラウドの違いは、こ のサーバーの周りに青い雲があること です。それだけで、考え方は同じです。 例えばEC2でサーバーを運用していて、 OSのイメージング側はamiが担当して いても、その上にロールと構成管理の レイヤーが必要になるということです ね。 John Allspaw 09:45 そうですね、それ以上に重要かもしれ ません。
33. 2.Shared version control
34. Paul Hammond 09:50 次に紹介するツールは、バージョン管理です。開発チームの 中には、バージョン管理なしで運用しようとする人はあまり いないでしょう。そして、ますます多くの運用チームが使う ようになっています。 バージョン管理を使うことは、実際、 かつて私たちがやっていたことでもあります。かつては、 FlickrのソースコードはCVSに格納されていましたが、運用 やパッケージ、構成管理のすべてはPerforceに格納されてい ました。そのため、開発者は何が起こっているのかわからず、 Perforceのリポジトリをどうやってチェックすればいいのか わからず、ジョンはCVSのリポジトリをどうやってチェック すればいいのかわからなかったのです。
35. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、 チームの誰もが、どこを見れば特定のボック ス用の設定の最新インスタンスを見つけられ るのかを知ることができ、また、アプリケー ションで何が起こっているのか、どこに変更 があるのかを知ることができます。これは、 緊急時には本当に便利です。先週の金曜日、 私は外で食事をしているときに、サイトの一 部に問題が発生していることがわかりました。 ジョンのチームで働いているケビンが私に電 話をかけてきたのです。もしソースコードの リポジトリが違っていたら、ケビンがアクセ スできなかったかもしれないし、私が家に 帰ってラップトップを取り出し、自分で修正 しなければならなかったでしょう。このよう に、シングルソースコントロールは透明性を 提供してくれるので、非常に便利です。
36. 3.One step build
37. Paul Hammond 09:50 開発の観点からは、ワンステップビルドを設定することが最も重 要です。ワンステップビルドとは、現在svnのソースコントロー ルシステムに登録されているコードを、本番サーバーにコピーし てサイトを実行できるようなファイルセットにするために必要な すべてのことを意味します。今お見せしているスクリーンショッ トは、 Flickr内部の開発管理インターフェースの一部です。画 面の一番下にある「ステージングを行う」と書かれたボタンをク リックすると、SVMチェックアウトが行われ、すべての翻訳、 すべてのテンプレートのコンパイル、最適化のためのコンパイル などが行われます。そして、そのコードをステージング・サー バーにコピーして、テストできるようにします。
39. Paul Hammond 09:50 今お見せしているスクリーンショットは、Flickr内部の開発管理インター フェースの一部です。画面の一番下にある「ステージングを行う」と書か れたボタンをクリックすると、svnチェックアウトが行われ、すべての翻 訳、すべてのテンプレートのコンパイル、最適化のためのコンパイルなど が行われます。そして、そのコードをステージング・サーバーにコピーし て、テストできるようにします。 John Allspaw 12:07 自動的に自動的に、つまり、人がこのコマンドを実行していないのに、こ のコマンドを実行するのです。結論から言うと、コンピュータはコマンド を同時に実行するのがとても得意で、何度も同じ順番で実行されます。 Paul Hammond 12:20 また、開発者が自分のワークステーションでビルドを行い、それが開発者 とは微妙に異なる設定になっているような状況もありません。そのため、 コードに大きな変更がなくても、その後の変更で、アプリケーションがデ プロイされたときの支払いが大きく変わってしまうのです。
40. Paul Hammond 09:50 ワンステップビルドができたら、 次に必要なのはワンステップデプロイです。
42. Paul Hammond 09:50 これはFlickr内部のデプロイ用管理ツールで、上部にはデプロイログ が表示されています。これは非常に安上がりな変更管理方法で、誰も が何が起こっているかを見ることができ、システムの他の場所で何か 変更が起こっているので、今がデプロイの絶好の機会であることを警 告することができるということです。下部には「I'm feeling lucky」と書かれたボタンがあります。これを押すと、コードが横に 押し出されます。コードを横に押し出しているときの様子はこんな感 じです。同じ原理がここにも当てはまります。ボタンを1つにするこ とで、エラーの余地が非常に少なくなり、一貫した環境でビルドやデ プロイを行うことができ、間違った手動の手順がなくなるのです。つ まり、ソースコードの差分を見れば、それがデプロイされたときのア プリケーションの動作に見られる唯一の違いになると、かなりの自信 を持って言えるのではないでしょうか。
44. John Allspaw 13:35 そして、これこそが私たちのやり方なのです。しかし、継続 的なデプロイメントがトレンドになっていますね。そして、 継続的インテグレーションは、多くの運用ツールや、ベン ダーが販売しているもの、さらにはオープンソースのプロ ジェクトにも登場し始めています。これは良いアイデアだと 思います。
45. [2009-06-22 16:03:57] [harmes] site deployed (changes...) Who? When? What?
46. John Allspaw 13:35 このプロセスで最も素晴らしいことの一つは、 デプロイ・ログがあることです。誰が、いつ、 何をしたかがわかります。John Adamsは、 監視・測定ツールの一番上にデプロイ時のタ イムスタンプを置いていることを先ほど紹介 しました。コンテキストが絶対的に重要なの です。この講演のタイトルは、1日に10回以 上のデプロイを行うというものです。1日に 10回もデプロイするふりをしたり、しよう としたりすることはできません。1日に10回 もサーバダウンしていたら、それはアジャイ ルではなく、ただのダメな人です。
48. Paul Hammond 14:45 私がここで伝えたいことの一つは、Webページ上にプロセスを結びつけ ないワンボタンを設置するだけではないということです。ソースコント ロールのルートにmakeスクリプトやmakeファイルを置いているかもし れません。デプロイに関しては シェルスクリプトを実行するだけでもい いですし、Capistranoを使ってもいいですし、RPMを使ってもいいで しょう。先ほど紹介したデプロイシステムは、Flickrのメインアプリ ケーションがどのようにデプロイされるかを示しています。周辺の小さ なアプリケーションで実験を始めていることの一つに、継続的インテグ レーション・サーバー（Hudson）を使ってパッケージを自動的に生成 し、運用チームがボックスにデプロイする方法があります。繰り返しに なりますがSVNのファイルをコミットするだけのシングルステップビル ドです。SVNのファイルをコミットし、ボタンを1つ押すだけでパッ ケージが生成されます。そして、シングルステップデプロイでは、運用 チームの誰かが実際にそのパッケージや開発者をデプロイしていきます。 ※Hudsonは 現在の Jenkins です。
49. Paul Hammond 14:45 ジョンがすでに述べたように、私た ちのビルドとデプロイのシステムは 完全に自動化されているので、より 頻繁にデプロイすることができます。 また、1回のデプロイを小さくするこ とができるので、個々のデプロイの リスクが少なくなり、万が一何か問 題が発生した場合でも、何が起こっ たのかを簡単に調べることができる ので、リカバリーが可能になります。
50. 4.Feature flags (aka branching in code)
51. Paul Hammond 14:45 次に紹介するのは、これまた開発者向け の話です。それは、フィーチャーフラグ と呼ばれるものです。これは、コードの 分岐(ブランチ)と考えることもできます。
52. Paul Hammond 14:45 リビジョン管理の分岐システムについて考えて みると、それはデスクトップソフトウェアを構 築する際の現実に対する反応です。そして、開 発チームはすぐにMicrosoft Word 1.1の開発 を始めます。そして、makeを動かして、1.1を 起動します。そして数日後、重大なセキュリ ティ上の脆弱性があることに気づきます。そこ で、1.0のコードベースに戻って変更を加え、 それを出荷しなければなりません。そして、 1.2をリリースします。そして、1.2をリリー スすると、また別の変更を加えなければなりま せん。つまり、一度に3つの異なるバージョン のソフトウェアをリリースすることになります。
53. Paul Hammond 14:45 しかし、ウェブアプリケーション のインスタンスが1つしかない場合 は、そうはいきません。私たちが 持っているのは、現在デプロイさ れているものだけであり、古い バージョンはもう重要ではありま せん。
54. Paul Hammond 14:45 私たちがこの問題に対処する方法は、 常にトランクを出荷することです。す べての開発をtrunkで行っているわけで はありませんが、ブランチで開発を行 い、そのブランチをマージすることも 可能です。 ※現在主流の Githubでは 2020年にtrunk は main に 変更されました。
55. Paul Hammond 14:45 しかし、常にtrunkを出荷することで、 チームの誰もが、現在サイトにデプロ イされているコードのバージョンがど こにあるのかを正確に知ることができ、 どのブランチのどのパッチリリースが 現在リリースされているものなのかを 考える必要がなくなります。
56. #php if ($cfg['enable_feature_video']){ … } {* smarty *} {if $cfg.enable_feature_beehive} … {/if} Feature flags
57. Paul Hammond 14:45 SVN(Subversion)に入ると、そこには トランクがあります。先ほど、SVNで はブランチを行わないと言いました。 代わりにコードで分岐を行います。つ まり、すぐにはリリースしない機能を 開発しているときは、条件分岐を使っ てその特定の分岐をブロックしている のです。ここでは、PHPの例を紹介し ます。これはSmartyの例です。つまり、 まだリリースされていないすべての新 機能のコードを、実際に本番サーバー に置いておくことができるのです。本 番サーバーでは、設定を変更するだけ で、まだ実際には表示されません。
58. Paul Hammond 18:11 この機能により、いくつかの優れたトリックが可能 になります。1つ目は、本番サーバー、本番ハード ウェア、本番トラフィックでプライベートベータを 行うことができるということです。もちろん、私た ちには現実的なテストを行うことができる素晴らし いステージング環境があります。そして、そのよう な環境で多くのQAを行いました。しかし、私たち が発見したのは、テストのために2台目のサーバー を使用した場合、ベータ版サーバーと本番サーバー の間で設定の変更があることに気づくかもしれない ということでした。構成管理を行っていても、ベー タ版サーバーでは新機能が完璧に動作していたのに、 本番版サーバーに移行した途端に動作しなくなった ということがあります。しかし、本番環境に移行し た途端、頼りにしていたバックエンドの内部ウェブ サービスが、本番環境のダブダブからブロックされ ていることに気付きました。そのため機能が動作せ ず、そのバックエンドのウェブサービスに緊急の変 更要求を出さなければなりませんでした。
59. Paul Hammond 18:11 これでバケットテストができるようになりました。 これは非常に便利なことです。つまり、新しい コードパスを手に入れて、新しいバックエンドシ ステムの使用を検討している場合、まずは5%の トラフィックをプッシュして、その後10、20、 30、50%と増やしていき、一部のユーザーに対 して機能をオンにすることができるのです。異な るバージョンのソフトウェアを異なるサーバーで 実行したり、本番環境に入れたり出したりといっ たことを慎重に行う必要はなく、すべてコードで 行うことができます。
60. Paul Hammond 18:11 そして最後に、ダークローンチこれは、 先ほどJonathanがFacebookの話をし たときに言っていたことですが、新しい 機能を舞台裏で立ち上げることができる のです。例えば、検索クラスタのデータ ベース・サーバーのmemcachedボック スに負荷をかけるような新機能があった 場合、その機能を裏でオンにして、数週 間データの取得を開始し、そのデータは 表示しないようにします。
61. John Allspaw 20:00 Opsにとっては、不安を取り除くことができるという点で、非常に大き なメリットがあります。申し訳ありませんが、ギグから恐怖を取り除く ことができるのです。そうではなくて、新しいお酒のホームページの例 を挙げてくれましたか？私は知りませんでした。そうですね。つまり、 私たちは新しいFlickrのホームページを再設計し、より多くの情報、基 本的にはあなたの連絡先からのアクティビティや、リアルタイムでスト リーミングされる様々な量のアクティビティを持っています。膨大な量 のデータだよ。そうでしょ？ではどうすればいいのかというと、これか ら配信するすべてのホームページは、データベースからより多くのデー タを取得することになります。でも、データベースは最悪です。それは とても面倒なことです。そして、そして、そして、本当に怖いです。そ こで私たちは実行しました。何週間もかけてリリースしました。そう。 アプリケーションがそれを受け取って、データはどうなるんですか？お かげで、実際のローンチはまったく拍子抜けするようなものになりまし た。これはとてもいいことですね。そう、この時点で明らかになってい るはずなんです。これらの機能フラグや無効フラグは、今いくつあるの かな。
62. John Allspaw 21:12 100点満点の結果が出れば、それを無効 にすることができます。また、サイトに 影響を与えているもの、つまり可用性や パフォーマンスに関わるものの動作を変 更することもできます。データベースク ラスターがたまたま劣化していたり、他 のバックエンドサービスが劣化していた りして、それが機能に依存している場合 は、これを変更することができます。そ して、サイトに影響を与えることなく、 ロールバックすることができます。多く の場合、ロールフォワードしてオフにし ます。これらの機能フラグの中には、単 にオンかオフかだけではないものもあり ます。Paulが言っていたように、量を変 えられるノブのようなものもあります。 だから良いのです。
63. 5.Shared metrics
64. John Allspaw 21:12 メトリクスの共有。メトリクスを共有すること は、バージョンコントロールを共有することと 同じです。あなたは私のビットを見ることがで き、私はあなたのビットを見ることができます。 まあ、私たちはメトリクスを集めています。
66. John Allspaw 21:12 これは私たちのガングリオンのインス トールのスクリーンショットです。37の 異なるクラスターがありますが、どれだ けの数のメトリクスを収集しているかわ かりません。 ここで重要なのは、開発者 はこれがどこにあるかを知っているだけ でなく、アクセス権を持っていて、運用 と同じくらい熱心に見ているということ です。オフィスを歩けば、すべての開発 者が少なくともブラウザの1つのタブに、 このようなものを持っています。
67. John Allspaw 21:12 CPU、ネットワーク、メモリ、ディスクなど のアプリケーションレベルのメトリクスをそこ に入れることができるということです。ユー ザーCPUが75%であろうと、そのうちの何% であろうと、私は気にしません。その役割とは、 サーバーがウィジェットを食べているかどうか、 1秒間に何個のウィジェットを食べているか、 それぞれのパーツ、それぞれのビット、それぞ れのCPUの割合です。これは当然、キャパシ ティマネジメントやキャパシティプランニング などにも関わってきますが、もしそれが重要だ と思うのであれば、そのようなことも必要です。 これは、画像処理を行う特定のサーバーの、過 去1分間の平均値を示したグラフです。あなた が子猫をFlickrにアップロードすると、私たち はそれを6つ、あるいは5つ、あるいは6つの 異なるサイズに切り分けます。それぞれの処理 にかかった時間の平均値を示しています。
68. Paul Hammond 24:10 これは、非同期タスクキューにあるバックグ ラウンドタスクの数を示したグラフです。面 白いのは、このグラフに表示されている指標 を私が実際に作ったことです。このグラフを 作成した理由の一つは、Johnのチームに頼ま れたからではなく、オフラインタスクシステ ムのパフォーマンスをある程度把握したかっ たからです。ここで興味深いのは、開発者が 伝統的な運用指標を作りたがるというダイナ ミックな状況があることです。ジョンのチー ムは、私たちがこれらを簡単に作れるように してくれました。今では、アプリケーション のどの部分であっても、キーと値のペアを含 むファイルを書くだけで、ガングリオンの セットアップがそれを取り込んで、かなり アーティスティックなグラフを作ってくれる フレームワークを持っています。
69. Adaptive feedback loops App System Metrics RU ok? maybe?
70. Paul Hammond 24:10 これが、アプリケーションにおける適応型 フィードバックループの作成につながります。 つまり、非同期に起こっていることがあれば、 システムがうまく機能していない場合には、 アプリケーションが手を引いて、システムへ の負荷を減らすようにすることができるので す。先ほど説明したオフラインタスクセン ターは、データベースが過負荷になり始める と、実際にダイヤルバックして、データベー スがリアルタイムの負荷に対応できるように してくれます。もし10分後にオフラインタス クを実行する必要があっても、それは大した ことではありません。また、Yahooフォトか らFlickrへの移行を行った際には、ストレー ジの空き容量に応じてスロットルをかけ、ス トレージが不足しないようにしました。
71. John Allspaw 25:42 ああ、あれは本当にいい例です。このように、数ヶ月に及ぶプロセスが ありますよね。彼らはYahooフォトを閉鎖していますが、Yahooフォ トをどうするかの選択肢の1つとして、Shutterflyや他のいくつかの場 所に行って、 Flickrに移行することができますよね？本質的には何なの でしょうか？10年分のYahooの写真を、Flickrが持っているのと同じ フォーマットで、すべてのメタデータとともにFlickrにインポートする には、膨大な時間がかかるでしょう。ですから「Flickrに移行したいと 思うのですが」「わかりました。あとでご連絡します。」と答えなけれ ばなりませんでした。Yahooの写真とFlickrでは大きな違いがあったの で、異なるサイズに処理しなければなりませんでした。ご存知のように、 私たちはどのくらいの量のストレージがいつオンラインになるのか、か なり厳密に把握しています。しかし、私たちが知らなかったのは、何人 の人がそのボタンをクリックするのかという巨大な未知の変数でした。 「はい、フリッカーに行きます」と言う人はどれくらいいるか。移行の 全期間を通じて、本当にこの変数に依存していました。つまり、いつス ペースが足りなくなるかを予測し、それを変更していくということです。 そして、それに適応するための移行は、私たちにとって非常に大きな勝 利でした。
72. John Allspaw 27:24 私たちは、すべての指標のすべてのページに、 最後にサイトが展開された時刻を表示してい ますが、これはすでに設定済みです。 Paul Hammond 27:35 そのため、あるグラフがなぜ2倍になったの か、あるいは半分になったのかを簡単に把握 することができます。これは、私のチームが 画像処理コードの最適化を行った例です。ど のような効果があるのかわからなかったので すが、ちょっとしたことだろうと思っていた ら、かなりの効果があることがわかりました。
73. 6.IRC and IM robots
74. John Allspaw 27:58 コミュニケ―ションは、ツールの最後のパートです。 Flickr では、他の多くの場所と同様に、IRCを多用しています。開発 者と運営者の間の継続的な対話のために使用しています。IRC は、特にリモートで仕事をしている人にとっては便利です。そ れで、このような会話が行われているわけです。そして、文脈 があるのは良いことだと思います。そこで私たちは、前回の FMで、まさにこのようなことをするための素晴らしい小さな ツールを書きました。
75. Dev, Ops, and Robots Having a conversation IRC search engine alerts monitors deploy logs build logs
76. John Allspaw 27:58 IRCのストリームにイベント、つまりコンピュー タ主導のイベントを流します。例えば、私たちが 本当に気にしている特定のアラートやモニターは、 ビルドログや、何かがデプロイされたときのデプ ロイログです。つまり、あなたは会話をしていて、 ある書き換えルールとデプロイでこんな問題が起 きていることを知らないのです。それについてど う思いますか、それともアラートが出ないのです か？そこで実際にやることは、このログに記録さ れた情報をすべて、検索エンジンに突っ込むこと です。そうすれば、2ヶ月前の木曜日に一体何を していたのか、何が起こっていたのかを知ること ができます。以前にもこのような問題があったの か。人間がコンテキストを持つようになったとい うことで、本当に助かりました。IRCツールで過 去にさかのぼって調べられるだけでなく、実際に 人間の文脈があるわけですから。
77. Culture
78. Paul Hammond 29:28 どのようなツールを導入しても、信じられないほどの議 論好き、闘争心の強い文化の下では、役に立ちません。 そしてもうひとつ、私たちの仕事ぶりを非常に楽にして いると思うのが、Flickrが持つ文化です。自動化された インフラのようにね。申し訳程度のグラウンドゼロのよ うなもので、ツールに関しては非常に基本的なことをし なければならないようなものです。
79. 1.Respect If there is only one thing you do…
80. Paul Hammond 29:28 文化に関して言えば これを言うのはちょっと偽 善的ですが、最も重要なことの1つは固定観念を 避けることです。あなたが5年前に一緒に働いて いたカウボーイは、あなたのアプリケーションに 関心がなかったり、システムのアップタイムに関 心がなかったりしましたよね。しかし、あなたが 一緒に仕事をする開発者の全員が彼のようなウイ ルスに感染しているわけではありませんし、運用 担当者の全員が彼のように妨害されるわけではあ りません。誰もが最悪の事態を想定するなら、誰 もがあなたに最悪の事態を想定することになるで しょう。
81. Paul Hammond 30:36 誰もが繊細な小さな雪の結晶であり、誰もが少し ずつ、彼らは異なる経験を持っており、あなたと は異なる問題解決策を思いつくからです。それら の解決策はベストなものではないかもしれません が、少なくとも彼らの提案を尊重すべきです。も うひとつ重要なことは、人それぞれの責任を尊重 することです。私たちは皆、ビジネスに対して異 なる責任を負っています。つまり、私たちはそれ ぞれ異なる優先順位を持っているということです。 それを理解し、認識し、そして尊重することが大 切です。
82. John Allspaw 31:20 それは、問題について会話をするときに、「いいえ」 と言うことは、「あなたの問題には関心がありませ ん」と言っているようなものだということです。ブ ルーム・フィルターは書けません。開発者が問題を解 決しようとしているのか、運用担当者が問題を解決し ようとしているのか、何を解決しようとしているのか を知ることができます。ここで最もクールなものを見 つけることができます。規模の壁を乗り越えて成功し た企業のほとんどは、開発者と運用担当者が一緒に なってユニークなソリューションを考え出したところ です。memcachedがいい例です。かつては、データ ベースといえば、DBAや運用担当者がいて、それが彼 らの仕事だったんです。私は開発者なので、コードを 書きます。そして、どこかに魔法のようなデータベー スがあって、私に代わって答えを出してくれる。そし て、memcachedが開発されました。そして、この問 題を解決するために様々なアーキテクチャが設計され ました。そして、それが実現したのは、開発者と運用 者が一緒に仕事をしたときだけです。
83. Paul Hammond 32:41 もし、あなたが問題を解決しようとしているときに、 同僚や他のチームからの反応が「それはダメだ」と いうものであることがわかっているなら、解決策を 隠しておくのは、本当にダメなことです。私がやり たいことをジョンが断るとしたら、それはおそらく 正当な理由があるはずです。それを隠してしまうと、 彼に専門知識を提供する機会を与えないことになり ます。さらに重要なことは、もし私が何かを隠して いたら、彼はいずれそれを知ることになるでしょう し、知ったときにはきっと怒るでしょう。 べきです。
84. Developers:Talkto ops about the impact of your code: •what metrics will change, and how? •what are the risks? •what are the signs that something is going wrong? •what are the contingencies? This means you need to work this out before talking to ops
85. Paul Hammond 32:41 繰り返しになりますが、開発者にとって、自分の仕事に敬意を払っても らうためにできることのひとつは、何かを立ち上げる前、あるいは何か を提案する前に、その影響について前もってOpsに相談することです。 もしあなたがコードを公開するなら、どのような指標が変わるでしょう か？どのようなボックスでしょうか？CPUの使用量は増えますか？ど のボックスの空きメモリが増えますか？何かが間違っているかもしれな いリスクは何ですか？実際に何か問題が起きていることを示す兆候は何 ですか？では、運用チームは何に気をつけるべきでしょうか？そして、 もし何かが起こり始めたら？不測の事態とは何か？サイトを継続的に運 営するために、オペレーションチームはどのように回復することができ るのでしょうか？これらの答えを導き出すための問題は、オペレーショ ンチームに話を聞きに行く前に、これらの答えを導き出す必要があると いうことです。すべての答えを得ることはできないかもしれませんが、 少なくともこれを会話のベースにすべきです。
86. 2.Trust
87. John Allspaw 34:05 そして、信頼へとつながっていきます。
88. Ops needs to trust dev to involve them on feature discussions Dev needs to trust ops to discuss infrastructure changes Everyone needs to trust that everyone else is doing their best for the business http://www.flickr.com/photos/85128884@N00/2650981813/
89. John Allspaw 34:05 最後のスライドには、会話を成立させるのに役立つ様々な事柄や推奨事項が 書かれています。つまり、開発者が運用担当者のところに来て、不機嫌な運 用担当者だけど、そんなに長くは不機嫌にならないだろうと思って、こう 言ったとしましょう。「クラスタA,B,Cの低い特性が変わると思うんだ。こ れを作ったんだけど、小さなフックがあって、これをゼロに設定できるんだ。 何かあったら私のせいにしてください。」この機能のために、このコードを 入れるのは良いことだと思わなければなりません。この男は本当に考えてい るんだな。それだけではなく、彼はこのことを気にかけています。彼はサイ トのアップタイムを気にしているし、真夜中に私のチームを起こさないよう に気にしています。これは信頼の問題です。運用担当者は、機能の議論に参 加させるために開発者を信頼する必要があります。つまり、自分たちの間で 「新しい機能ができた、最高だ」と話しているわけです。ここで言っている のは、キャパシティプランニングのような、早期に行われるべき通常のオペ レーションの話ではありません。私が言っているのは、サイトに起こる変化 のことです。
90. Paul Hammond 35:25 開発チームは、運用チームがインフラの変更につい て事前に話し合うことを信頼する必要があります。 繰り返しになりますが、本当に当たり前のことをし ているように聞こえます。しかし、私は過去にいく つかの機能不全のチームで働いたことがありますが、 そこではこれが必要なこととして受け入れられてい ませんでした。これは、組織全体のためにベストを 尽くそうとしている他のメンバーを、皆が信頼して いるということに帰結します。 John Allspaw 35:58 「うん、うん、ジムには言わない方がいいよね。 だって、言ったらどうせ怒り散らすよね」「いいか らやっちまおうぜ」それはつまりあなたもクソッタ レのカウボーイになるってことです。ほかのみんな にもそれをしてほしくはないでしょう。
91. Paul Hammond 36:17 この会話を確実に行うために私たちが実践して いることは、可能な限り共有のランブックと共 有のエスカレーションプランを作成することで す。つまり、ジョンと私が一緒に座って、どん な機能を見ても、あるいはチームのメンバーが 一緒に座って、この新機能が運用面でどのよう にサポートされるのかを検討するのです。何 を？失敗する可能性のあるシナリオは何か？誰 がその修正に関与する必要があるのか、そのた めにはどのような会話が必要なのか。リスクは 何か？不測の事態に備えて、全員が参加してい るかどうかを確認する。
92. John Allspaw 36:57 そうは言っていられないのです。開発者が苦労 して作ったコードを監視するためのノブやレ バーを提供することが多すぎるのです。そして、 開発者はこれらのことが運用できるように、 フックやノブ、レバーを書きます。 Paul Hammond 37:20 ただコードを投げ込むだけでは不十分で、すべ ての変数にまつわる仮定があらかじめコンパイ ルされていて、オペレーションがそれを変更で きないようになっています。20個の子プロセ スを持つことが良い数字だと思うなら、オペ レーションが設定できるようにして、その下に あるハードウェアをアップグレードしたら、自 分たちでそれを実行できるようにしなければな りません。
93. John Allspaw 37:50 私は、開発者がシステム上で何が起こっているかを確認できるようにすべき だと考えています。電話のタグを渡すのは最悪です。シェルコマンドでは、 ただの馬鹿です。ところで、開発者はあなたのマシンで動いているコードを 書いています。もちろんガードレールは重要ですが、誰かに読み取り専用の シェルアカウントを与えることは、たとえ本番用のハードウェアで超偏執的 になっていたとしても、リスクは低く、実際に何が起こっているかを見るこ とができます。それは、あなたが共有しているメトリクスを超えて、あなた が運用担当者として共有しているからこそ、彼らが実際に内部に入り込み、 gangliaやNagiosにあるメトリクスだけでなく、あなたのすべてのメトリ クスにアクセスできることを確認できるということです。そして、何が起 こっているのかを見極める必要があり、それを許可することを恐れてはいけ ません。
94. Paul Hammond 38:53 私たちは、すべての開発者がすべての本番マシンでRoot権 限を持つべきだとは言いません。開発者としては、アプリ ケーションが作成しているファイルやロックファイルを見る ことができず、プロセスツリーを見ることもできないのであ れば、自分のアプリケーションでより良い方法があるかどう かを診断することは非常に困難です。個々のアプリケーショ ンがどれだけのCPUを消費しているかを知ることは、マシン にアクセスできなければ、オペレーションを助けることは非 常に難しいのです。
95. 3.Healthy attitude about failure
96. Paul Hammond 38:53 文化の3つ目の側面として、失敗に対する 健全な態度についてお話しします。
97. Paul Hammond 38:53 ここで重要なことは、失敗は必ず起こるという ことです。起こるかどうかは問題ではなく、い つ起こるかが問題なのです。
98. Paul Hammond 38:53 もしあなたが失敗を防ぐ方法を考えることに時 間を費やしているのであれば、失敗が起こった ときにどのように対応するかを考えることに時 間を費やしていないことになります。例えば、 航空会社のパイロットは、毎月何日も何時間も シミュレーターに通い、エンジンが止まったら どうなるかを考えます。何か問題が起きたとき のための手順や、避難計画なども策定していま す。
99. Paul Hammond 38:53 もしあなたがサイトの停止中に何らかの医療問 題を抱えているとしたら、年に一度、心臓発作 に対処する救急救命士に治療してもらいたいと 思いますか？それとも、数週間に一度、心臓発 作に対処する救急隊員の方がいいでしょうか。 ですから、オペレーションチームと開発チーム の両方に必要なことのひとつは、問題に迅速か つ効果的に対応する能力なのです。もちろん、 毎週のように障害に対処していたら、もっと大 きな問題が発生してしまいます。そこで、消防 訓練の話に戻ります。
100. Paul Hammond 38:53 Flickrで障害が発生した場合は、オペレーションチーム の担当者と上級エンジニア数名が待機し、できるだけ 早く問題を解決するようにします。私が始めたことの ひとつに、チームのジュニアエンジニア1人か2人に メッセージを送ることがあります。「いいかい、誰も オフィスにいないと仮定して、サイトがダウンしたと 仮定して、君しかいないんだ。そして、停電が終わっ た後に、その内容を比較するのです。これは、この種 の問題にどのように対応すべきか、チームの若手メン バーを訓練するための方法なのです。
101. 4.Avoiding Blame
102. John Allspaw 41:46 非難しないこと。 それは本当に基本的なこと のように聞こえます。
103. John Allspaw 41:46 だれかの責任にしない(No fingerpointing)という ルールがありますが、実際にはそれを徹底する必要 はありません。なぜなら、私は、責任の所在を明ら かにする組織に関わることができて非常に幸運だか らです。すぐ近くにいるぞ、行こう行こう。そうそ う、進化した世界での普通の問題のようなものです。
104. John Allspaw 41:46 問題が発生して、ああ、どうしよう？私 はどうすればいいの？もしかしたら変わ るかもしれません。何が起こっているか を人に知られたくないと思っているので ログを削除しようと思うんだけど、どう しよう？とか、鶏の頭を切って、私の コードに基づいてではなく、あなたのマ シンに基づいて、やっとの思いで解明す るんですよ。無駄な時間がやたらと多い んですよね。縄張り意識が物事を解決す る邪魔をしているんだ。
105. John Allspaw 41:46 こうすればいいんじゃないかな？あな たはそれを理解することができます。 あなたは物事を修正することができま す。そして、後でそのことについて罪 悪感を感じたいなら、そうすればいい。 これは一般的に起こることです。私の チームでもPaulのチームでも、「自分 のせいだ」と証明しようとする人が出 てきます。自分のせいで壊れた。だっ て、1日に10回は誰にもわからないん だから。そうすれば、彼らはそれを修 正する人になれると思います。そして、 彼らはそれを修正する男になれるので す。
106. Developers: Remember that someone else will probably get woken up when your code breaks http://www.flickr.com/photos/alex-s/353218851/
107. Paul Hammond 43:23 何か変なことが起きていますね。うん。 John Allspaw 43:28 そうですね。繰り返しになりますが、「開発者 の皆さん、コードを書くときに、誰かが夜中に 目を覚ますかもしれない、ということを忘れな いでください」とおっしゃっていましたね。開 発者を待機させている組織もあります。真夜中 に何かが起こるかもしれないと考えたとき、あ なたが不在であったり、セントマーチン島の感 謝祭に行っていたりしたら、他の人があなたの クソを直してくれるでしょう。他の人があなた のクソを直してくれます。
108. Paul Hammond 43:55 たとえ開発者が待機していたとしても、これが 最初のページであることを知るのは、たいてい 運用チームです。夜中に何かを壊してしまい、 朝になってみると30分もの停電が発生してい て、5人もの人が呼び出されて起こされたのは 自分のせいだったというシナリオがあったとし たら、ただ謝るだけでいいんです。 多くの開発チームが陥りがちなのが、オペレー ションが存在すること、オペレーションが夜中 に起こされて修正してくれることを当てにして いることです。しかし、自分自身に問いかけて みるのもいいでしょう。「もし、誰かが私の不 足分を補ってくれなかったら、私は何か違うこ とをするだろうか？もし自分が夜中に起こされ ていたとしたら、何かを変えるべきだと思いま す。
109. John Allspaw 44:49 Opsは、建設的なフィードバックを提供し、物 事がどのように進んでいるかについて継続的に フィードバックする必要があります。この人た ちは、あなたのビジネスを動かすためにコード を書いているんですよね。そして、より多くの ユーザーを獲得し、地球を征服するために。だ から、彼らは物事がどのように進んでいるかを 知るべきです。不満を言うのではなく、何が起 きているのかを説明して、こう言いましょう。 「ほら、毎朝6時に発生するcronジョブに気づ いたんだ。
110. 1.Automated infrastructure 2.Shared version control 3.One step build and deploy 4.Feature flags 5.Shared metrics 6.IRC and IM robots 1.Respect 2.Trust 3.Healthy attitude about failure 4.Avoiding Blame
111. Paul Hammond 45:32 利用を検討すべき6つのツールと、変更を 検討すべき4つの文化をまとめます。 自動化されたインフラ、 共有されたバージョンコントロール、 ワンステップビルド＆デプロイ、 フィーチャーフラグ、 共有されたメトリクス、 IRCボット、 リスペクト、 信頼、 失敗に対する健全な態度、 責任追及しないこと。
112. This is not easy You could just carry on shouting at each other…
113. John Allspaw 45:56 はっきり言って、これは絶対に簡単な ことではありません。お互いに怒鳴り あい続けることも自由です。お好きに どうぞ。 Paul Hammond 46:07 お忙しい中、 ありがとうございました。