Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

DevOpsDays History and my DevOps story

DevOpsDays History and my DevOps story

a keynote at DavOpsDays Tokyo 2024
https://www.devopsdaystokyo.org/

Yasunobu Kawaguchi

April 17, 2024
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti YesNoBut株式会社 代表取締役社長 アギレルゴコンサルティング株式会社 シニアアジャイルコーチ

    一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
  2. https://newrelic.com/blog/nerd-life/devops-name 2008年8月: トロントで開催されたアジャ イルカンファレンスで、ソフトウェア開発 者のAndrew Shaferが「アジャイルイン フラストラクチャー」と題した「Birds of a Feather」セッションの告知を掲示しま

    す。出席したのはちょうど1人だけでした。 そう、Patrick Deboisです。そして、彼 は会場を独り占めします。自分のトピック に関心がないと思ったAndrew は、自分の セッションをスキップしてしまったので す! 後になって、Deboisは廊下で幅広い会 話をするためにShaferを追いかけます。 彼らの話に基づいて、アジャイルシステム 管理グループを結成します。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  3. https://newrelic.com/blog/nerd-life/devops-name 2009年6月: O'Reilly Velocity 09カン ファレンスにて、John AllspawとPaul Hammondが「1日10回のデプロイ: Flickrにおける開発と運用の協力」と題し た今や有名なトークを行います。遠隔で視

    聴していたDeboisは、直接出席できない ことをTwitterで嘆きます。Paul Nasrat が「なぜベルギーで自分のVelocityイベン トを開催しないのか?」とツイートで返信 します。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  4. https://newrelic.com/blog/nerd-life/devops-name 2009年10月: Deboisはまさにそれを行うこ とを決意しますが、まず名前が必要でした。彼 は開発(development)と運用 (operations)の最初の3文字をとり、そこに 「days」という単語を加え、DevOpsDaysと 名付けました。10月30日、カンファレンスの 扉が開き、開発者、システム管理者、ツールス ミス、その他の人々の印象的な集まりが現れま

    した。カンファレンスが終わると、継続的な議 論がTwitterに移りました。覚えやすいハッ シュタグを作るため、Deboisは名前を #DevOpsに短縮しました。そして、このムー ブメントはその後ずっとDevOpsとして知られ るようになりました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  5. Lindsayは、DevOpsのアイデアをとても気に 入り、オーストラリアのシドニーに持ち帰り、 ダウンアンダーで最初のDevOpsDaysを開催 しました。私自身とAndrew Schaefer、John Willisは一緒になり、Stefan Abbottと LinkedInのDaniel Franciscoの助けを借りて、 2010年版のvelocityの直後に、米国で最初の

    DevOpsDaysを開催しました。しかし、その 間に、もっと興味深いことが起こり始めていま した。これらの初期の対面ミーティングの勢い に火をつけられて、世界中から実践者のコミュ ニティが突然現れ、この新しいDevOpsという 旗印の下で経験を共有し、アイデアを議論し始 めたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  6. これは、ツイートとブログ記事の雪崩の背後に 築かれたオンラインの勢いの継続でした。人々 は自分の経験を共有し、他の人から学んでいた のです。人々が自作の歌のパロディやミュー ジックビデオを作るようになったとき、 DevOpsが生の神経に触れていることは多くの 人にとって明らかになりました。DevOpsは本 格的な草の根運動になったのです。これはかな り稀なことで、当時はベンダーやアナリスト、 伝統的なエンタープライズITショップのほとん

    どに無視されていました。しかし、この運動は、 主にウェブ運用の背景を持つ実践者たちの情熱 によって成長していました。彼らは主に自分の 自由な時間にこれらのトピックについて議論し、 書いていたのです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  7. それに対応して、DevOpsコミュニティは、彼らが求め るベストプラクティスを形式化する新世代のツールを推 進し始めました。これらのツールには、Puppet、Chef、 Vagrant、Juju、Rundeck、LogStash、FPMなどの 楽しい名前がついていました。FPMのFが何を意味する のかは想像するしかありませんが、これらは真剣なツー ルでした。 ほとんどの場合、これらのツールはレガシーツールが提 供できるものを軽々と凌駕していました。コミュニティ にとって、これらは新しいアイデアやプロセスについて

    の考えを形式化する方法であり、より良い働き方を表す 成果物でした。 外部の人にとっては、これらは持っていないと羨ましく なるような光り輝く新しいおもちゃであり、会話に引き 込まれるものでした。しかし、全体的に、これらのツー ルに対する熱意は、初期の活力となりました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  8. すぐに、より洞察力のあるアナリストたちが、ここで何 か面白いことが起こっていることに気づき始めました。 そして、会話に加わるべきだと考えたのです。最初は、 当時Redmonkにいた Michael Cote や、451グループ にいた Jay Lyman

    などでした。その後、Gartner の Cameron Haight などが続きました。Cameron の影響 は興味深いものです。それは微妙ですが、DevOps とエ ンタープライズの関係にとって潜在的に重要な転換点と なる可能性があります。私はこの主張を決定的に証明す ることはできませんが、タイミングは確かに興味深いも のです。2011年3月、Cameron はプレゼンテーション でスライドを紹介しました。それは、エンタープライズ IT ショップとそれにサービスを提供するベンダーに、 DevOps ムーブメントではそれまでほとんど聞かれな かったような強いシグナルを送ったのです。では、 Cameron が何と言ったのかを見てみましょう。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  9. 彼は次のように言いました。「2015年までに、 DevOpsは大規模クラウドプロバイダーが採用 するITストラテジーから、グローバル2000企 業の20%が採用するメインストリームのスト ラテジーに進化するだろう」と。アナリストの 言葉がわからないかもしれませんが、これは大 まかに「DevOpsは本物だ、注目せよ」と訳せ ます。この20%という予測に固執する人もい るかもしれません。あまりに強気すぎるとか、 控えめすぎるとか。しかし、それはポイントで

    はありません。ポイントは、ここに明確なメッ セージがあるということです。つまり、 「DevOpsはエンタープライズに来ている。 DevOpsに乗るんだ」というメッセージです。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  10. それからそれほど経たないうちに、偶然かどう かはわかりませんが、ほとんどすべての大手ベ ンダーがDevOpsという言葉を取り上げ、自社 のメッセージングに組み込み始めました。うま く使いこなしている企業もあれば、的を外して いる企業もあります。しかし、いずれにせよ、 DevOpsはあちこちに登場していて、それは良 いことです。DTOでも、同じ頃にエンタープラ イズの関心が大幅に高まりました。突然、大手 の有名企業が、お洒落なウェブ企業とは程遠い

    ところで、DevOpsに興味を持ち始めたのです。 DevOpsは本当にキャズムを越えて、主流にな る途上にありました。 https://www.youtube.com/watch?v=o7-IuYS0iSE
  11. Agile 2008 での出会い。 2009年のFlickrの発表。 ベルギーで第一回の カンファレンスを行い、 その後 #DevOps が ハッシュタグとして生まれる。

    そして、活動が自然と 広がっていき、 各地でイベントが行われる。 実践者の集まり。 DevOps→Days
  12. DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年)

    を再訪する https://www.youtube.com/watch?v=LdOe18KhtT4
  13. John Allspaw 00:11 皆さん、聞こえていますか?はい。私の名前 はジョン・アルスポー、Flickrのオペレー ショングループを担当しています。 Paul Hammond 00:22 フリッカー社でエンジニアリンググループを

    担当しているポール・ハモンドと申します。 John Allspaw 00:29 今日の話は、実際には様々なトピックを扱う 予定ですが、開発と運用がどのようにフィッ トして仲良くなり、実際に協力して、お互い に大馬鹿者ではないことを説明するための手 段とでも言いましょうか。
  14. Paul Hammond 00:51 しかし、始める前に、Flickrとは何かにつ いて少し話しておきましょう。フリッカー について聞いたことがある人は手を挙げて ください。さて、フリッカーを知らない人 のために説明しますと、 Flickrは写真共有 サイトです。現在、約30億枚の写真を保

    存しています。そして、1日の任意の時点 で、1秒間に約40,000枚の写真を提供し ています。これらの写真は、約6ペタバイ トのストレージを占めています。子猫がた くさんいるように見えるかもしれませんが、 実はとても大きいのです。
  15. 対処中にすべきこと • 全員でゴールをはっきりさせる • 口と手を同時に動かす • 最も重要なことに集中する • できることを一つずつ終わらせる •

    ダメだとわかるのも完了 • なるべく短い時間で進捗を出す • 勝手にヒーローになろうとする人を避ける • 長期の話や改善案は、 あらかじめ時間を決めて行う • ちゃんと休憩する
  16. Paul Hammond 09:35 私たちにはあらゆる種類のツールがあります が、このトークはそれについてではありませ ん。アダムとエズラがもう少し後でそれにつ いてのトークをする予定で、このトピックに ついてはもっと優れたプレゼンテーションが 半ダースほどあります。しかし、ここでの主 なポイントは、OSイメージを持っているとい

    うアイデアがあるということです。そして、 このサーバー、このインフラストラクチャー のピース、またはクラウドのビットが実際に 実行する何らかの役割があります。それはタ スク駆動型のインフラストラクチャーです。
  17. Paul Hammond 09:50 次に紹介するツールは、バージョン管理です。 開発チームの中には、バージョン管理なしで運 用しようとする人はあまりいないでしょう。そ して、ますます多くの運用チームが使うように なっています。 バージョン管理を使うことは、 実際、かつて私たちがやっていたことでもあり

    ます。かつては、 FlickrのソースコードはCVS に格納されていましたが、運用やパッケージ、 構成管理のすべてはPerforceに格納されていま した。そのため、開発者は何が起こっているの かわからず、Perforceのリポジトリをどうやっ てチェックすればいいのかわからず、ジョンは CVSのリポジトリをどうやってチェックすれば いいのかわからなかったのです。
  18. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、 チームの誰もが、どこを見れば特定のボックス用 の設定の最新インスタンスを見つけられるのかを 知ることができ、また、アプリケーションで何が 起こっているのか、どこに変更があるのかを知る ことができます。これは、緊急時には本当に便利 です。先週の金曜日、私は外で食事をしていると

    きに、サイトの一部に問題が発生していることが わかりました。ジョンのチームで働いているケビ ンが私に電話をかけてきたのです。もしソース コードのリポジトリが違っていたら、ケビンがア クセスできなかったかもしれないし、私が家に 帰ってラップトップを取り出し、自分で修正しな ければならなかったでしょう。このように、シン グルソースコントロールは透明性を提供してくれ るので、非常に便利です。
  19. Paul Hammond 09:50 今お見せしているスクリーンショットは、Flickr内部の 開発管理インターフェースの一部です。画面の一番下に ある「ステージングを行う」と書かれたボタンをクリッ クすると、svnチェックアウトが行われ、すべての翻訳、 すべてのテンプレートのコンパイル、最適化のためのコ ンパイルなどが行われます。そして、そのコードをス テージング・サーバーにコピーして、テストできるよう

    にします。 John Allspaw 12:07 自動的に自動的に、つまり、人がこのコマンドを実行し ていないのに、このコマンドを実行するのです。結論か ら言うと、コンピュータはコマンドを同時に実行するの がとても得意で、何度も同じ順番で実行されます。
  20. Paul Hammond 12:20 そして、下部には「I'm feeling lucky」というボタンがあり、これを押 すとコードがサイトにプッシュされま す。これは、コードをサイトにプッ シュしているときの様子です。ここで も同じ原則が当てはまります。ボタン

    を1つにすることで、エラーの余地が非 常に少なくなります。つまり、一貫し た環境でビルドとデプロイを行うこと ができ、間違える可能性のある手動の 手順がないことを意味します。
  21. Paul Hammond 14:45 リビジョン管理のブランチングシステムについて 考えると、それはデスクトップソフトウェアを構 築する現実への対応です。あなたはマイクロソフ トで、Microsoft Wordを開発し、Microsoft Word 1.0をリリースしました。そして、開発

    チームはすぐにMicrosoft Word 1.1の開発に取 りかかります。そして、1.1をリリースします。 そして数日後、重大なセキュリティの脆弱性があ ることに気づきます。そこで、1.0のコードベー スに戻って変更を加え、それを出荷しなければな りません。そして、1.2をリリースします。そし て、もう一度変更を加えなければなりません。つ まり、3つの異なるバージョンのソフトウェアを 同時にリリースしているのです。
  22. Paul Hammond 14:45 SVNではブランチングを行わないと言い ましたが、その代わりにコードでブランチ ングを行います。つまり、すぐにリリース しない機能を開発する際は、条件文を使っ てそれらの特定のコードパスをブロックす るのです。 ここにPHPの例があります。smartyの例

    です。実際にはまだリリースされていない すべての新機能のコードを、本番サーバー の本番環境に置くことができるのです。た だ、設定が行われているので、まだ実際に は見えないだけなのです。
  23. Paul Hammond 18:11 これにより、いくつかの本当に素晴らしいトリックが できるようになります。1つ目は、本番サーバー、本 番ハードウェア、本番トラフィックでプライベート ベータを行えるということです。もちろん、私たちに は非常にリアルなテストができる素晴らしいステージ ング環境があります。そして、それらの環境で多くの QAを行っています。しかし、私たちが発見したことは、

    テストに別のサーバーセットを使用すると、ベータ サーバーと本番サーバーの間の設定の変更に気づかな い可能性があるということです。構成管理を使用して いても、それは起こります。過去には、新しい機能が ベータサーバーで完璧に動作していたのに、本番環境 に移行した途端、依存していたバックエンドの内部 Webサービスが本番のWWWからブロックされている ことに気づいたケースがありました。そのため、その 機能は動作せず、そのバックエンドWebサービスに緊 急の変更要求を出さなければなりませんでした。
  24. Paul Hammond 18:11 最後に、Jonathan がさきほど Facebook について話したときに言及した、ダーク ローンチ(水面下でのローンチ)ができま す。新しい機能を舞台裏でローンチするの です。memcached

    ボックス、データベー スサーバー、検索クラスターに負荷がかか る新しい機能がある場合、その機能を舞台 裏でオンにして、数週間データを取得し始 めますが、そのデータは表示しません。そ して、実際にこの新しい機能をローンチす る頃には、数週間負荷をかけていたので、 負荷に耐えられることがわかっているので す。
  25. John Allspaw 21:12 私たちは数百のフラグを持っているので、物事をオ フにしたり、サイトの可用性やパフォーマンスに影 響を与えている物事の動作を変更したりできます。 データベースクラスターに何らかの劣化があったり、 他のバックエンドサービスに何らかの劣化があり、 それが特定の機能に関連している場合、私たちはこ れを変更できます。そして、サイトに影響を与える

    ことなく、ロールバックするのでしょうか。実際に はそれほど頻繁ではありません。私たちがするのは、 前に進んで、それをオフにすることです。 これらのフィーチャーフラグの中には、オンとオフ だけでなく、ポールが言ったように、可変量を持つ ノブのようなものもあります。
  26. Paul Hammond 24:10 これは、私たちの非同期タスクキューにあるバック グラウンドタスクの数を示すグラフです。興味深い ことの1つは、実際に私がこのグラフに表示されて いるメトリクスを作成したことです。 そして、私がこのグラフを作成した理由の1つは、 ジョンのチームに頼まれたからではなく、私たちの オフラインタスクシステムがどのように機能してい

    るかを知りたかったからです。ここで興味深いのは、 開発者がこれらの伝統的に運用上のメトリクスを作 成したいと考えているという状況があることです。 そして、ジョンのチームは、私たちがそれを簡単に 作成できるようにしてくれます。私たちは今、アプ リケーションのどの部分でもキーと値のペアを含む ファイルを書き込むだけで、Gangliaの設定がそれ を取り込み、私たちのために美しいグラフを作成し てくれるフレームワークを持っています。
  27. Paul Hammond 24:10 これは、アプリケーションの中に適応型フィード バックループを作成することにつながります。非 同期に発生している事柄がある場合、システムが うまく機能していないときに、アプリケーション がバックオフしてシステムへの負荷を軽減しよう とすることができます。先ほど述べたオフライン タスクセントリズムは、データベースが過負荷に

    なり始めると実際に調整されて、データベースが リアルタイムの負荷に対処できるようにします。 オフラインタスクを10分後に実行する必要が あっても、それは大した問題ではありません。 そして、Yahoo PhotosからFlickrへの移行を 行った際には、ストレージの空き容量に基づいて スロットリングを行い、ストレージが不足しない ようにしました。
  28. John Allspaw 27:24 実際に、私たちが持っている全てのメトリクス の全てのページに、最後のサイトデプロイの時 間を記載しています。 Paul Hammond 27:35 そして、これによって、特定のグラフが2倍に

    なったり半分になったりした理由を簡単に特定 できることがよくあります。これは、私のチー ムの1人が画像処理コードの最適化をロールア ウトした例です。私たちはそれがどのような効 果をもたらすかわかりませんでしたが、少しの 効果があるかもしれないと考えていました。し かし、結果はかなり大きなものでした。
  29. John Allspaw 27:58 コンピューター駆動のイベントをIRCのストリー ムに送り込みます。例えば、私たちが本当に気に している特定のアラートとモニター、ビルドログ、 何かがデプロイされたときのデプロイログなどで す。(中略) そこで私たちが実際に行っていることは、このロ グ情報のすべてを取得して、検索エンジンに突っ

    込むことです。そうすれば、「2ヶ月前の木曜日に 一体何をしたのか、何が起こっていたのか、この 問題を以前に見たことがあるか」などと言うこと ができます。 これは本当に役立ちます。なぜなら、人間がコン テキストを持つことができるからです。 ※IRC(Internet Relay Chat)は、 1990~2010年くらいまで 主流だったオンライン チャットプロトコル。
  30. Paul Hammond 35:25 そして、開発チームは、運用担当者が事前にイ ンフラストラクチャーの変更について彼らと話 し合ってくれることを信頼する必要があります。 PHPがPHP 5にアップグレードされたことを、 それが起こった翌日に知ることはないでしょう。 繰り返しになりますが、これは本当に明らかに

    すべきことのように思えます。しかし、私は過 去に本当に機能不全なチームで働いたことがあ り、そこではこれが必要不可欠なものとして受 け入れられていませんでした。そして、それは、 組織全体のために皆が最善を尽くそうとしてい ることを、全員が信頼することに戻ってきます。
  31. Paul Hammond 35:25 この会話が確実に行われるようにするために私 たちが実践していることは、可能な限り、共有 ランブックと共有エスカレーション計画を作成 するよう努めることです。 つまり、ジョンと私、あるいは私たちのチーム のメンバーが一緒に座って、新しい機能がオペ レーション上どのようにサポートされるかを正

    確に把握します。どのようなシナリオで問題が 発生する可能性があるのか? それらを修正す るために誰が関与する必要があるのか? そし て、それは単に、リスクは何か、不測の事態は 何かについての会話を強制し、全員が同意して いることを確認するのです。
  32. John Allspaw 36:57 開発者が監視し、注視するためのノブとレバー、つ まり、開発者が苦労して作ったコードを監視するた めのノブとレバーを提供することについて、私たち は言い過ぎることはできません。そして、開発者は フックとノブとレバーを書いて、これらのものを運 用可能にします。 Paul

    Hammond 37:20 コードを塀の向こうに投げ込むだけでは不十分で、運 用担当者が変更できないように、全ての変数に関する 全ての前提条件をプリコンパイルしておく必要があり ます。20個の子プロセスを持つことが良い数だと思う なら、運用担当者が設定できるようにする必要があり ます。そうすれば、下層のハードウェアをアップグ レードした場合に、運用担当者は自分たちでそれを実 行できます。
  33. Paul Hammond 40:13 しかし、それでも、何かが上手くいかない 時のために手順を作成し、避難計画などを 立てています。 一つの考え方は、もしサイトの停止に直面 しているなら、つまり、何らかの医療上の 問題を抱えているなら、年に一度心臓発作 に対処するEMT(救急隊員)に治療しても

    らいたいですか?それとも、数週間ごとに 心臓発作に対処するEMTに対処してもらい たいですか?あなたの運用チームと開発 チームの両方で育成する必要があるものの 一つは、問題に迅速かつ効果的に対応する 能力です。
  34. John Allspaw 44:49 運用担当者は、物事がどのように進んでいるかに ついて、建設的なフィードバック、継続的な フィードバックを提供すべきです。これらの人々 は、あなたのビジネスを運営し、より多くのユー ザーを獲得し、世界を支配するためにコードを書 いているのです。だから、物事がどのように進ん でいるか知るべきです。文句を言わないでくださ

    い。彼らに何が起こっているのかを説明して、 「ほら、毎朝6時に実行されるこのcronジョブは、 そこまで大したことではないけど、でも...」と 言ってください。彼らに説明してください。あら ゆる種類のメトリクスがあります。あなたが見た いものも、彼らが見たいものも。情報を共有する だけです。