無印吉澤 Site Reliability Engineering(SRE)、ソフトウェア開発、クラウドコンピューティングなどについて、吉澤が調べたり試したことを書いていくブログです。 2022-12-24T11:08:36+09:00 muziyoshiz Hatena::Blog hatenablog://blog/8454420450087952872 WEB+DB PRESS Vol.132「コンテナ化実践ガイド」はこれからコンテナ化する人必読の記事(のつもりで書きました) hatenablog://entry/4207112889944956230 2022-12-24T11:08:36+09:00 2022-12-24T11:08:36+09:00 本日12/24発売のWEB+DB PRESS Vol.132に、私が執筆した「コンテナ化実践ガイド」が掲載されました! 今までいろいろ文章を書いてきましたが、実は、書店に並ぶ雑誌に記事を書いたのは初めてです。ドキドキしながら発売日を待ってました。 gihyo.jp ちなみに、電子版がほしい方はGihyo Digital PublishingのEPUB/PDFセットがおすすめです。 gihyo.jp 想定する読者は? 歴史の長いシステムで、モノリシックなアプリケーションを開発・運用している方に向けて、コンテナ化を進めるためのステップを具体的に解説したガイドです。 ここまで具体的に(悪く言えば泥臭… <p>本日12/24発売のWEB+DB PRESS Vol.132に、私が執筆した「コンテナ化実践ガイド」が掲載されました! 今までいろいろ文章を書いてきましたが、実は、書店に並ぶ雑誌に記事を書いたのは初めてです。ドキドキしながら発売日を待ってました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgihyo.jp%2Fmagazine%2Fwdpress%2Farchive%2F2023%2Fvol132" title="WEB+DB PRESS Vol.132" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://gihyo.jp/magazine/wdpress/archive/2023/vol132">gihyo.jp</a></cite></p> <p>ちなみに、電子版がほしい方は<a href="https://gihyo.jp/dp">Gihyo Digital Publishing</a>のEPUB/PDFセットがおすすめです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgihyo.jp%2Fdp%2Febook%2F2022%2F978-4-297-13246-0" title="WEB+DB PRESS Vol.132 | Gihyo Digital Publishing … 技術評論社の電子書籍" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://gihyo.jp/dp/ebook/2022/978-4-297-13246-0">gihyo.jp</a></cite></p> <h2 id="想定する読者は">想定する読者は?</h2> <p>歴史の長いシステムで、モノリシックなアプリケーションを開発・運用している方に向けて、コンテナ化を進めるためのステップを具体的に解説したガイドです。</p> <p>ここまで具体的に(悪く言えば泥臭いことを)説明している資料は、少なくとも僕は見たことがないので、これからコンテナ化に着手する人には必ず役立つと思います。「うちのシステムをコンテナに乗せて、本当に動くのか……?」と悩んでいる方に是非読んでほしいです。<strong>僕がBacklogのコンテナ化に着手する前に読みたかった記事</strong>を目指しました。</p> <p>また、「絶対コンテナ化しなきゃ駄目!」とは書いていなくて、こういう場合はコンテナ化以外の改善をしたほうがいい、という話もしているのでご安心ください。</p> <p>逆に、「モダンなアプリケーション開発をしているから、なにも苦労しなくてもコンテナに乗りますよ」という方にとっては、この記事のガイドは過剰かと思います。まあ、最近だと、そういう方は最初からコンテナを使ってますよね……。</p> <h2 id="どういう記事なの">どういう記事なの?</h2> <p>以下の全5章で構成されています。1章で、この記事で言う「コンテナ化」とはなにかを丁寧に説明してから、2〜5章でコンテナ化の具体的な進め方や、ありがちな落とし穴を説明しています。</p> <ol> <li>あなたのシステムにコンテナ化は必要か?</li> <li>コンテナ化の計画を立てる</li> <li>アプリケーションを改善する</li> <li>アプリケーションをコンテナで動作させる</li> <li>本番環境にリリースする</li> </ol> <p>この記事では、僕がBacklogのコンテナ化を実際に行った際の経験から、コンテナ化プロジェクトを以下の4つのフェーズに分けました。2〜5章は、これらの各フェーズに対応しています。</p> <p><figure class="figure-image figure-image-fotolife" title="コンテナ化プロジェクトを構成する4つのフェーズ"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20221214/20221214115554.png" alt="&#x8A08;&#x753B;&#x30D5;&#x30A7;&#x30FC;&#x30BA;&#x3001;&#x6539;&#x5584;&#x30D5;&#x30A7;&#x30FC;&#x30BA;&#x3001;&#x30B3;&#x30F3;&#x30C6;&#x30CA;&#x5316;&#x30D5;&#x30A7;&#x30FC;&#x30BA;&#x3001;&#x30EA;&#x30EA;&#x30FC;&#x30B9;&#x30D5;&#x30A7;&#x30FC;&#x30BA;" width="820" height="200" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>コンテナ化プロジェクトを構成する4つのフェーズ</figcaption></figure></p> <p>1〜2章を読んでもらえれば、僕が考えるコンテナ化プロジェクトの進め方は理解してもらえると思います。3〜5章はさらに具体的な話になるので、実際にコンテナ化することになったら読む、というのでもOKです。</p> <h2 id="Backlogのコンテナ化って">Backlogのコンテナ化って?</h2> <p>僕はヌーラボという会社で、<a href="https://backlog.com/ja/">Backlog</a>というプロジェクト管理ツールのSREを5年以上担当してきました。</p> <p>Backlogには、そのトラフィックの約9割を処理するモノリシックなWebアプリケーションがあるのですが、以前はこれがEC2インスタンス上で動いていました。このアプリをコンテナ化するプロジェクトを2021年4月〜2022年8月に実施し、現在はAmazon EKS上で動いています。</p> <p>このプロジェクトは本当に最後の最後まで、未知の問題が発生するんじゃないかとビクビクしながら進めました。コンテナ化を進めていくうちに、既存のアプリケーションの問題がいくつも新たに見つかり、上記のフェーズ分けを当てはめるなら「改善フェーズ」がどんどん伸びていって、これは本当に無事に終わるのかと……。</p> <p><figure class="figure-image figure-image-fotolife" title="コンテナ化フェーズの前に終わると思っていた改善フェーズがどんどん伸びていく様子"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20221214/20221214121218.png" alt="&#x6539;&#x5584;&#x30D5;&#x30A7;&#x30FC;&#x30BA;&#x306E;&#x7D42;&#x4E86;&#x6642;&#x671F;&#x304C;&#x30B3;&#x30F3;&#x30C6;&#x30CA;&#x5316;&#x30D5;&#x30A7;&#x30FC;&#x30BA;&#x306E;&#x7D42;&#x4E86;&#x6642;&#x671F;&#x307E;&#x3067;&#x4F38;&#x3073;&#x3066;&#x3044;&#x308B;" width="1000" height="500" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>コンテナ化フェーズの前に終わると思っていた改善フェーズがどんどん伸びていく様子</figcaption></figure></p> <p>しかし、そんなプロジェクトも無事に終わり、いまはBacklogを構成するその他の細かいアプリケーションサーバのコンテナ化を進めています。それらの活動から得られた知見をもとに、今回のWEB+DB PRESSの記事を執筆しました。</p> <p>WEB+DB PRESSの記事では、このBacklogのコンテナ化自体については詳しく触れていないので、もしご興味のある方は<a href="https://sre-next.dev/2022/schedule#jp20">SRE NEXT 2022</a>の<a href="https://speakerdeck.com/nulabinc/sre-next-2022">発表スライド</a>や<a href="https://youtu.be/w69iWW8-YX0">発表動画</a>をご覧ください。</p> <script async class="speakerdeck-embed" data-id="5791ad731ac742d19ab229ce2379c21a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <iframe width="560" height="315" src="https://www.youtube.com/embed/w69iWW8-YX0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <h2 id="執筆のきっかけとSRE-LoungeSRE-NEXTへの感謝">執筆のきっかけとSRE Lounge/SRE NEXTへの感謝</h2> <p>今回のコンテナ化実践ガイドは、今年5月のSRE NEXT 2022の発表をきっかけに、技術評論社の池田さんからお声がけいただいて書くことになりました。SRE Lounge/SRE NEXTのようなSREのための情報共有の場は貴重だと思い、長い間スタッフとして参加してきましたが、今回はその貴重さを改めて強く実感しました。スタッフの皆さんいつもありがとうございます。</p> <p>ちなみに、池田さんから最初にお声がけいただいたのは6月だったのですが、そのときはまだコンテナ化が終わっていませんでした。コンテナ化が無事に終わってから企画会議でOKをもらって書き始めて、12月の雑誌掲載となりました。</p> <p>昔、研究者だった頃は、こういう雑誌に記事を書けるくらいの有識者になりたいと思ってたものですが、そんなことをすっかり忘れた今になってお声がけいただいてビックリしました。人生なにがあるかわからないもんですね……。</p> <h2 id="ちなみに">ちなみに</h2> <p>このブログ記事は<a href="https://adventar.org/calendars/7996">ヌーラバーブログリレー2022</a>の24日目でした。最終日となる明日はAya Yoshidaさんの担当です。そちらもお楽しみに!</p> muziyoshiz ヌーラボ在籍時に書いたブログ記事&プレゼン資料まとめ hatenablog://entry/26006613802143321 2021-08-28T15:48:59+09:00 2023-02-28T10:15:45+09:00 2017年8月〜2023年2月のヌーラボ在籍時に、SRE 関係のブログ記事やプレゼン発表をいろいろ行いました。徐々に SRE メンバーが増えていくフェーズで入社したため、特に SRE の組織に関する話を多く書きました。 それらの記事がヌーラボブログとBacklog ブログとこの個人ブログに散らばってしまっていて、自分でも探すのが大変になってしまったのでここにまとめておきます。 目次 目次 入社直後 2015 〜 2018 年の Backlog SRE チームの変遷 Backlog Play 化プロジェクト Backlog の課題検索機能のリプレイスプロジェクト Amazon Linux 2 へ… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191230/20191230205919.png" width="680" height="357" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <p>2017年8月〜2023年2月のヌーラボ在籍時に、SRE 関係のブログ記事やプレゼン発表をいろいろ行いました。徐々に SRE メンバーが増えていくフェーズで入社したため、特に SRE の組織に関する話を多く書きました。</p> <p>それらの記事が<a href="https://nulab.com/ja/blog/">ヌーラボブログ</a>と<a href="https://backlog.com/ja/blog/">Backlog ブログ</a>とこの個人ブログに散らばってしまっていて、自分でも探すのが大変になってしまったのでここにまとめておきます。</p> <h2 id="目次">目次</h2> <ul class="table-of-contents"> <li><a href="#目次">目次</a></li> <li><a href="#入社直後">入社直後</a></li> <li><a href="#2015--2018-年の-Backlog-SRE-チームの変遷">2015 〜 2018 年の Backlog SRE チームの変遷</a></li> <li><a href="#Backlog-Play-化プロジェクト">Backlog Play 化プロジェクト</a></li> <li><a href="#Backlog-の課題検索機能のリプレイスプロジェクト">Backlog の課題検索機能のリプレイスプロジェクト</a></li> <li><a href="#Amazon-Linux-2-への移行プロジェクト">Amazon Linux 2 への移行プロジェクト</a></li> <li><a href="#インシデント対応のセルフサービス化">インシデント対応のセルフサービス化</a></li> <li><a href="#モノリシックアプリケーションのコンテナ化">モノリシックアプリケーションのコンテナ化</a><ul> <li><a href="#SRE-NEXT-2022での発表">SRE NEXT 2022での発表</a></li> <li><a href="#プロジェクト完了後の情報発信">プロジェクト完了後の情報発信</a></li> </ul> </li> </ul> <h2 id="入社直後">入社直後</h2> <p>入社前から<a href="https://muziyoshiz.hatenablog.com/archive/category/Wiki">Wiki に関する記事</a> をいろいろ書いてきた関係で、入社直後の研修で<a href="https://backlog.com/ja/wiki-guide/">サル先生の Wiki 入門</a>(旧:サルでもわかる Wiki 入門)を執筆し、このサイトのインフラ構築もしました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fnulab%2Fwiki-guide%2F" title="チームの情報共有を Wiki でもっと円滑に。解説&ハンズオン形式の入門サイト「サルでもわかる Wiki 入門」を公開しました! | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/nulab/wiki-guide/">nulab.com</a></cite></p> <p>その後は、徐々に SRE 業務に慣れていったのですが、その時期に行った改善についての記事も書いてます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fnulab%2Fencrypt-aws-access-key-with-ansible-vault%2F" title="Gitリポジトリ上でAWSアクセスキーを大公開しないためにAnsible Vaultをフル活用する | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/nulab/encrypt-aws-access-key-with-ansible-vault/">nulab.com</a></cite></p> <p>他には、<a href="https://developer.cybozu.io/hc/ja/articles/360001062323-kintone-devCamp-2018">kintone devCamp 2018</a> や <a href="https://mackerelio.connpass.com/event/106805/">Mackerel Drink Up #8</a> でプレゼンをさせてもらう機会がありました。</p> <script async class="speakerdeck-embed" data-id="4697db202d974338b637e07267901c2a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <script async class="speakerdeck-embed" data-id="1f95815eb02948afacd64af6355db33b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <h2 id="2015--2018-年の-Backlog-SRE-チームの変遷">2015 〜 2018 年の Backlog SRE チームの変遷</h2> <p>SRE としての働き方が落ち着き、SRE 組織のあり方について考えるようになった頃に、<a href="https://sre-lounge.connpass.com/event/99389/">SRE Lounge #5</a> で発表をさせてもらいました。自分の入社前のことについては、間違った情報を発信してしまわないように、僕の入社前からいたメンバーに何度もヒアリングさせてもらいました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F09%2F27%2F234149" title="SRE Lounge #5 にて Backlog における SRE の事例について講演しました - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/09/27/234149">muziyoshiz.hatenablog.com</a></cite></p> <script async class="speakerdeck-embed" data-id="029f41f30c92426c97c0461e10351568" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>また、SRE Lounge #5 では時間の都合で話しきれなかったサービスレベル計測の話題についても、別の記事にまとめました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fbacklog%2Fbacklog-sre-service-level-management%2F" title="サービス品質向上のためにBacklogのSREが行ってきたサービスレベル管理の取り組み | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/backlog/backlog-sre-service-level-management/">nulab.com</a></cite></p> <p>ちなみに、この SRE 組織のあり方については、SRE lounge #5 の発表後に少し考え方が変わりました。そのことはまた別の記事にまとめています。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F12%2F30%2F210707" title="2019 年に SRE をしながら考えが変わったこと - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/12/30/210707">muziyoshiz.hatenablog.com</a></cite></p> <h2 id="Backlog-Play-化プロジェクト">Backlog Play 化プロジェクト</h2> <p>2018年4月から2019年7月まで、<a href="https://backlog.com/ja/blog/the-story-of-large-scale-replacement-with-play-framework-over-4-years/">Backlog を Java &amp; Tomcat から Scala &amp; Play Framework に移行する大規模なリプレイスプロジェクト</a>に参加していました。このプロジェクトからは色々な気付きが得られて、多くの改善を行いました。それらを2回のブログ記事に分けて書きました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fhow-sre-resolved-the-problems-on-large-scale-replacement-with-play-framework%2F" title="SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/how-sre-resolved-the-problems-on-large-scale-replacement-with-play-framework/">backlog.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fon-call-system-for-backlog-developers%2F" title="Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/on-call-system-for-backlog-developers/">backlog.com</a></cite></p> <h2 id="Backlog-の課題検索機能のリプレイスプロジェクト">Backlog の課題検索機能のリプレイスプロジェクト</h2> <p>Play 化プロジェクト以降は、改善プロジェクトでプロマネをしながら手を動かす、という働き方が増えました。これはその最初のプロジェクトでした。</p> <p>このプロジェクトでは、いろいろな課題があった Backlog の課題検索機能を、Amazon Elasticsearch Service を使った新しい実装にリプレイスしました。ステートフルな Backlog アプリケーションをステートレスにし、将来的なマイクロサービス化を可能にするためのプロジェクトでした。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fcase-of-sre-featuring-issue-search-replacement%2F" title="SREの活動事例紹介 〜 Backlogのマイクロサービス化に向けた課題検索機能のリプレイス | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/case-of-sre-featuring-issue-search-replacement/">backlog.com</a></cite></p> <p><a href="https://nucon.nulab.com/2020/">NuCon 2020</a> でも、このリプレイスプロジェクトと、プロジェクト後の継続的な改善について話しました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fnulab%2Fhow-nulab-sres-improve-long-lived-products%2F" title="ヌーラボのSREは歴史の長いプロダクトをどのように改善しているか? #ヌーラボのアドベントカレンダー | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/nulab/how-nulab-sres-improve-long-lived-products/">nulab.com</a></cite></p> <script async class="speakerdeck-embed" data-id="e764e4f44ea647c2925e84dc9bbd02a8" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>技術面では、Amazon Elasticsearch Service の認証・認可まわりにすごく悩まされて、ついカッとなって個人ブログにまとめたりしました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F11%2F30%2F144213" title="Amazon Elasticsearch Service の認証・認可に関する面倒くさい仕様をなるべくわかりやすく説明する - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/11/30/144213">muziyoshiz.hatenablog.com</a></cite></p> <h2 id="Amazon-Linux-2-への移行プロジェクト">Amazon Linux 2 への移行プロジェクト</h2> <p>2020年は主に、Backlog のたくさんあるサーバをすべて Amazon Linux 2 に移行するプロジェクトを進めていました。技術的な新しさは少ないのでどうまとめようか悩んだ結果、プロジェクトの進め方に焦点を当ててブログ記事を書きました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fbacklog%2Famazon-linux-2-migration%2F" title="歴史の長いプロダクトでAmazon Linux 2への移行をやり遂げた話 | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/backlog/amazon-linux-2-migration/">nulab.com</a></cite></p> <h2 id="インシデント対応のセルフサービス化">インシデント対応のセルフサービス化</h2> <p><a href="https://backlog.com/ja/blog/on-call-system-for-backlog-developers/">Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム</a> からのさらなる改善事例として、「インシデント指揮者」としての役割を開発チームに引き継ぐための活動について書きました。SRE 本および SRE ワークブックを参考に、「インシデント対応チェックリスト」というものを考案し、2021年7月から導入しました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fbacklog%2Fincident-response-checklist%2F" title="開発チームをインシデント対応に慣れさせてくれる「インシデント対応チェックリスト」の導入 | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/backlog/incident-response-checklist/">nulab.com</a></cite></p> <h2 id="モノリシックアプリケーションのコンテナ化">モノリシックアプリケーションのコンテナ化</h2> <h3 id="SRE-NEXT-2022での発表">SRE NEXT 2022での発表</h3> <p>2021年からは、今までの改善活動の集大成として、Backlog のコンテナ化および Amazon EKS への移行に取り組みました。色々な問題に苦しめられたのですが、約1年かけて解決することができたため、その問題解決の経緯をまとめて <a href="https://sre-next.dev/2022/">SRE NEXT 2022</a> にて発表しました。</p> <p><a href="https://sre-next.dev/2022/schedule#jp20">長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか?(SRE NEXT 2022オフィシャルサイト)</a></p> <blockquote><p>ヌーラボのプロジェクト管理ツール“Backlog”のWebアプリケーション部分は、モノリシックアプリケーションとして開発されてきました。Backlog SREは、開発効率の改善などを目的として、このアプリをAmazon EKSに移行するためのコンテナ化を進めています。 10年以上開発されてきたモノリシックアプリケーションをコンテナ化するにあたり、運用を考慮すると、アプリ自体を改修しなければ解決できない問題がいくつも見つかりました。 この講演では、自社アプリのコンテナ化を検討している方に向けた事例情報として、このコンテナ化プロジェクトで私達が遭遇した問題とその解決方法をご紹介します。また、コンテナ化の完了に向けた今後の計画と、コンテナ化の先に見据える理想像についてもお話しします。</p></blockquote> <script async class="speakerdeck-embed" data-id="5791ad731ac742d19ab229ce2379c21a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <iframe width="560" height="315" src="https://www.youtube.com/embed/w69iWW8-YX0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <h3 id="プロジェクト完了後の情報発信">プロジェクト完了後の情報発信</h3> <p>SRE NEXT 2022の発表時点ではまだEC2インスタンスからコンテナへと切り替えている最中だったのですが、2022年7月にコンテナへの切り替えおよびEC2インスタンスの削除が無事完了しました。このコンテナ化プロジェクトで得られた知見を、以下のブログ記事で発信しました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fbacklog%2Fgraceful-shutdown-of-kubernetes-application%2F" title="Amazon EKS上でアプリケーションをGraceful Shutdownさせる際に注意すべきポイント | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/backlog/graceful-shutdown-of-kubernetes-application/">nulab.com</a></cite></p> muziyoshiz AWSの薄い本シリーズ(IAMのマニアックな話など)の読書メモ hatenablog://entry/26006613672283619 2020-12-31T13:40:27+09:00 2020-12-31T13:40:27+09:00 年明けから IAM 周りの整理をいろいろしなければいけなくなったので、佐々木拓郎さんの「AWSの薄い本」シリーズ2冊を読みました。今回はその読書メモです。 booth.pm booth.pm AWS は普段から使っているので、IAM の基本的な機能はもちろん知っているのですが、最近追加された機能(特にマルチアカウント管理に関する機能)については全然追えてなかったので勉強になりました。 以下、勉強になった点をまとめたメモです。AWS の情報は日々変わっていってしまうので、発行日も併せて記載しました。 AWSの薄い本 IAMのマニアックな話(発行日:2019年9月22日) 第1章 AWSとIAM … <p>年明けから IAM 周りの整理をいろいろしなければいけなくなったので、佐々木拓郎さんの「AWSの薄い本」シリーズ2冊を読みました。今回はその読書メモです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbooth.pm%2Fja%2Fitems%2F1563844" title="AWSの薄い本 IAMのマニアックな話 - 佐々木拓郎のオンライン本屋 - BOOTH" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://booth.pm/ja/items/1563844">booth.pm</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbooth.pm%2Fja%2Fitems%2F1919060" title="AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー - 佐々木拓郎のオンライン本屋 - BOOTH" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://booth.pm/ja/items/1919060">booth.pm</a></cite></p> <p>AWS は普段から使っているので、IAM の基本的な機能はもちろん知っているのですが、最近追加された機能(特にマルチアカウント管理に関する機能)については全然追えてなかったので勉強になりました。</p> <p>以下、勉強になった点をまとめたメモです。AWS の情報は日々変わっていってしまうので、発行日も併せて記載しました。</p> <h2>AWSの薄い本 IAMのマニアックな話(発行日:2019年9月22日)</h2> <h3>第1章 AWSとIAM</h3> <ul> <li>AWS Organizations は本書の対象外</li> <li>ポリシー記述の文法的な部分は本書では扱わない。詳細は公式の<a href="https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies.html">IAM JSON ポリシーのリファレンス</a> を参照</li> </ul> <h3>第2章 IAMの機能</h3> <ul> <li>IAMの機能のうち、まず次の5つの機能の認知と理解をしておくことが重要 <ul> <li>IAM ユーザー</li> <li>IAM グループ</li> <li>IAM ポリシー</li> <li>IAM ロール</li> <li>パーミッション・バウンダリー</li> </ul> </li> <li>アクセスキーの発行は原則しないほうがいい。必要になったときに最小の権限で発行する</li> <li>IAMユーザーに権限を直接付与こともできるが、管理上の複雑さが増すので、IAMグループで管理することを推奨</li> <li>管理ポリシーとインラインポリシー <ul> <li>インラインポリシーは管理ポリシーができる前の古い機能</li> <li>AWSが最初から設定しているポリシーをAWS管理ポリシー(AWS Managed Policies)、各ユーザーが独自に作成したポリシーをカスタマー管理ポリシー(Customer Managed policies)と呼ぶ</li> <li>AWS管理ポリシーで大まかな権限を足した後、不要な権限をカスタマー管理ポリシーで引く</li> </ul> </li> <li>Permissions Boundary(パーミッション・バウンダリー) <ul> <li>2018年7月に登場した、IAMの移譲権限を制限する機能</li> <li>他者にIAMユーザーやIAMロールを貸与する際に、それらが持つ権限の一部(パーミッション・バウンダリーで設定した権限)しか使えない状態にすることができる</li> </ul> </li> </ul> <h3>第3章 IAMチュートリアル</h3> <ul> <li>Condition で aws:SourceIp を指定するときに、プライベート IP の範囲を指定しても意味がない。VPC 内のリソースを制限するには VPC ID もしくは VPC Endpoint ID を指定する必要がある(6章)</li> <li>IAM ポリシーの基本的な動作は「明示的な Deny > 明示的な Allow > 暗黙的な Deny(デフォルト)」</li> <li>クロスアカウントロール(IAM ロール)を使って、設定変更時のみ、変更権限を持つ IAM ロールにスイッチする例 <ul> <li>スイッチ元は sts:AssumeRole で制限</li> <li>Principal に、IAM グループでの指定はできない</li> </ul> </li> </ul> <h3>第4章 IAMポリシーのデザインパターン</h3> <ul> <li>ホワイトリストパターン <ul> <li>最小権限を付与するのに適している</li> <li>事前に役割を決めて権限を付与するため、探索的な開発の場合には効率が悪くなる</li> <li>本番環境、かつ高いセキュリティを求められるエンタープライズ向け</li> </ul> </li> <li>ブラックリストパターン <ul> <li>禁止事項のみを定義すればよいので、IAM ポリシーの設計・設定が最小で済む</li> <li>AWS に新しいサービスが始まると、予期せぬ機能が突然使えるようになる</li> <li>探索的な開発環境、もしくは比較的大きな権限が必要な管理者向け</li> </ul> </li> <li>ハイブリッド・パターン <ul> <li>AWS の定義済みのポリシーと、自分で作ったブラックリストを組み合わせて利用することで、最小の労力で実用的なポリシーを作ることができる</li> <li>組み合わせに使われる個々のポリシーは、シンプルに作ることができる</li> </ul> </li> </ul> <h3>第5章 IAMグループのデザインパターン</h3> <ul> <li>以下の2つのパターンが考えられるが、機能的な優劣はない <ul> <li>ユーザーが複数グループに所属し、グループ間のポリシーの重複はないパターン</li> <li>ユーザーが1つのグループに所属し、グループ間でポリシーの重複があるパターン</li> </ul> </li> <li>IAMグループは、path オプションを使って階層構造を表現できるが、権限の継承のような機能はない</li> </ul> <h3>第6章 IAMとセキュリティ</h3> <ul> <li>AWS が公開している <a href="https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html">IAM のベストプラクティス</a></li> <li>特権ユーザーに関わらず、すべての IAM ユーザーに対して MFA の有効化を原則にすべき</li> <li>ユーザー自身のパスワードと MFA の設定を許可する例 <ul> <li><code>${aws:username}</code> は IAM ポリシーエレメントと呼ばれる変数で、ログインしている IAM ユーザー名に置き換えられる</li> <li>AWS アカウント ID の変数は、IAM ポリシーエレメントに無い。代わりに、CloudFormation の疑似パラメーター参照に AWS::AccountId として存在する</li> </ul> </li> <li>Lambda のリソースベースポリシー <ul> <li><a href="https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/access-control-resource-based.html">AWS Lambda のリソースベースのポリシーを使用する</a></li> <li>この権限を利用すると、IAM 権限を利用せずとも AWS のリソースのアクセス権を自由にコントロールすることができる</li> <li>Lambda のアクセス権限の付与は、AddPermission や AddLayerVersionPermission で行える</li> </ul> </li> <li>インターネット公開系の権限(EC2のインスタンスへの通信許可など)は、ホワイトリストで管理するのは大変。そういった際には、ネットワーク系の操作を明示的に拒否する方法と併用するといい</li> <li>S3 へのアクセス元制限は、IAM ポリシーを使うより S3 側のバケットポリシーを使うのが一般的 <ul> <li><a href="https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html">Amazon S3 の VPC エンドポイント用のバケットポリシーの例</a></li> </ul> </li> <li>IAM ユーザーを作成する際の原則として、アクセスキー、シークレットアクセスキーを作らないことを推奨</li> <li>Capital One の情報流出事件(S3 からの情報流出)を防ぐために必要だった設定 <ul> <li>IAM ロールのクレデンシャルが漏洩した際の影響を最小化するため、IAM ロールに付与する権限を絞り込む</li> <li>バケットポリシーで接続元 VPC を制限する</li> </ul> </li> </ul> <h3>第7章 IAMの運用</h3> <ul> <li>IAM 運用の目的 <ul> <li>AWS を安全な状態に保ち続ける</li> </ul> </li> <li>目的の達成のために <ul> <li>維持するために手間が掛からない(現実に許容できるコスト)</li> <li>利用者によってセキュリティレベルの差異がでないようにする(標準化)</li> </ul> </li> <li>まずは利用者(人間、プログラム)を洗い出す</li> <li>AWS を利用する人ごとに適切な最小権限を付与し、必要でなくなったら権限をなくす <ul> <li>CloudTrail で AWS コンソール、API 利用履歴のログを取得する</li> <li>Config を利用し、IAM 関係の設定の変更を監視する <ul> <li><a href="https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-aws-config.html">AWS Config マネージドルールのリスト</a></li> </ul> </li> <li>Config Rules で設定値を監視</li> <li>(月次等の)定期的な IAM ユーザーの棚卸し</li> </ul> </li> <li>CLI やプログラムから利用する IAM ユーザーも、棚卸しが必要 <ul> <li>IAM ユーザーごとの担当者を明確化する <ul> <li>例えば、IAM ユーザーのタグに担当者を書く</li> </ul> </li> <li>最終利用日から一定時間が過ぎた IAM ユーザーは継続の確認をする <ul> <li>使われていなければ、まず無効化して、しばらくして問題がなければ消す</li> </ul> </li> </ul> </li> <li>CLI 利用のためにアクセスキーを発行する場合、アクセスキーの流出対策が必要 <ul> <li>CLI 利用時にも IAM ロールへの切り替えが可能</li> <li>IAM ユーザー側に IP アドレスによる利用制限をした上で、必要な場合にスイッチロールで権限を切り替えるという運用をしておけば、万が一流出しても直接の被害を防げる</li> </ul> </li> <li>マルチアカウント利用時は、各アカウントに IAM ユーザーを作るのではなく、踏み台 AWS アカウントを1個作り、そこの IAM ユーザーから、他のアカウントのロールにスイッチする</li> </ul> <h3>第8章 IAMとCloudFormation</h3> <ul> <li>複数の AWS アカウントに、同じようなポリシーやロールを作る場合、CloudFormation 化しておけば人的ミスを排除できる</li> <li>IAM ユーザーは基本的に一度作っておしまいなので、CloudFormation のライフサイクルで管理するメリットがほとんどない。そのため管理対象から外すことを推奨する</li> </ul> <h3>第9章 IAMのテンプレート集</h3> <ul> <li><a href="https://books.takuros.net/aws-iam/templates.zip">本書のテンプレート集のダウンロード URL</a></li> <li>管理者グループには IP 制限を加えるべきだが、IP 制限があると CloudFormation 等の一部の機能が使えない場合がある。そのため、スイッチロールを指定して IP 制限を解除できるようにしておく</li> <li>管理者ロールへスイッチできるユーザーを限定する方法としては、以下の2通りがある <ul> <li>ロールに、スイッチ可能なユーザーを記載する(本書のテンプレートはこちらを採用)</li> <li>スイッチロールを原則拒否し、必要なユーザーのみスイッチロールの権限を付与する</li> </ul> </li> <li>ネットワークに関連する権限は多岐に渡るため、自分でリストアップするのは難しい。<a href="https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_job-functions.html">職務機能の AWS 管理ポリシー(AWS managed policies for job functions)</a> にある NetworkAdministrator の利用を推奨する</li> <li>開発者に、EC2 インスタンスを立ち上げるための権限を付与しようとすると、いまや EC2 に IAM ロールを付与するのは必須であるため、IAM ロールの作成・更新に関する権限が必要。そうすると、実質的に何でもできてしまう <ul> <li>現実的な対応としては、開発環境では管理者権限を付与した上でしっかり監査証跡を残す</li> </ul> </li> </ul> <h3>第10章 IAM以外のAWSサービスの活用</h3> <ul> <li>AWS Organizations(組織アカウント) <ul> <li>ルートと呼ばれるマスターアカウントと、それに紐づく子アカウントがある。また、子アカウントを階層化するための組織単位がある</li> <li>アカウントに対するポリシーと言う形で、ホワイトリスト/ブラックリスト形式で権限の管理ができる</li> <li>上位で決めたポリシーは、個々のアカウント単位で打ち消すことはできない(強力な統制)</li> </ul> </li> <li>CloudTrail と Config <ul> <li>CloudTrail と Config は対となるようなサービス</li> <li>CloudTrail は操作ログの記録</li> <li>Config は操作の結果どういう状態になったのかの記録、および状態変更に対するアクションの定義</li> </ul> </li> <li>Amazon GuardDuty <ul> <li>脅威検出と継続的なモニタリングサービス</li> </ul> </li> <li>AWS Control Tower と AWS Security Hub <ul> <li>AWS Control Tower は複数アカウントの設定および管理</li> <li>Security Hub は複数のアカウントの状況を一括してモニタリング</li> </ul> </li> </ul> <h3>付録A アカウント開設時の設定チェックリスト</h3> <ul> <li>セキュリティの強化 <ul> <li>1) ルートアカウントの MFA 設定</li> <li>2) IAM Group と IAM ユーザーの作成</li> <li>3) IAM パスワードポリシーの適用</li> </ul> </li> <li>状況の出力・見える化 <ul> <li>4) CloudTrail の有効化</li> <li>5) Config の有効化</li> <li>6) GuardDuty の有効化</li> <li>7) Trusted Advisor の E メール通知設定</li> <li>8) Cost Usage Report の出力</li> </ul> </li> <li>機能を使うための設定 <ul> <li>9) ルートアカウントで IAM User への請求情報へのアクセス許可</li> <li>10) 支払い通貨を日本円に変更</li> <li>11) コスト配分タグの設定</li> <li>12) 代替連絡先の設定</li> </ul> </li> </ul> <h2>AWSの薄い本Ⅱ アカウントセキュリティのベーシックセオリー(発行日:2020年3月22日)</h2> <h3>第1章 AWSアカウントセキュリティ</h3> <ul> <li>AWS のセキュリティを3つの観点から分類 <ul> <li>1) AWS 上に構築するシステムのセキュリティ</li> <li>2) AWS アカウント自体の管理(IAM の設計・運用)</li> <li>3) セキュリティを維持管理するための施策</li> </ul> </li> <li>3は、いわゆる AWS アカウントのガードレール設計。本書の中心テーマの一つ <ul> <li>IAM を運用しているうちに抜け漏れが出てきたり、カバーしきれない部分がでてきたときに、それらを予防・検知するための施策がガードレール設計</li> </ul> </li> <li>本書では AWS Organizations は基本的には解説せず、その一部の機能であるサービスコントロール Policy(SCP)のみを扱う</li> </ul> <h3>第2章 ガードレールという設計と思想</h3> <ul> <li>Control Tower にはガードレールという機能がある</li> <li>ガードレール設計の思想と、Control Tower が実際にそれをどのように実現しているのか</li> <li>Control Tower は最小構成で3つの AWS アカウントで構成される <ul> <li>マスターアカウント</li> <li>ログ管理用アカウント</li> <li>監査用アカウント</li> </ul> </li> <li>一元管理と改ざん防止のため、ログ管理用アカウントと監査用アカウントが、その他のアカウント(開発環境用や本番環境用)から分離されている</li> <li>Control Tower は、道から踏み外さないための予防と検知を提供する <ul> <li>予防:自分の権限外の操作(例えばログの削除)を禁止する</li> <li>検知:ルールから外れた操作(例えばルートアカウントの利用)を検知する</li> </ul> </li> <li>Control Tower における予防と検知の実態は、Organization の SCP(Service Control Policy)と Config Rules <ul> <li>ただし、Control Tower の個々のガードレール名を見ても、予防なのか検出なのかの区別がつかないという欠点がある</li> </ul> </li> </ul> <h3>第3章 AWSのセキュリティサービス</h3> <ul> <li><a href="https://d1.awsstatic.com/whitepapers/compliance/JP_Whitepapers/NIST_Cybersecurity_Framework_CSF_JP.pdf">NIST Cybersecurity Framework</a></li> <li>CSF コア <ul> <li>特定(Identity)</li> <li>防御(Protect)</li> <li>検知(Detect)</li> <li>対応(Respond)</li> <li>復旧(Recover)</li> </ul> </li> <li>NST CSF コアを参照しながら、AWS のセキュリティサービスを整理する</li> <li>CloudTrail のおすすめの設定の一つに、クロスアカウントロールを利用して他のアカウントに対してログを保存するという方法がある <ul> <li>システム内で使う証跡情報はローカルの S3 バケットに保存し、監査用に集積する証跡情報は監査用 AWS アカウントのバケットに保存する</li> <li>こうすることにより、プロジェクトごとの利便性と、組織全体のガバナンスの両方を確保できる</li> </ul> </li> <li>GuardDuty の分析対象は、CloudTrail、VPC フローログ、DNS ログの3種類</li> <li>Trusted Advisor は便利だが、現在は通知方法がEメールしか使えない</li> </ul> <h3>第4章 サンドボックスアカウントの作成のチュートリアル</h3> <ul> <li>実験や検証に使う AWS アカウントのことを、本書ではサンドボックスアカウント(サンドボックス環境)と定義する</li> <li>今回作るサンドボックス環境の要件 <ul> <li>1) アカウントの利用者は一人(多人数でアカウントを共有しない)</li> <li>2) 利用者はそのアカウント内では、ほぼ全ての権限を持つ(管理者権限)</li> <li>3) 外部への情報漏えいにつながる行為、権限付与を禁止する</li> <li>4) 問題となる行為を定義し、自動で検知・通知できるようにする</li> <li>5) 問題検知時に通知だけでなく自動復旧を目指す</li> </ul> </li> <li>3の設定項目については、以下の4項目に具体化して考える <ul> <li>IAM ユーザーの新規作成禁止</li> <li>アクセスキーの作成禁止</li> <li>S3 のパブリックアクセス禁止</li> <li>不特定多数へのセキュリティグループ開放禁止</li> </ul> </li> <li><a href="https://aws.amazon.com/jp/iam/features/analyze-access/">IAM Access Analyzer</a> を有効にする</li> <li>マスターアカウント側で CloudTrail の設定をして、メンバーアカウントから設定や削除ができないようにする</li> <li>Config アグリゲータの設定をして、マルチアカウント・マルチリージョンで Config のデータを集約する</li> <li>Security Hub を有効化する</li> <li>Config Rule は登録時に設定した間隔で定期的にチェックされる(デフォルト12時間、最短1時間)</li> <li>自動復旧は、複雑な処理が必要な場合は Lambda でスクリプトを書き、定形処理で済む場合は AWS System Manager(SSM)の Automation を使う</li> <li>SCP の使い方としては、現状の仕様では <code>"Effect": "Allow"</code> を利用せず、<code>"Effect": "Deny"</code> で禁止すべき項目を設定していくほうがよい</li> </ul> <h3>第5章 CloudFormation を利用した構成管理</h3> <ul> <li>CloudFormation StackSets は、1つのテンプレートから複数の AWS アカウント・リージョンに対してスタックの作成・実行ができる機能</li> <li>2020年2月12日に機能が追加され、Organizations からアカウントの作成・削除時や OU の移動時に指定しておいた StackSets を自動で実行できるようになった</li> </ul> <h3>第6章 アカウントセキュリティの設計の考え方の原則</h3> <ul> <li><a href="https://d1.awsstatic.com/whitepapers/ja_JP/architecture/AWS_Well-Architected_Framework.pdf">AWS Well-Architected フレームワーク</a>(現時点の最新版は2020年7月)</li> <li>NIST CSF コアと、AWS Well-Architected Framework を比べながらの解説</li> <li>SEC 8「データをどのように分類していますか?」に該当する機能に、AWS Macie(機密データを検出、分類、保護するサービス)がある</li> </ul> <h3>第7章 障害の検知と復旧の考え方</h3> <ul> <li>AWS に多数あるセキュリティ関係のサービス同士の関係についての解説 <ul> <li>似たようなサービスもあるが、それをどう取捨選択するか</li> </ul> </li> <li>Security Hub と個別サービスの使い分けはシンプル <ul> <li>システムの運用に関わる障害は、アカウント個別に設定</li> <li>AWS アカウントに対する攻撃については、複数のアカウントで共通設定</li> </ul> </li> </ul> <h3>第8章 まとめとマルチアカウント管理への道</h3> <ul> <li>本書全体のおさらい</li> <li>予防的統制(Preventive controls)と発見的統制(Detective controls)</li> </ul> muziyoshiz Amazon Linux 2 に awscurl を安全にインストールする簡単な方法 hatenablog://entry/26006613658363853 2020-11-29T18:13:54+09:00 2020-11-29T18:13:54+09:00 この話の背景 以前のブログ記事で、Amazon Elasticsearch Service を awscurl(AWS 署名に対応した curl ライクなコマンド)経由で管理する方法をまとめました。 muziyoshiz.hatenablog.com 自分が扱っている環境では、管理用サーバ(Amazon Linux 2)に awscurl をインストールして使ってます。 この管理用サーバで使う Python 製のツールは awscurl だけだったので、Amazon Linux 2 標準の Python 2 に pip install awscurl して使ってたんですが、そしたら yum u… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20201129/20201129180845.png" alt="f:id:muziyoshiz:20201129180845p:plain" title="" class="hatena-fotolife" itemprop="image"></span></div> <h2>この話の背景</h2> <p>以前のブログ記事で、Amazon Elasticsearch Service を <a href="https://github.com/okigan/awscurl">awscurl</a>(AWS 署名に対応した curl ライクなコマンド)経由で管理する方法をまとめました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F11%2F30%2F144213" title="Amazon Elasticsearch Service の認証・認可に関する面倒くさい仕様をなるべくわかりやすく説明する - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/11/30/144213">muziyoshiz.hatenablog.com</a></cite></p> <p>自分が扱っている環境では、管理用サーバ(Amazon Linux 2)に awscurl をインストールして使ってます。</p> <p>この管理用サーバで使う Python 製のツールは awscurl だけだったので、Amazon Linux 2 標準の Python 2 に <code>pip install awscurl</code> して使ってたんですが、そしたら yum update を実行するたびに urllib3 のアップデートと衝突して使えなくなることが頻発。</p> <p>まあ、Python 知っている人にしたら「それはそう」って話なんですけど、awscurl を使いたいだけだからいいか、とサボってたんですよ……そしたら案の定という感じ。このためだけに pyenv 入れるのは面倒だなあと悩んでいたら、同僚にいい方法を教えてもらって解決したのでまとめておきます。</p> <h2>結論:pipx 経由で awscurl をインストールする(ただし Python 3 が必要)</h2> <p>pipx とは、Python で書かれたエンドユーザーアプリケーションを、独立した環境で動かすことができるツールです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fpipxproject%2Fpipx" title="pipxproject/pipx" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/pipxproject/pipx">github.com</a></cite></p> <p>コマンド名からお察しの通り、pipx は pip と同じく The Python Package Index (PyPI) を使えます。それに加えて、pipx はインストールしたツールが依存するパッケージを、ツールごとに独立した環境にインストールしてくれます。アップグレードやアンインストールも、同様にクリーンな環境で行なえます。</p> <p>サイト内の説明を借りると、いわば pipx は PyPI を Python アプリケーションのための巨大な app store にしてくれる(In a way, it turns Python Package Index (PyPI) into a big app store for Python applications.)というわけです。いいですね。</p> <p>ただし、pipx の動作には Python 3 が必須です。しかし Amazon Linux 2 に標準添付されているのは Python 2.7 だけ。amazon-linux-extras に Python 3 系があるので、細かいことを考える必要がないなら、これで Python 3 系を入れてしまうのが一番楽でした。</p> <p>以下、awscurl のインストールが完了するまでの具体的な手順です。</p> <h2>インストール手順</h2> <h3>Python 3 のインストール</h3> <p>amazon-linux-extras に関する説明はこちら。これは AWS が Amazon Linux 2 用に管理している yum リポジトリを有効にするコマンドです。ソフトウェアのインストール自体は yum コマンドで行います。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Faws.amazon.com%2Fjp%2Fpremiumsupport%2Fknowledge-center%2Fec2-install-extras-library-software%2F" title="Amazon Linux 2 EC2 インスタンスに Extras Library からソフトウェアをインストールする" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-install-extras-library-software/">aws.amazon.com</a></cite></p> <p>amazon-linux-extras 自体が未インストールの場合は、まず以下のコマンドでインストール。</p> <pre class="code" data-lang="" data-unlink>$ sudo yum install -y amazon-linux-extras</pre> <p>amazon-linux-extras コマンドで、現在利用できるリポジトリ(amazon-linux-extras の用語ではトピック)の一覧が確認できます。現時点では python3.8 が利用できることがわかります。</p> <pre class="code" data-lang="" data-unlink>$ amazon-linux-extras | grep python 44 python3.8=latest available [ =stable ]</pre> <p>そこで、今回は python3.8 のリポジトリを有効にしてから、yum コマンドでインストールします。将来、Python のバージョンが上がったら、python3.8 の部分は読み替えてください。</p> <pre class="code" data-lang="" data-unlink>$ sudo amazon-linux-extras enable python3.8 $ sudo yum install python3.8</pre> <h3>pipx のインストール</h3> <p>pipx のインストールは、<a href="https://github.com/pipxproject/pipx">pipx サイト内の手順</a> のコマンド名を python3 から python3.8 に置き換えれば OK です。</p> <pre class="code" data-lang="" data-unlink>$ python3.8 -m pip install --user pipx $ python3.8 -m pipx ensurepath</pre> <p>これで、そのユーザー(EC2 だと ec2-user)は特別なパス指定なしで pipx を使える状態になりました。pipx のインストール先は <code>~/.local/bin/pipx</code> です。</p> <h3>pipx 経由での awscurl のインストール</h3> <p>awscurl のインストールは、従来の pip を pipx に置き換えるだけで OK です。</p> <pre class="code" data-lang="" data-unlink>$ pipx install awscurl</pre> <p>awscurl のコマンドは <code>~/.local/bin/awscurl</code> にインストールされますが、awscurl が依存するパッケージ一式は <code>~/.local/pipx/venvs/awscurl/</code> 以下にインストールされます。このように、ツールごとに環境が分離されるわけですね。</p> <h3>注意点:シェル変数の扱いが変わる</h3> <p>コマンドごとに環境が分離されるためか、シェル変数の扱いが変わるようです。</p> <p><a href="https://muziyoshiz.hatenablog.com/entry/2019/11/30/144213">以前のブログ記事</a> では、awscurl コマンドへ自動的に認証情報を渡す awscurl-on-ec2 というシェルスクリプトを紹介しました。</p> <pre class="code" data-lang="" data-unlink>#!/bin/env bash ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/` CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}` AWS_ACCESS_KEY_ID=`echo $CRED | jq -r &#34;.AccessKeyId&#34;` AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r &#34;.SecretAccessKey&#34;` AWS_SESSION_TOKEN=`echo $CRED | jq -r &#34;.Token&#34;` awscurl &#34;$@&#34;</pre> <p>pipx でインストールした awscurl には、この方法ではシェル変数が渡されませんでした。以下のように、export を使って環境変数にすれば問題なく渡されました。</p> <pre class="code" data-lang="" data-unlink>#!/bin/env bash ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/` CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}` export AWS_ACCESS_KEY_ID=`echo $CRED | jq -r &#34;.AccessKeyId&#34;` export AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r &#34;.SecretAccessKey&#34;` export AWS_SESSION_TOKEN=`echo $CRED | jq -r &#34;.Token&#34;` awscurl &#34;$@&#34;</pre> <p>awscurl の場合はコマンドライン引数を使って、これらの認証情報を明示的に渡すこともできます。環境変数を増やしたくなかったので、自分はこちらの方法で対応しました。</p> <pre class="code" data-lang="" data-unlink>#!/bin/env bash ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/` CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}` AWS_ACCESS_KEY_ID=`echo $CRED | jq -r &#34;.AccessKeyId&#34;` AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r &#34;.SecretAccessKey&#34;` AWS_SESSION_TOKEN=`echo $CRED | jq -r &#34;.Token&#34;` awscurl --access_key $AWS_ACCESS_KEY_ID --secret_key $AWS_SECRET_ACCESS_KEY --session_token $AWS_SESSION_TOKEN &#34;$@&#34;</pre> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 21 hatenablog://entry/26006613647423567 2020-10-31T23:34:14+09:00 2020-10-31T23:34:49+09:00 SRS 本の読書メモです。 Chapter 7 までは順番に読んでましたけど、途中を飛ばして、気になっていた最終章の Chapter 21 を先に読んでみました。 SRS 本について SRS 本はこちらから無償でダウンロードできます。 前回までの読書メモは SRS Book タグ を参照のこと。 Chapter 21. Building a Culture of Security and Reliability この章では、セキュリティと信頼性に関する健全な文化の側面について述べる。また、変化を起こすべきときに、良いプラクティスを選ぶことで、あなたがどのように組織文化に影響を与えることができる… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>SRS 本の読書メモです。</p> <p>Chapter 7 までは順番に読んでましたけど、途中を飛ばして、気になっていた最終章の Chapter 21 を先に読んでみました。</p> <h2>SRS 本について</h2> <p>SRS 本はこちらから無償でダウンロードできます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>前回までの読書メモは <a href="https://muziyoshiz.hatenablog.com/archive/category/SRS%20Book">SRS Book タグ</a> を参照のこと。</p> <h2>Chapter 21. Building a Culture of Security and Reliability</h2> <p>この章では、セキュリティと信頼性に関する健全な文化の側面について述べる。また、変化を起こすべきときに、良いプラクティスを選ぶことで、あなたがどのように組織文化に影響を与えることができるかについても触れる。そして、セキュリティと信頼性についての同意を得るために、組織を超えてリーダーとチームに対しての影響を与えるかについての洞察を提供する。</p> <p>Google やその他の組織で有用だったいくつかのプラクティスを共有するが、同じ組織は2つと無いこと、これらのプラクティスをあなたの組織の文化に合わせて応用する必要があることに注意してほしい。また、Google もこれらを完璧に実践できているわけではなく、日々改善を進めていることを添えておく。</p> <p>例えばこんなシナリオを想像しよう:あなたの組織には大きな取引(Big Deal)が近づいており、みな締切に追われている。しかし、今日あなたは攻撃者がシステムに進入した証拠を発見してしまう。あなたはすぐシステムをオフラインにすべきと気づいているが、もちろん顧客は怒り、大きな取引はリスクに晒されるだろう。おそらくあなたは、先月のセキュリティパッチを適用していなかったことを責められるだろう。こんな状況で、あなたの組織の文化は、どのような決定を促すだろう? 強いセキュリティ文化を持つ健全な組織なら、従業員がそのインシデントについてすぐ報告することを促すだろう。</p> <p>この章では、セキュリティと信頼性の文化(a culture of security and reliability)を構築するためのパターンとアンチパターンの両方を紹介する。</p> <h3>Defining a Healthy Security and Reliability Culture</h3> <p>健全なシステム(healthy systems)のように、健全なチーム文化は明示的に設計され、実装され、そして維持されることができる。健全なシステムを構築するための設計の原則(design principles)があるように、健全な文化にもそのような設計の原則がある。</p> <h4>Culture of Security and Reliability by Default</h4> <p>Chapter 4 で議論したように、セキュリティと信頼性について考えることは、プロジェクトの最終盤に回されがちである。しかし、あとから技術的負債を支払おうとすると、長期的なベロシティは低下し、その仕組みには一貫性がなく、失敗を招くことになりかねない。</p> <p>それはさながら、シートベルトやエアバッグが車に標準搭載されておらず、消費者があとから買わなければならない世界のようだ。これらは車の設計時から考慮されるべきだし、そのほうが最適な場所に設置されるだろう。このたとえ話は、システムにとって、最初から(デフォルトで)セキュアかつ信頼できること(secure and reliable by default)ことの必要性を示している。</p> <p>最初からセキュリティと信頼性について考える健全な文化を持つ組織は、開発者に、それらをプロジェクトの初期段階で(例えば設計段階で)考えること、そして実装のイテレーションを繰り返すなかでも考え続けることを促す。そのように成熟した製品は、セキュリティと信頼性を維持しつづけることが自然にできるようになる。</p> <p>Google の、最初からセキュリティと信頼性を考える文化(a culture of security and reliability by default)の発展についての知見を、本書の Chapter 12, 13, 19 で示した。</p> <h4>Culture of Review</h4> <p>強いレビュー文化が整っている環境では、誰もが変更を承認する際に、自分の役割について前もって考えることを促される。本書では、以下のようなピアレビューの方法を取り上げてきた。</p> <ul> <li>最小権限(least privilege)を保つための、アクセスや変更の認可に関する複数人でのレビュー(Multi-party authorization reviews)(Chapter 5)</li> <li>コードの変更が適切かつ高品質(セキュリティと信頼性の考慮も含む)であることを保証するためのピアレビュー(Chapter 12)</li> <li>本番システムに適用される前の、設定変更のピアレビュー(Chapter 14)</li> </ul> <p>このような文化を構築するためには、レビューの価値とそれをどのように実行するかについて、組織全体で幅広い理解が必要である。</p> <p>レビューで期待されることを明らかにするために、変更レビューのプラクティスは文書化されるべきである。レビューで拒否されたときに、その理由を明確にできることは、感情的にならないためにも必要である。</p> <p>レビューの文化は、そのレビュープロセスに全員が参加することを必要とする。その人がシニアロールであるとか、参加したくないとかいう理由で、レビューから逃れることを許すべきではない。</p> <p>(コラム:Reducing Friction) 軽微な変更に対しては、より軽量なレビューを選択肢として提供できるようにすることを考えてみよう。Chapter 14 で述べたとおり、レビューはそれが必須である場合のみ有効に働く。ただし、どのような場合に軽量レビューを実施できるかを、ガイドラインで明確にする必要がある。</p> <p>レビュアーが、意思決定するための十分なコンテキストを知らない場合は、レビューを断るか、他の人にレビューを回すという選択肢を保証すべきである。</p> <p>自動チェックは、このようなコンテキストの構築を補助することができる。例として、Chapter 13 では、コードのサブミット前に、開発者とレビュアーに、セキュリティ問題を自動的に示すツール Tricorder を Google がどのように使っているかを示した。</p> <h4>Culture of Awareness</h4> <p>組織のメンバーが、自分たちのセキュリティと信頼性に対する責任に気づいていて、それを実践する方法を知っていたら、良い成果物を効率的に生み出すことができる。認知と教育の戦略は、強いセキュリティ文化を作るための鍵である。</p> <p>Google では、従業員の教育のために、複数のアプローチを取っている。広範囲には、年1回の必須のトレーニングを全従業員に提供している。さらに、ここで伝えたメッセージを、役割ごとの特別なプログラムで強化している。Google での長年の実践により、有効とわかったいくつかの戦略を以下に示す。</p> <ul> <li>Interactive talks <ul> <li>参加型の講演。例えば、Google では重大なインシデントに関する主要な根本原因および緩和策について共有することで、私達がなぜこのようなトピックに集中しているかを従業員によく理解してもらうことができた</li> </ul> </li> <li>Games <ul> <li>例えば、ゲームを通して XSS を見つける方法および悪用する方法を学べる XSS game</li> </ul> </li> <li>Reference documentation <ul> <li>Chapter 12 で、リファレンス文書の重要性を書いた。詳しい情報を口頭で正確に伝えることは難しい</li> </ul> </li> <li>Awareness campaigns <ul> <li>開発者に、最近のセキュリティおよび信頼性に関する問題について知ってもらうことは難しい。この問題に対して、Google では1ページ形式の週刊のアドバイス "Testing on the Toilet" を発行している。これを全 Google オフィスのトイレに張り出している</li> </ul> </li> <li>Just-in-time notifications <ul> <li>なにか、良いプラクティスに反したことをした瞬間にタイミングよく知らせることで、従業員の理解を深めることができる。例えば、ソフトウェアを信頼できないリポジトリからアップグレードしようとしたときや、センシティブデータを未承認のクラウドストレージシステムにアップロードしようとしたときにポップアップを出す。Chapter 13 に、これに関連した話題を書いた</li> </ul> </li> </ul> <h4>Culture of Yes</h4> <p>時とともに、組織にはリスクに対して保守的な文化が育ちやすい。特に、セキュリティ上の欠陥や信頼性の問題によって、収益を失ったり何らかの悪影響を被ったことがある場合はそうである。</p> <p>そのような考え方は No の文化(a culture of no)、すなわちリスクのある変更や、ネガティブな結果になりうる変更を回避する文化に繋がりうる。健全な組織は、ある程度のリスクはあるがメリットのある選択を取る際に、"yes" と答えるための方法を持っている。</p> <p>例えば、Chapter 8 の Google App Engine の例がある。Google App Engine は悪意のあるコードがその上で動く可能性があるサービスである。そのようなリスクはあるが、製品チームとセキュリティチームが連携することで、最終的にこのプロダクトをローンチできた。</p> <p>リスクを許容するための他のアプローチには、エラーバジェットがある。</p> <p>(コラム:Balancing Accountability and Risk Taking) コードレビューを行う人が、自分が最後の砦だ、と思うようになると、リスクのある変更は受け入れがたくなっていく。リスクを共用できるようにするためには、このプレッシャーを下げるための、例えば、最小権限や、回復性、テストといった要素のためのデザイン戦略が必要である。多層的なアプローチで、個人に対する重荷を軽くすることができる。例えばレビューでミスを犯しても他の自動的なチェックが働くなど。</p> <h4>Culture of Inevitably</h4> <p>完璧なシステムなどなく、どんなシステムもいつかは失敗する可能性がある。Googleでは、失敗はいつでも起こりうると仮定している。実世界のシステムは、100%セキュアかつ信頼できるとは決して言えないと私達は知っている。</p> <p>Chapter 16 では、このような不可避の問題に対する準備の必要性について議論した。不可避の文化(culture of inevitability)を持つチームは、大規模な障害(disasters)に備えるために時間を割き、そのような場合に効率的に対応できる。</p> <p>また、本書の Chapter 18、および SRE 本の Chapter 15 にある、批判のないポストモーテム(blameless postmortems)もその一例である。</p> <h4>Culture of Sustainability</h4> <p>システムの信頼性とセキュリティを長期的に維持するためには、その組織が、それらを改善するための努力を継続的に行う、つまり十分なリソース(スタッフと時間)を割き続けることを保証しなければならない。</p> <p>この努力を維持するために、チームはリアクティブな仕事と、長期的に報われるプロアクティブな投資の間でバランスを取ることができなければならない。Chapter 17 の例では、効率的なチームは、ある1人に過大な責任を追わせないために、ハードワークを大勢の人の間で分かち合っていることを示した。</p> <p>持続性の文化(a culture of sustainability)を持つ組織では、改善のための投資と同様に、運用業務(例えばインシデント対応)を扱うために必要な工数も計測する。ストレス、燃え尽き、士気(morale)を考慮する。</p> <p>Google SRE の "follow the sun" シフトもその一例である(コラム:Sustainable Reliability and Security Culture at Google)。</p> <p>持続性の文化を持つということは、例外的な状況では通常の業務量から一時的に逸脱することがありうるということを理解し、そのような逸脱を扱うための良いプロセスを持っているということも意味する。そのような例外的な状況が解決したあとで、引き続き持続性の文化を維持するために、以下のようなことを考慮するとよい。</p> <ul> <li>一時的な対応は、問題が解決したらもとに戻す。トイルが増えたまま戻さない、ということにならないようにする</li> <li>通常のプロセスを迂回する権限を持つ、専任のグループを持つ。ただし、ベストプラクティスを迂回したり覆した点を記録しておき、必ずあとで対処する</li> <li>イベントが完了したら、ポストモーテムにて、今回の障害を導いた報酬システムを必ずレビューすること。開発を優先して信頼性やセキュリティを蔑ろにする文化では、このときに技術的負債を生む可能性がある</li> </ul> <h3>Changing Culture Through Good Practice</h3> <p>セキュリティと信頼性に関する新しい活動は、恐れを生じさせる。それは、開発速度を低下させるのではないか、新しいリスクを生じさせるのではないか、という恐れだ。しかし、著者らの意見としては、そのような摩擦を生じさせるというのは神話(myth)である。</p> <p>もし、ある種の文化的な配慮を行ったうえで変更を実施すれば、それらの変化はすべての人の経験を向上させることができる、と私達は信じている。</p> <p>この節では、変化を導入するための技術的な戦略について議論する。あなたは CEO やリーダーではないかもしれないが、すべての開発者、SRE、セキュリティ専門家はそれぞれの広さで影響を与えるための手段を持っている。</p> <h4>Align Project Goals and Participant Incentives</h4> <p>信頼を築くのは難しく、失うのは易しい。システムを設計、実装、維持する人々が、異なる役目を超えてコラボレーションするためには、みんなが共通の報酬システム(common reward system)を共有する必要がある。</p> <p>技術的なレベルでは、プロジェクトの信頼性や安全性は、SLO のような測定可能なメトリクスや、脅威モデル(例:Chapter 2, 14)を通して評価できる。プロセスや人のレベルでは、信頼性や安全性への貢献がキャリアアップに繋がることを保証すべきである。理想的には、そのような評価基準が明文化されているべきである。</p> <p>プロジェクトのゴールを組織の目的に揃える一方で、個人のインセンティブに揃えない場合、それは非協力的な組織文化に繋がりかねない。</p> <h4>Reduce Fear with Risk-Reduction Mechanisms</h4> <p>大きな変更は、組織の中で反対されることがある。そのような場合は、よいデプロイ上の選択を提示することで、信頼を得ることができる。Chapter 7 で触れた話題だが、組織文化への影響についてここで改めて触れる価値があるだろう。</p> <ul> <li>Canaries and staged rollouts <ul> <li>安全なリリースを繰り返すことで、次第に、組織はそのような気配りと勤勉さをすべての変更に期待するようになる。そして変更に対する信頼を構築し、恐れを減らすことができる</li> <li>このようなリリース方法については SRE workbook の Chapter 16 で触れた。また本書の Chapter 19 では Chrome のリリースサイクルについて議論した</li> </ul> </li> <li>Dogfood <ul> <li>自分たちが実施しようとしている変更を自分たち自身に適用し、それをユーザーに示すことで、その変更が安定性や生産性に与える影響をユーザーに保証することができる</li> <li>例えば、多要素認証のような新しいメカニズムを導入する際に、まず自分たちの業務に導入する</li> </ul> </li> <li>Trusted Testers <ul> <li>社内でテスターを募集し、フィードバックをオープンに求める。そして、フィードバックを活用して、自分たちがフィードバックを聞いていることを知ってもらう</li> </ul> </li> <li>Opt in before mandatory <ul> <li>いきなり必須にするのではなく、移行期間を設ける。いつ有効化するかを選択できるようにする</li> </ul> </li> <li>Progressive stringency (漸進的な説得力、妥当性、厳密さ) <ul> <li>いきなり厳密なポリシーを適用するのではなく、徐々に適用できないかを考える</li> <li>例えば、最小権限を例に挙げると、最初は対象を開発者に制限したり、権限がないアクセスを拒否するのではなくエラーを出すだけに留めるなど</li> </ul> </li> </ul> <h4>Make Safety Nets the Norm(セーフティネットを規範にする?)</h4> <p>信頼性およびセキュリティに対する改善が、あなたが今まで頼ってきたリソースを使えなくすることはよくある。例えば、いままで root 権限を使えていたものが使えなくなったら。緊急時の作業の妨げにならないか?といった恐れを抱くことは自然なことである。</p> <p>breakglass procedures のようなセーフティネット(Chapter 5)を提供することで、変更に対する恐れを減らすことができる。セーフティネットは最後の手段であって、便利な代替手段とみなされないようにすべきである。また、システムを安全に保つための段階的なロールアウト手段が、場合によっては緊急リリースの邪魔になるかもしれない。変更を即座にプッシュするための迂回手段があれば、そのような懸念は避けられる。この種の状況については Chapter 14 で議論した。</p> <h4>Increase Productivity and Usability</h4> <p>セキュリティ及び信頼性の観点での組織的な変更が、生産性や使い勝手を落とすのではないか、という恐れが生じると、その導入を難しくする。そのため、導入戦略について注意深く考えることは重要である。私達は、以下のテクニックが摩擦を減らす助けになることを見てきた。</p> <ul> <li>Build transparent functionality <ul> <li>Chapter 6, 12 にあるように、デフォルトの選択が良い状態なら、罰を与えるようなことをしなくても、開発者は正しいことをする</li> <li>このアプローチではれば、開発者自身がセキュアかつ信頼できるシステムの恩恵を受けるだけでなく、これらの活動をシンプルかつ簡単にしようとしているあなたの意図を理解できる</li> </ul> </li> <li>Focus on usability <ul> <li>今までの仕組みより、新しい仕組みのほうが使いやすければ、導入は簡単に進む</li> <li>chapter 7 の二要素認証の例では、認証はセキュリティキーをタッチするだけで済むようになり、パスワードの定期変更も求められなくなった</li> </ul> </li> <li>Self-registration and self-resolution <ul> <li>Googleではインストールして良いソフトウェアの allow list と deny list を持っている。中央集中で管理していると、そこが許可のボトルネックになってしまう</li> <li>Googleでは、これらのリストにないソフトをインストールしたいときには、Upvote というポータルを通して、必要な許可を迅速に得られるようにしている。また、大勢の希望があるときは自動的に許可する仕組みもある</li> </ul> </li> </ul> <h4>Overcommunicate and Be Transparent</h4> <p>システム変更を主張する際に、コミュニケーション手段は結果に影響しうる。Chapter 7 および 19 で議論したように、よいコミュニケーションは変更への同意と信頼を得るための鍵である。</p> <p>どのように変更が起こるかについての情報とわかりやすい知見を与えることで、人々の恐れを減らし、信頼を構築できる。私達は以下に示す戦略が成功するのを見てきた。</p> <ul> <li>Document decisions <ul> <li>変更を行うときは、なぜそれが起こっているのか、成功はどのように見えるのか、操作が状況を悪化させたらどのように変更をロールバックするのか、懸念がある場合は誰に話せばいいのかを明確に文書化する</li> <li>それが従業員に直接影響する場合は特に、なぜあなたがその変更を行っているのかを明確に伝える</li> <li>注釈に、SRE が行う Production Excellence reviews についての記載あり</li> </ul> </li> <li>Create feedback channels <ul> <li>懸念を持つ可能性がある人々が使えるフィードバックチャンネルを作り、双方向のコミュニケーションを作る</li> <li>フィードバックフォームや、バグトラッキングシステムへのリンク、あるいは単なるメールアドレス</li> <li>関係者を巻き込むことで、恐れを減らすことができる</li> </ul> </li> <li>Use dashboards <ul> <li>あなたが人々に期待していることを明確に示し、その進捗に対するフィードバックを提供するためにダッシュボードを使う</li> </ul> </li> <li>Write frequent updates <ul> <li>変更に長い時間がかかる(Google の場合は数年に渡ることも)場合は、進捗を頻繁に(例えば月1回)ステークホルダーに共有するための担当者をアサインする。これは、特にリーダーへの、信頼を得る役に立つ</li> </ul> </li> </ul> <h4>Build Empathy</h4> <p>チームを超えた共感(Cross-team empathy)は、それがシステムの信頼性とセキュリティに関わるものであれば特に重要である。なぜなら、Chapter 20 で論じたように、信頼性とセキュリティに対する責任は組織全体で共有されるべきものだからである。</p> <p>Chapter 19 では、チームを超えた共感を作るためのいくつかのテクニック、特に実装、デバッグ、コード修正に対する責任を共有する方法について述べた。</p> <p>共感を作るための他のアプローチとしては Job shadowing(他の人の仕事を後ろで観察する)や job swapping(仕事を交換する)がある。これらはトップダウンでの組織的な変更を必要とせずに実施できる。これは数時間から、(マネジメント層の許可は必要だろうが)数ヶ月までの幅がありうる。他の人にあなたのチームの仕事を経験してもらうことで、あなたは組織のサイロを壊して、共通の理解を作ろうとしているというシグナルを送ることができる。</p> <p>Google の SRE Security Exchange Program は、他の SRE やセキュリティエンジニアを1週間経験できる(shadow, 後ろで観察する)プログラムである。この交換プログラムの最後に、SRE は自分たちのチーム自身と、ホストチームの両方に対する改善提案をレポートに書く。このプログラムは非常に低い投資で、組織をまたいだ知識共有の面で大きな利益を生んでいる。他には、SRE 組織に6ヶ月参加してもらう Mission Control program もある。</p> <p>最後に、感謝を伝える仕組みの構築(building in mechanisms to say thank you)ーー簡単なメールから、より詳細な形式のものまでーーは、人々がお互いに対して与えるポジティブな影響を強め、正しいインセンティブを与える。Google には、長年に渡るピアボーナスの文化がある。これの、現金のやり取りがないバージョンは Kudos と呼ばれるもので、Googler は全員に見えるフォーム上で感謝を伝えることができる。いくつかのオフィスでは、感謝のポストカードも試してきた。</p> <h3>Convincing Leadership(リーダーを説得する)</h3> <p>もしあなたが大きな組織で働いているなら、あなたが行いたいセキュリティや信頼性に関する変更に対して、支持を得る(原文では get buy-in = 買付を得る?)のは難しいことだろう。多くの組織は、自分たちの数少ないリソースを、利益を生むために使うように動機づけされているため、彼らの目に見えない部分を改善するための支持を得ることは難しい。</p> <p>この節では、そのような変更に対して、リーダーからの支持を得るための戦略について見ていく。これらは私達が Google で用いたものに加え、他の場所で用いられているのを見たものも含む。</p> <h4>Understand the Decision-Making Process</h4> <p>ここでは、リーダー(leadership)という単語は、方針決定やリソース配分、利害関係の調整にまつわる決定を行うことができる人々を緩やかに指すものとする。</p> <p>あなたがそれらの人々に影響を与えたいので、それが具体的に誰なのかを明らかにする必要がある。あなたが大企業で働いていたら、それは VP であったり、上位の管理職かもしれない。スタートアップや非営利団体のようなもっと小さな組織なら、それは CEO かもしれない。オープンソースプロジェクトなら、プロジェクトの創設者かトップコントリビューターだろう。</p> <p>「誰がその変更に対する決定権を持っているのか?」という質問への答えは、解くのが難しい場合がある。それは組織上のリーダーではなく、テックリードのような場合もある。また、複数の人の場合もある。Chapter 7 で述べた Chrome の HTTPS 対応の例のように、コミュニティの場合もある。しかし、この質問の答えを避けて通ることはできない。</p> <p>意思決定者を見つけたら、その人が直面している困難や要求について理解しようとすべきである。それらを理解することは、あなたの提案する変更がうまくはまる場所を理解するために重要である。</p> <h4>Build a Case for Change</h4> <p>すでに述べたように、変更への抵抗は、恐れや摩擦の認識に起因する。しかし、多くのケースでは、変更の理由を理解していないことにも起因する。</p> <p>成功する case-building process に必要なステップを以下に示す。</p> <p>※ ここで言う case はどういう意味? リーダーに問題として認識してもらう、といった意味?</p> <ul> <li>Gather data <ul> <li>変更が必要と思うに至った理由があるはず。それをデータで説明できること</li> </ul> </li> <li>Educate others <ul> <li>例えば、Google の Red Team postmortems(Chapter 20)。SREが直面するリスクの種類について、リーダーを教育するためのもの。もともとは教育が目的に作られたものではないが、会社の全階層における認識を高めることができる</li> </ul> </li> <li>Align incentives <ul> <li>他の面でもメリットが有ることを説明し、お互いにインセンティブがあるという状態にする</li> <li>例えば、DDoS 攻撃に強いフレームワークを導入することで、セキュリティ上の利点に加えて、より安定したウェブサイトは売上を高めるという効果もある。これは企業のリーダー層にとって強い根拠になる</li> </ul> </li> <li>Find allies(支持者を探す) <ul> <li>支持者の存在は説得力を高めるし、あなたの論拠をピアレビューしてより強くしてくれる</li> </ul> </li> <li>Observe industry trends <ul> <li>あなたが適用しようとしている変更が、他の組織がすでに適用している変更であれば、その他組織の経験はあなたの組織のリーダー層を説得する際の助けになるかもしれない。その特定のトピックおよび業界トレンドに詳しいエキスパートを呼んで、あなたの組織のリーダー層に説明してもらうことさえ可能かもしれない。</li> </ul> </li> <li>Change the zeitgeist(時代精神を変える) <ul> <li>もしあなたが、あなたの問題について日々考えている人々の考え方を変えられるなら、そのあとで意思決定者を説得するのはより容易だろう。これは、あなたがその変更に対する広いコンセンサスを必要としているときに、特に有効である。Chapter 7 の HTTPS のケーススタディはこれにあたる</li> </ul> </li> </ul> <h4>Pick Your Battles</h4> <p>組織が信頼性とセキュリティの課題に数多く直面している場合、継続的なアドバイスは、アドバイスされることへの疲れや、追加の変更への抵抗感を生んでしまう。あなたの戦う場所を慎重に選ぶ(pick your battles carefully)、つまり成功する見込みのある取り組みを優先し、勝ち目のない戦い(lost causes)の止めどきを知ることが重要である。</p> <p>勝ち目のない戦い、つまり棚上げにしなければならない提案にも価値がある。変更をうまく主張できないときでさえ、自分のアイデアを裏付けるデータや、自分の計画を支持してくれる仲間がいること、そして問題について人々を教育することには、価値がある。将来、あなたの組織がその課題に取り組む準備ができたときに、それまでにあなたが準備したものがあれば、チームはより素早く行動することができる。</p> <h4>Escalations and Problem Resolution</h4> <p>最善の努力を尽くしても、セキュリティや信頼性に関わる変更についての意思決定の必要が、爆発的に表面化することがある。重大な障害やセキュリティ脆弱性により、あなたは急遽追加のリソースやスタッフを必要とするかもしれない。あるいは、2つのチームが問題解決の方法について異なる意見を持ち、意思決定の自然な流れが働かないかもしれない。</p> <p>このような状況では、あなたはマネジメントチェーンから解決手段を探す必要があるかもしれない。意思決定のエスカレーションを行う場合、私達は以下のガイドラインを推奨する。</p> <ul> <li>その状況に関する意見を、両方の側から提供するために、同僚、メンター、テックリード、またはマネージャーのグループを作る</li> <li>そのグループに、現在の状況と、提案された選択肢を、マネジメント層のために要約させる</li> <li>あり得る解決手段についてさらに調整するために、あなた自身のチームのリーダーにその要約を共有する</li> <li>影響を受けるマネジメントチェーン全員にその状況を説明し、それぞれのチェーンでの適切な意思決定者を指名するための会議を設定する</li> </ul> <p>具体例をあげると、Googleでは、セキュリティ問題に対するアクションについて、プロダクトチームとセキュリティレビュアーの間で意見が一致しなかった場合に、エスカレーションが必要になる。このケースでは、セキュリティチームからエスカレーションが開始される。Googleではこのようなエスカレーションを通常の企業文化の一部としているため、エスカレーションは対立的なものとはみなされない。</p> <h3>Conclusion</h3> <p>あなたがシステムを設計して管理するのと同様に、あなたはセキュリティと信頼性の目標を達成するために、時間をかけて組織の文化を設計、実装そして維持することができる。</p> <p>セキュリティと信頼性の向上は、摩擦の増大に対する恐れや懸念を抱かせることがある。そのような恐れに対処し、変更の影響を受ける人々からの支持を得るのを助けるための戦略がある。あなたのゴールと、リーダーを含むステークホルダーのゴールを揃えることが鍵である。ユーザビリティに焦点を当て、ユーザーへの共感を行動で示すことで、ユーザーが変化を受け入れることを促すことができる。他の人が変化をどのように認識しているかを理解するために小さな投資をすることで、あなたの変更が妥当なものだとユーザーに納得させることができるかもしれない。</p> <p>この章の冒頭で述べたように、同じ文化は2つとして無いので、本書で紹介した戦略をあなた自身の組織に適合させる必要がある。あなたの組織で最も解決すべき問題領域を選び、それを時間をかけて解決していくことが必要である。</p> <h2>ここまでの感想</h2> <p>最終章だけあって、本書のエッセンスが詰まったような章でした。自分の SRE としての経験からも頷ける内容が多い一方で、本章にある「恐れを抱く側」になっていることも時々あるな、と感じました。</p> <p>あとは、普段自分でもなんとなく考えていたことがうまく明文化されていたので、他の人と議論するときに本書の概念をうまく使っていきたいと思いました。特に「持続性の文化(a culture of sustainability)」は、そういうふうに表現するのかと感心しました。</p> <p>さて次はどの章を読もうか……。あとはざっと読むだけで、特に面白かった箇所だけ読書メモを残すようにしようか、とも考えてます。</p> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 7 hatenablog://entry/26006613621789775 2020-08-30T21:44:26+09:00 2020-08-30T21:51:09+09:00 SRS 本の読書メモです。 Chapter 7 は、Google での事例を中心に、変更にはその内容によって異なるタイムライン(短期、中期、長期)があることと、タイムラインの種類ごとに注意すべき点を解説しています。 事例情報がメインなので、要約してしまうと面白さが減ってしまいそうな章でした。そのため、今回のメモは短めです。興味を持たれた方は原文をご参照ください。 SRS 本について SRS 本はこちらから無償でダウンロードできます。 前回までの読書メモは SRS Book タグ を参照のこと。 Chapter 7. Design for a Changing Landscape この章では、G… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>SRS 本の読書メモです。</p> <p>Chapter 7 は、Google での事例を中心に、変更にはその内容によって異なるタイムライン(短期、中期、長期)があることと、タイムラインの種類ごとに注意すべき点を解説しています。</p> <p>事例情報がメインなので、要約してしまうと面白さが減ってしまいそうな章でした。そのため、今回のメモは短めです。興味を持たれた方は原文をご参照ください。</p> <h2>SRS 本について</h2> <p>SRS 本はこちらから無償でダウンロードできます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>前回までの読書メモは <a href="https://muziyoshiz.hatenablog.com/archive/category/SRS%20Book">SRS Book タグ</a> を参照のこと。</p> <h2>Chapter 7. Design for a Changing Landscape</h2> <p>この章では、Googleが長年、どのような変更を行ってきたか、そしてそれをどのように適用してきたかという事例を複数紹介する。そして、その道程で私達が学んできた教訓を示す。</p> <p>ほとんどの設計上の判断は、特にそれがアーキテクチャに関するものは、システムの設計フェーズで実装するのが最も容易かつ安価である。しかし、この章で示すベストプラクティスのほとんどは、システムライフサイクルの後半のステージで実装されたものである。</p> <p>私達が日々扱うライブラリやアプリケーションの数は増え続けており、それらには常に新たな脆弱性の影響を受ける可能性がある。また、ユーザーや各種規制からの、セキュリティやプライバシーに対する期待も常に上がり続けている。</p> <p>このような状況に対応するためには、自分たちのインフラを頻繁かつ迅速に変更できる必要があるが、その一方で高信頼なシステムを維持する必要もある。このバランスをとるためには、変更をいつ、どのくらいのスピードでロールアウトする(展開する)かを決めることが重要になる。</p> <h3>Types of Security Changes</h3> <p>自分たちのセキュリティ体制(security posture)を改善したり、セキュリティインフラの回復力を高めるためには、さまざまな変更が考えられる:</p> <ul> <li>Changes in response to security incidents (see Chapter 18)</li> <li>Changes in response to newly discovered vulnerabilities</li> <li>Product or feature changes</li> <li>Internally motivated changes to improve your security posture</li> <li>Externally motivated changes, such as new regulatory requirements</li> </ul> <h3>Designing Your Change</h3> <p>セキュリティ上の変更(security changes)は、他のソフトウェア変更と同様、基本的な信頼性要件とリリースエンジニアリング原則の対象となる(本書の Chapter 4 や SRE 本の Chaprter 8 を参照)。セキュリティ上の変更をロールアウトするためのタイムラインは異なるかもしれないが、その全体的なプロセスは同じベストプラクティスに従うべきである。</p> <p>すべての変更がもつべき特性(characteristics)は以下の通り:</p> <ul> <li>Incremental <ul> <li>個々の変更を、小さく、独立したもののする。リファクタリングのような、無関係な変更を混ぜたくなる誘惑に逆らう</li> </ul> </li> <li>Documented <ul> <li>その変更内容およびロールアウトの相対的な緊急性を理解できるように、変更についての "how" と "why" を記載する</li> <li>文書に含まれる内容: <ul> <li>Requirements</li> <li>Systems and teams in scope</li> <li>Lessons learned from a proof of concept</li> <li>Rationale for decisions (in case plans need to be reevaluated)</li> <li>Points of contact for all teams involved</li> </ul> </li> </ul> </li> <li>Tested <ul> <li>ユニットテスト、および可能ならインテグレーションテストを行う</li> </ul> </li> <li>Isolated <ul> <li>Feature flag を用いて、機能のオンオフと、バイナリの更新を別に扱う(詳しい情報は SRE workbook の Chapter 16 を参照)</li> </ul> </li> <li>Qualified <ul> <li>複数のステージからなる、正規のリリースプロセスに従ってロールアウトする</li> </ul> </li> <li>Staged <ul> <li>カナリアリリースのような方法で、段階的にリリースする。変更前後でのシステムの振る舞いの違いを確認できるようにすべき</li> </ul> </li> </ul> <p>これらのプラクティスは "slow and steady" approach を取ることを勧めているが、スピードと安全さの間にはトレードオフがある。</p> <h3>Architecture Decisions to Make Changes Easier</h3> <p>システムを変更しやすい状態にするための戦略について。</p> <h4>Keep Dependencies Up to Date and Rebuild Frequently</h4> <p>自分がシステムが依存しているソフトウェア(OpenSSL や Linux カーネルなど)について、最新のバージョンを利用するように保ち続ける。最新版を利用していればパッチを当てるのも用意になる。</p> <h4>Release Frequently Using Automated Testing</h4> <p>SRE の基本原則では、巨大なリリースを行う代わりに、そのリリースをより小さなものに分割し、定期的にロールアウトすることを推奨している。リリースに含まれる変更が小さいほど、ロールバックの可能性も減る。<a href="https://landing.google.com/sre/workbook/chapters/canarying-releases/">SRE Workbook の Figure 16-1</a> にある "virtuous cycle"(好循環)を参照。</p> <p>同様に、コンテナやマイクロサービスを用いることで、パッチを当てるべき境界面を減らすことができる。</p> <h4>Use Containers</h4> <p>コンテナは、あなたのアプリケーションに必要なバイナリとライブラリを、その下にあるホスト OS と切り離し、依存関係を減らす。コンテナレジストリを更新したら、その更新後のコンテナが自動的にロールアウトされていく。</p> <p>脆弱性が発生した場合は、コンテナそのものではなく、コンテナイメージをスキャンすることで影響範囲を特定できる。パッチがあたっていない古いイメージがデプロイされないように、本番環境には最新のイメージのみデプロイされるように強制すべきである。</p> <p>コンテナに関連する話題は、SRE 本の Chapter 7 の "Case Study 4: Running Hundreds of Microservices on a Shared Platform"、および SRE workbook の Chapter 16(blue/green deployment によるパッチ当ての話)にある。</p> <h4>Use Microservices</h4> <p>マイクロサービス化することで、それぞれのマイクロサービスをスケールアウト、負荷分散、ロールアウトできる。つまりインフラの変更を柔軟に行えるようになる。</p> <p>マイクロサービス化すると、あらゆるトラフィックがそこを流れるようになるので、limited or zero trusted network が必要になる。マイクロサービス化により、チーム間で共通のライブラリやインフラを使うようになる。そのライブラリやインフラを少数の責任者が更新・管理する。望ましいセキュリティ特性を維持するために、できるだけサービスをシンプルにすることを保証するための制約が必要になる(※本書の Chapter 6 で取り上げられていた話題)。</p> <h5>Example: Google’s frontend design</h5> <p>Google のフロントエンドデザインは、回復性と多層防御(defense in depth)を実現するためにマイクロサービスを用いている。</p> <p>Google Front End (GFE) は、Google サービスに対するフロントエンド層を提供する。ほとんどの Google サービスはバックエンド層のマイクロサービスとして実装されていて、インターネットに直接公開されていない。</p> <p>GFE は外部からの通信を終端し、DDoS対策や、ルーティングや、ロードバランシングを提供する。また、個々の開発チームが苦労することなく、新しいセキュリティ機能を導入できる。例えば、Google セキュリティチームが Application Layer Transport Security (ALTS) ライブラリを、自社の RPC ライブラリに組み込むことで、ALTS サポートを迅速に広範囲へ適用できた。</p> <p>また、バックエンド層とフロントエンド層は、その内部にまた複数のレイヤーを持つことができる。そのそれぞれのレイヤーで負荷分散できる。このようなアーキテクチャにより、それぞれのレイヤーへの変更が適用しやすくなっている。</p> <h3>Different Changes: Different Speeds, Different Timelines</h3> <p>すべての変更が同じタイムライン、または同じ速度で発生するわけではない。以下に示す複数の要素が、変更をどれくらいの速さで更新する必要があるかに影響する。</p> <ul> <li>Severity (重大性)</li> <li>Dependent systems and teams <ul> <li>他の人の作業を待つ必要があるケース(ベンダーのパッチ提供、顧客側のクライアントへのパッチ適用など)</li> </ul> </li> <li>Sensitivity (※何と訳すべき? 感度?) <ul> <li>※Severity との違いがよくわからなかった。セール期間のような重要なイベント中は変更を後回しにしたいと思うかもしれない、という話が書かれているので、客観的な重大性ではなくて、自分たちの事情と比較した上での緊急性という意味?</li> </ul> </li> <li>Deadline <ul> <li>法規制などによる、明確な期限がある場合</li> <li>脆弱性情報の報道規制(embargo)の期間が終わるまでにパッチを当てなければいけない場合</li> </ul> </li> </ul> <p>以下の節では、タイムラインが異なる事例を3つ紹介する。</p> <ul> <li>短期の変更:新しいセキュリティ脆弱性への対応</li> <li>中期の変更:新しいプロダクトの段階的な適用</li> <li>長期の変更:規制上の理由による変更(その変更を実装するために Google は新しいシステムを作る必要があったもの)</li> </ul> <h4>Short-Term Change: Zero-Day Vulnerability</h4> <p>Shellshock(bash の脆弱性)の事例。</p> <p>Shellshock に対して、Googleのインシデントレスポンスチームはこの例外的な脆弱性を解決するために Black Swan protocol (?) を開始し、以下を行うための大規模な対応を調整した。</p> <ul> <li>Identify the systems in scope and the relative risk level for each</li> <li>Communicate internally to all teams that were potentially affected</li> <li>Patch all vulnerable systems as quickly as possible</li> <li>Communicate our actions, including remediation plans, externally to partners and customers</li> </ul> <p>この対応と並行して、インシデントレスポンスチームは、Google のネットワーク境界内にある脆弱なシステムを検知するためのソフトウェアを開発した。そして、このソフトウェアを、残りのパッチ作業を完了させるために用いるだけでなく、Google の標準セキュリティ監視の機能に追加した。</p> <p>この対応中に実施したこと(およびしなかったこと)から、他のチームや組織にも適用できるいくつかの教訓が得られた:</p> <ul> <li>Standardize software distribution to the greatest extent possible (ソフトウェアの配布を可能な限り標準化する)</li> <li>Use public distribution standards (?) <ul> <li>※読んでも、何を指しているのかわからなかった</li> </ul> </li> <li>Ensure that you can accelerate your mechanism to push changes for emergency changes (緊急時の変更のために、自分たちの変更適用メカニズムを高速化できるかどうか確認する) <ul> <li>例えば、validation をスキップするなどして高速化できるか?</li> </ul> </li> <li>Make sure that you have monitoring to track the progress of your rollout, that you identify unpatched systems, and that you identify where you’re still vulnerable (ロールアウトの進捗を監視し、パッチが当てられていない=まだ脆弱性のあるシステムを特定できるようにする)</li> <li>Prepare external communications as early in your response efforts as possible (脆弱性対応のできるだけ早い段階で、外部とのコミュニケーションを準備する)</li> <li>Draft a reusable incident or vulnerability response plan (再利用可能なインシデントや脆弱性対応計画の作成)</li> <li>Know which systems are nonstandard or need special attention (どのシステムが標準に従っていないか、または特別な対応を必要とするかを知る)</li> </ul> <h4>Medium-Term Change: Improvement to Security Posture</h4> <p>FIDO セキュリティキーを用いた二要素認証の事例。</p> <p>変更のロールアウトに関しては、2つの対立する哲学がある。</p> <ul> <li>Start with the easiest use case, where you’ll get the most traction and prove value.</li> <li>Start with the hardest use case, where you’ll find the most bugs and edge cases.</li> </ul> <p>組織内での賛同をまだ十分に得られていないなら、最も簡単なユースケースから始めることに意味がある。組織の上層部からすでに十分な支持が得られているなら、最も難しいユースケースから始めて、バグや課題を早期に発見したほうがいい。</p> <p>Phishing 対策として、Google 社内では二要素認証の調査およびテストを2011年に開始した。さまざまな選択肢を考慮したのち、Google は FIDO セキュリティキーを共同設計した。そして、OTP の代わりに FIDO セキュリティキーを導入する活動を2013年から開始した。</p> <p>社内への展開はセルフサービス的に行った。最初は、志願してこの機能をオプトインしたユーザーから導入した。このデバイスは、各オフィスにある TechStop location(ヘルプデスク)から入手しやすくした。</p> <p>それと同時に、セキュリティチームは FIDO 対応が必要なアプリケーションの長いリストに対応した。2015年にロールアウトの完了と、OTP サービスの廃止に集中し始め、2015年内に対応を完了した。</p> <p>この経験から得られた教訓は、セキュリティ及び信頼性に関する文化を作ることに関係するものだった。</p> <ul> <li>Make sure the solution you choose works for all users. (そのソリューションを、すべてのユーザーが利用できるものにする)</li> <li>Make the change easy to learn and as effortless as possible. (その変更内容を、学びやすく、できるだけ苦労せずに済むものにする)</li> <li>Make the change self-service in order to minimize the burden on a central IT team. (中央集中的な IT チームの負荷を最小化するために、その変更を、セルフサービス可能なものにする)</li> <li>Give the user tangible proof that the solution works and is in their best interest. (そのソリューションが動作し、自分たちの利益になることを、実際に触れて確認できる証拠を提供する)</li> <li>Make the feedback loop on policy noncompliance as fast as possible. (ポリシーに準拠していないことを、できるだけ早く気付けるようなフィードバックループを作る)</li> <li>Track progress and determine how to address the long tail. (進捗を計測し、ロングテールをどのように解決するかを決定する)</li> </ul> <h4>Long-Term Change: External Demand</h4> <p>Google Chrome チーム、Let's Encrypt およびその他の組織による努力により、HTTPS の利用率が増加した事例。</p> <p>長期の変更では、きちんとしたドキュメンテーションと、進捗の計測&可視化の自動化が必要。長期に渡るプロジェクトでは、担当者が途中で会社を去る可能性がある。</p> <p>作業にはロングテール(変更が行き届かない部分)がある。全体の80〜90%に適用できたら、それはセキュリティリスクの削減に対する計測可能なインパクトを持つため、成功したとみなされるべきだろう。</p> <p>ここから得られた教訓:</p> <ul> <li>Understand the ecosystem before committing to a strategy.</li> <li>Overcommunicate to maximize reach.</li> <li>Tie security changes to business incentives.</li> <li>Build an industry consensus.</li> </ul> <h3>Complications: When Plans Change</h3> <p>変更計画を変更して、変更を加速させたり、遅らせなければいけなくなる潜在的な理由:</p> <ul> <li>You might need to delay a change based on external factors.</li> <li>You might need to speed up a change based on a public announcement.</li> <li>You might not be severely impacted.</li> <li>You might be dependent on external parties.</li> </ul> <p>Heartbleed(OpenSSL の脆弱性)は、キャッチーなロゴと名前で、予想外にメディアの衆目を集めた脆弱性だった。そのため、当初の計画より、パッチの適用を加速させる必要が生じた。</p> <p>Heartbleed の事例からは、いくつかの重要な教訓が得られた:</p> <ul> <li>Plan for the worst-case scenario of the embargo breaking or being lifted early.</li> <li>Prepare for rapid deployment at scale.</li> <li>Regularly rotate your encryption keys and other secrets. <ul> <li>SRE workbook の Chapter 9 も参照</li> </ul> </li> <li>Make sure you have a communication channel to your end users—both internal and external.</li> </ul> <h2>ここまでの感想</h2> <p>次にセキュリティ変更を行うタイミングがあったら、読み返して、計画立案の参考にしたいと思える内容でした。</p> <p>セキュリティ変更を行う際には事前に計画を行い、それが短期〜長期のいずれに該当するかによって適切なアプローチが変わる、ということを事例とともに説明していて説得力がありました。また、変更がロールアウトされた範囲を自動的に検出可能にする(検出のために人手を挟まないようにする)ことで、各開発チームが自律的にセキュリティ変更を進められるようにするというのは、良いプラクティスだと思いました。今後うまく適用できそうな機会があれば、是非試して見たいです。</p> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 6 hatenablog://entry/26006613605499608 2020-07-28T00:26:50+09:00 2020-07-28T00:34:42+09:00 月一連載になっている SRS 本の読書メモです。 Chapter 6 の "Design for Understandability" は、最初にタイトルを見たときから気になっている章でした。実際読んでみて、勉強になる考え方が多かったです。 じっくり英訳しようとすると全然先に進めなくなってしまうので、今回から若干翻訳の手を抜いて、ほとんど意訳で書いてるのと、一部は英語のまま引用してます。また、細部はかなり省略してしまってます。興味が湧いた部分については原文をあたってみてください。 本章で頻出する "Understandability" という単語は、以下のメモでは「わかりやすさ」と訳しました。… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>月一連載になっている SRS 本の読書メモです。</p> <p>Chapter 6 の "Design for Understandability" は、最初にタイトルを見たときから気になっている章でした。実際読んでみて、勉強になる考え方が多かったです。</p> <p>じっくり英訳しようとすると全然先に進めなくなってしまうので、今回から若干翻訳の手を抜いて、ほとんど意訳で書いてるのと、一部は英語のまま引用してます。また、細部はかなり省略してしまってます。興味が湧いた部分については原文をあたってみてください。</p> <p>本章で頻出する "Understandability" という単語は、以下のメモでは「わかりやすさ」と訳しました。「理解可能性」のように訳したほうがいいかとも思ったのですが、文章が固くなりすぎるように感じたので、このメモでは「わかりやすさ」にしました。</p> <p>また、本章には、"reason about" という表現も頻出します。これは「すべてのコードを深く読んで理解しなくても、システムの不変条件やメンタルモデルからそのことを説明できる」というような意味で使われています。適切な訳という自信はありませんが、以下では「論証する」と訳しました。</p> <h2>SRS 本について</h2> <p>SRS 本はこちらから無償でダウンロードできます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>前回までの読書メモは <a href="https://muziyoshiz.hatenablog.com/archive/category/SRS%20Book">SRS Book タグ</a> を参照のこと。</p> <h2>Chapter 6. Design for Understandability</h2> <p>本章では、システムのわかりやすさ(understandability)について議論する。</p> <p>最初に、不変条件(invariants)とメンタルモデル(mental models)に従って、あなたのシステムを分析し、理解する方法についての議論から始める。そして、アイデンティティ、認可、アクセス制御のための標準フレームワークに基づく階層化されたシステムアーキテクチャが、わかりやすいシステムの設計を助けることを示す。</p> <p>そして、セキュリティ境界(security boundaries)に関する話題を題材として、どのようにソフトウェア設計(特に、アプリケーションフレームワークとAPIの利用)が、セキュリティおよび信頼性に関する特性(security and reliability properties)に対する論証(reason about)を助けるかを示す。</p> <p>本書では、システムのわかりやすさ(understandability)とは、関連分野の専門知識を持つ人が、以下の両方を、正確かつ自信を持って論証できる度合いと定義する。</p> <ul> <li>The operational behavior of the system(システムの運用上の振る舞い)</li> <li>The system’s invariants, including security and availability(セキュリティや可用性を含む、システムの不変条件)</li> </ul> <h3>Why Is Understandability Important?</h3> <p>わかりやすいシステム(understandable system)を設計し、そのわかりやすさを維持するには努力を要する。わかりやすいシステムは、プロジェクトのベロシティを維持するという(4章で示した)利点もあるが、それ以上に、以下のような明確な利点がある。</p> <ul> <li>Decreases the likelihood of security vulnerabilities or resilience failures <ul> <li>わかりにくいシステムでは、修正時にバグや脆弱性を生みやすい。またそれらに気づきにくい</li> </ul> </li> <li>Facilitates effective incident response <ul> <li>わかりにくいシステムは、インシデント発生時の対応〜根本原因の解決を妨げる</li> </ul> </li> <li>Increases confidence in assertions about a system’s security posture <ul> <li>システムのセキュリティに対するアサーション(表明)は、一般に、不変条件(invariants)と呼ばれる。不変条件とは、そのシステムの、すべてのありうる振る舞いに対して成立しなければならない特性(property)のことである</li> <li>例えば、外部からの入力(悪意あるものを含む)に対して必ず特定の検査が行われる、というのは不変条件である。そのような抽象化がなければ、システムが外部からの入力に対して安全かどうかの論証が難しい</li> </ul> </li> </ul> <h4>System Invariants</h4> <p>システムの不変条件(system invariant)とは、そのシステムを取り巻く環境が正しく振る舞うか間違って振る舞うかに関係なく、常に真である特性のこと。ここで言う環境は、あなたが直接コントロールできないものもすべて含む。</p> <p>以下は、セキュリティと信頼性に関する望ましい特性の例:</p> <ul> <li>Only authenticated and properly authorized users can access a system’s persistent data store.</li> <li>All operations on sensitive data in a system’s persistent data store are recorded in an audit log in accordance with the system’s auditing policy.</li> <li>All values received from outside a system’s trust boundary are appropriately validated or encoded before being passed to APIs that are prone to injection vulnerabilities (e.g., SQL query APIs or APIs for constructing HTML markup).</li> <li>The number of queries received by a system’s backend scales relative to the number of queries received by the system’s frontend.</li> <li>If a system’s backend fails to respond to a query after a predetermined amount of time, the system’s frontend <a href="https://landing.google.com/sre/sre-book/chapters/addressing-cascading-failures/#xref_cascading-failure_load-shed-graceful-degredation">gracefully degrades</a>—for example, by responding with an approximate answer.</li> <li>When the load on any component is greater than that component can handle, in order to reduce the risk of cascading failure, that component will serve overload errors rather than crashing.</li> <li>A system can only receive RPCs from a set of designated systems and can only send RPCs to a set of designated systems.</li> </ul> <p>あなたのシステムがこれらの望ましいセキュリティ特性に反している、つまり不変条件が実際には不変条件ではない、という場合には、そのシステムはセキュリティ上の弱点や脆弱性を持つということになる。</p> <p>上記リストの4番目にあるような、信頼性に関する特性についても同様である。フロントエンドが外部から受け取った以上のリクエストを、バックエンドに対して生成するようなシステムは、可用性に関する潜在的な弱点を持つといえる。</p> <h4>Analyzing Invariants</h4> <p>意図した特性が実際に不変条件として成立しているかは、解析しないとわからない。不変条件が成立していないことによって起こりうる悪影響と、不変条件が成立するかを検証するために割く労力は、トレードオフの関係にある。</p> <p>両極端な例を上げると、例えば少しのテストとバグチェックのためのソースコードレビューをするくらいでは、不変条件の違反を見逃す恐れがある。一方で、マイクロカーネルの実装で行われているように、セキュリティ特性を形式論理で証明できれば完璧だが、そのようなことを大規模なアプリケーション開発に適用するのは難しい。</p> <p>本章では、その両極端な例の間にある、現実的な妥協案を示す。わかりやすさについての明確な目標を持ってシステムを設計することで、システムが特定の不変条件を満たすことを(形式的にとまではいかなくても)原理的に示すことができ、それらのアサーションをかなり高い度合いで信頼できる。Google では、このアプローチが、大規模ソフトウェア開発に対して実用的で、かつよくある種類の脆弱性の発生を効果的に減らすことができることを発見した。テストと検証についての詳細は Chapter 13 で示す。</p> <h4>Mental Models</h4> <p>複雑なシステムをそのまま全体的に理解することは難しいため、エンジニアや特定分野のエキスパートは、不必要な詳細を省いたメンタルモデルを構築する。複雑なシステムでは、メンタルモデルが複数になることもある。</p> <p>メンタルモデルは有用だが、限界もある。もし、典型的な運用シナリオに基づいてメンタルモデルを作ったら、それは通常でない場合のシナリオでのシステムの振る舞いの予測には使えない。</p> <p>例えば、通常はリクエスト数の増加に応じて段階的に負荷が増えるシステムが、ある閾値を超えると、全く違う振る舞いを見せることがある。そのようなシステムでは、単純すぎるメンタルモデルは、トラブルシューティングを阻害する。</p> <p>極端な状況、または通常でない状況でも、システムが予測可能な振る舞いをして、メンタルモデルが保たれるようにシステムを設計すべきである。そのようなシステムであれば、障害発生時にも、そのメンタルモデルは有用なままになる。</p> <p>※本文ではメモリのスラッシングを例に挙げて、システムの振る舞いを予測可能にする方法を例示している。</p> <h3>Designing Understandable Systems</h3> <p>この章の残りでは、システムをよりわかりやすくし、そのシステムが日々進化するなかでもわかりやすさを維持し続けるために使える、いくつかの具体的な指標について議論する。</p> <h4>Complexity Versus Understandability</h4> <p>わかりやすさに対する最初の敵は、管理されていない複雑さ(unmanaged complexity)である</p> <p>いくつかの複雑さは、現在のソフトウェアシステム(特に分散システム)の規模と、それらのシステムが解決する問題による生来のもので、回避できない。Google では数万のエンジニアが、10億行を超えるコードを含むソースコードリポジトリを編集しているが、そこまでの規模でない組織でも、1つのプロダクトで数百を超える機能を提供することはざらにあるだろう。</p> <p>例えば、Gmail は多くの機能を提供している(p.94 のリスト)。このように多数の機能を提供するシステムは、機能がより少ないシステムよりも本質的に複雑である。しかしこれらの機能は価値を生み出しているので、複雑さを下げるためにそれらの機能を削除しろとは言えない。私達がそれらの複雑さを管理できれば、システムを十分にセキュアかつ高信頼にすることができる。</p> <p>私達の目標は、この本質的な複雑さをより小さい部品・コンパートメントに分割して含むように、システムの設計を構成することである。そして、それは具体的かつ重要なシステム特性や振る舞い(specific, relevant system properties and behaviors)を、高い確度で人間が論証できるような方法で行わなければならない。言い換えると、私達はわかりやすさの観点に立って、複雑さという特性を管理しなければならない。(※なんとなく言いたいことはわかるがうまく訳せない)</p> <p>本書ではセキュリティと信頼性の観点で、わかりやすさについて議論している。しかし、私達が議論するパターンの話は、この2つの観点に限ったものではなく、一般的なソフトウェア設計テクニック全般に渡る。システム及びソフトウェア設計に関する全般的な読み物としては、<a href="https://www.amazon.co.jp/Philosophy-Software-Design-John-Ousterhout/dp/1732102201">John Ousterhout の A Philosophy of Software Design</a> を参照のこと。</p> <h4>Breaking Down Complexity</h4> <p>複雑なシステムの振る舞いのすべての側面を理解するためには、巨大な1個のメンタルモデルを内面化して維持する必要がある。しかし、そのようなことは人間には難しい。</p> <p>システムを複数の小さなコンポーネントにわけて、それを組み合わせることで、システムをわかりやすくすることができる。そして、個々のコンポーネントの特性を論証可能にして、そこからシステム全体の特性を引き出せるようにする。</p> <p>このアプローチは、現実には単純明快ではない。そのようなことが可能かどうかは、そのシステム全体がどのように複数のコンポーネントへと分解されているか、そしてそれらのコンポーネント間のインターフェイスと信頼関係の性質に依存する。この点については p.97 からの "System Architecture" にて見ていく。</p> <h4>Centralized Responsibility for Security and Reliability Requirements</h4> <p>セキュリティおよび信頼性に関する要求(例えば何らかのチェック処理)を個々のコンポーネントで実装していたら、そのシステム全体がそれらの要求を満たしているか判断するのは難しい。</p> <p>Chapter 4 で議論したように、そのような共通タスクを実装する責任は、その組織共通のコンポーネント(ライブラリやフレームワーク)に集約させることができる。</p> <p>例えば、サービスで共通して必要なセキュリティ機能(認証、認可、ロギング)は RPC サービスフレームワークが実装する。また、信頼性に関する機能(リクエストのタイムアウトなど)も RPC サービスフレームワークに任せる。</p> <p>セキュリティと信頼性に関する要求に関する責任を1箇所に集中させることで、以下の利点が得られる。</p> <ul> <li>Improved understandability of the system <ul> <li>レビュアーは、システムの1箇所を見るだけで、セキュリティおよび信頼性に関する要求が満たされているかどうかを判断できる</li> </ul> </li> <li>Increased likelihood that the resulting system is actually correct <ul> <li>アプリケーション上での要求のアドホックな実装が間違っていたり、実装し忘れている可能性について考えずに済むようになる</li> </ul> </li> </ul> <h3>System Architecture</h3> <p>システムを複数のレイヤーとコンポーネントに分割することは、複雑さを管理するためのキーツールである。</p> <p>しかし、この分割をどのように行うかは、慎重に考える必要がある。もしコンポーネント同士が密結合していたら、モノリシックシステムと同様に、理解が難しいシステムになってしまう。システムをわかりやすくするためには、境界とインターフェイスに注意を払う必要がある。</p> <p>経験豊富なソフトウェアエンジニアは、外部の環境から来た入力は信頼すべきでなく、それらの入力についてシステムはなんの仮定も置いてはいけない、ということを知っている。その一方で、システム内部からの呼び出しについては信頼し、想定通りの呼び出し方をされると期待しがちである。</p> <p>しかし、システムのセキュリティ特性が実現されるかどうかは、実際にはシステム内部からの入力が正しいかどうかに依存する。そのため、セキュリティ特性を論証可能にするためには、システム内部からの呼び出しについてもなんの仮定も置けない。</p> <p>コンポーネントが呼び出し元に対して置く仮定を減らせば減らすほど、そのコンポーネントの特性の論証が容易になる。理想的には、そのような仮定は全く無くしたい。</p> <p>もし、呼び出し元について仮定を置くことを強制される場合は、その仮定を、インターフェイスの設計に明示的に加える事が重要である。例えば、呼び出し元のプリンシパルを制限する。</p> <h4>Understandable Interface Specifications</h4> <p>構造化されたインターフェイス(structured interfaces)、一貫したオブジェクトモデル(consistent object models)、そして冪等なオペレーション(idempotent operations)は、システムのわかりやすさに貢献する。</p> <ul> <li>Prefer narrow interfaces that offer less room for interpretation <ul> <li>フレームワークは、RPC メソッドの入出力に対する型定義の機能を(gRPC, Thrift, OpenAPI のように)持っていたほうがいい</li> <li>OpenAPI や Protocol buffer が持つようなバージョニング機能の有無は、将来のアップグレードのしやすさに影響する(<a href="https://developers.google.com/protocol-buffers/docs/proto#updating">アップデートに関する Protocol buffer のガイドライン</a>)</li> <li>任意の文字列(JSON の string 型)を受け付けるような API は、入出力が制約されないため、わかりやすさを損ないやすい。また、例えばクライアントとサーバが別のタイミングでアップデートされるときに、片方の処理を壊すことがありうる</li> <li>明確な API 仕様がないと、例えば <a href="https://istio.io/latest/docs/reference/config/security/authorization-policy/">Istio Authorization Policy</a> のような認可フレームワーク上のポリシーと、サービスが公開する実際の境界面(actual surface area)を関連付けるための、自動的なセキュリティ監査システムの構築は難しくなる</li> </ul> </li> <li>Prefer interfaces that enforce a common object model <ul> <li>複数のタイプのリソースを管理するシステムは、<a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/">Kubernetes Objects</a> のような共通オブジェクトモデル(common object model)から恩恵を得られる</li> <li>そのオブジェクトで各リソースを取り扱えるようになるだけでなく、エンジニアが巨大なシステムを理解するのに役立つ単一のメンタルモデルを提供する(p.99 にその利点についての箇条書きあり)</li> <li>Google は <a href="https://cloud.google.com/apis/design/resources">resource-oriented APIs を設計するための一般的なガイドライン</a> を公開している</li> </ul> </li> <li>Pay attention to idempotent operations <ul> <li>API 呼び出しは失敗したり、成功したあとでその応答が届かないことがある。API が冪等(idempotent)であれば、呼び出し元は再実行すればいい。もし、冪等でなければ、呼び出し結果を確認するためのポーリングが必要になる</li> <li>冪等性は、エンジニアのメンタルモデルにも影響する。例えば、エンジニアがなにかデータを作成する API を冪等だと思って呼び出しているのに、実際にはそうでなかった場合、そのデータが意図せず重複して作られる、ということが起こりうる</li> <li>本質的に冪等でない処理であっても、サーバ側で冪等にすることができる。上記の例では、リクエストに一意な識別子(例:UUID)を含めることで、2回目の API 呼び出しをサーバ側で検出して、重複したデータの作成を防げる</li> </ul> </li> </ul> <h4>Understandable Identities, Authentication, and Access Control</h4> <p>どんなシステムでも、機密性の高い(highly sensitive)リソースに、誰がアクセスしたかは特定できるようにすべきである。例えば課金システムでは、PII(personally identifiable information)データに、社内の誰がアクセスしたかを、監査できる必要がある。監査フレームワークは、アクセスのログを取り、そのログを自動的に解析し、定期的なチェックや、インシデント調査に活用できるべきである。</p> <h5>Identities</h5> <p>アイデンティティ(identity)とは、属性の集合、またはあるエンティティに関連する識別子のことである。クレデンシャル(credentials)は、特定のエンティティのアイデンティティを主張する。クレデンシャルは、認証プロトコル(authentication protocol)を使って送信される。</p> <p>システムがどのように人間のエンティティ(顧客および管理者)識別するかを論証することは相対的に簡単な一方で、巨大なシステムは人間以外のエンティティも識別できる必要がある。マイクロサービスの集合から構成された巨大システムは、人が介在する場合もしない場合も含めて、相互に呼び出し合う。エンティティには、人、ソフトウェアコンポーネント、ハードウェアコンポーネントが含まれる。</p> <p>一般に、アイデンティティと認証のサブシステム(identity and authentication subsystems)は、アイデンティティのモデル化と、それらのアイデンティティを表すためのクレデンシャルの提供に責任を持つ。アイデンティティが意味があるもの("meaningful")であるためには、以下の条件を満たす必要がある。</p> <ul> <li>Have understandable identifiers <ul> <li>人間にとってわかりやすい文字列であること(例:<code>widget-store-frontend-prod</code> のような文字列)</li> <li>わかりやすい文字列には、設定ミスを防げたり、異常なアクセスにすぐ気づけたりするメリットがある</li> <li>これが <code>24245223</code> のような無意味な数字だと、間違った設定をしていても気づけない</li> </ul> </li> <li>Be robust against spoofing <ul> <li>ID/password を clear-text channel でやり取りするようなものは簡単に spoofing できてしまう</li> </ul> </li> <li>Have nonreusable identifiers <ul> <li>例えば、社員のメールアドレスを管理ツールのアイデンティティに使っていて、その管理者が退職したあとで同じメールアドレスを新入社員に割り当てたら、いろいろな権限が渡ってしまう可能性がある</li> </ul> </li> </ul> <p>意味のあるアイデンティティを、システム上のすべてのアクティブなエンティティに割り当てることが、わかりやすさへの基本的な第一歩である。組織内で統一されたアイデンティティシステム(organization-wide identity system)は、エンティティを参照するための共通の方法を提供し、全従業員が共通のメンタルモデルを持つことを助ける。</p> <h5>Example: Identity model for the Google production system.</h5> <p>例として、Google のシステムでは、異なる種類のアクティブなエンティティを以下のように分類している。</p> <ul> <li>Administrators <ul> <li>システムの状態を変更する(例えば新しいリリースを行ったり、設定を変更する)権限を持つエンジニア</li> <li>Administrator は、システムの状態を直接変更せず、そのような一連のワークロードを起動する</li> <li>そのアイデンティティは global directory service で管理されて、シングルサインオンに使われる</li> </ul> </li> <li>Machines <ul> <li>Google データセンタ内の物理マシン</li> <li>global inventory service/machine database で管理されている</li> <li>Google プロダクション環境では、マシンは DNS 名で解決可能</li> <li>そのマシン上で動作するソフトウェアの修正権限を表すために、administrators と machines の間の関連を管理する</li> </ul> </li> <li>Workloads <ul> <li>Borg オーケストレーションによってスケジューリングされたワークロード</li> <li>ワークロードと、それが動作するマシンのアイデンティティは、大抵の場合異なる</li> <li>オーケストレーションシステムは、ワークロードと、それが動作可能なマシンの関係(制約)を強制する</li> </ul> </li> <li>Customers <ul> <li>Google が提供するサービスにアクセスする顧客</li> <li>Customers のアイデンティティは、専用のアイデンティティサブシステムで管理される</li> <li>Google は <a href="https://developers.google.com/identity/protocols/oauth2/openid-connect">OpenID Connect workflows</a> を提供しており、顧客は Google identity を、Google 外のエンドポイントで使えるようにしている</li> </ul> </li> </ul> <h5>Authentication and transport security</h5> <p>認証およびトランスポートセキュリティの分野は難しいので、すべてのエンジニアが完全に理解することは期待できない。その代わりに、それらの抽象化とAPIを理解すべき。</p> <p>Google ではエンジニアに <a href="https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/">Application Layer Transport Security (ALTS)</a> を提供している。ALTS は、以下のようなシンプルなメンタルモデルを提供する。</p> <ul> <li>An application is run as a meaningful identity: <ul> <li>A tool on an administrator’s workstation to access production typically runs as that administrator’s identity.</li> <li>A privileged process on a machine typically runs as that machine’s identity.</li> <li>An application deployed as a workload using an orchestration framework typ‐ ically runs as a workload identity specific to the environment and service pro‐ vided (such as myservice-frontend-prod).</li> </ul> </li> <li>ALTS provides zero-config transport security on the wire.</li> <li>An API for common access control frameworks retrieves authenticated peer information.</li> </ul> <p>ALTS に類似のシステムとして、<a href="https://istio.io/latest/docs/concepts/security/#authentication">Istio のセキュリティモデル</a> がある。</p> <p>このようなシステムがない場合、セキュリティ対策が正しく行われるか確認するためには、すべてのアプリケーションコードに目を通す必要が出てきてしまう。</p> <h5>Access control</h5> <p>アクセス制御の部分をフレームワークで提供することは、システム全体のわかりやすさを大きく向上させる。フレームワークはアクセス制御に関する共通の知識、共通の方法をエンジニアに提供する。</p> <p>フレームワークは、複数のコンポーネント(Ingress → Frontend → Backend)を渡るワークロードに対するアクセス権限、といった難しい問題の扱いを助けることができる。このようなワークロードチェインでは、リクエストを送った Customer の権限と、ワークロードを実行する Machine の権限があり、両方を考慮する必要がある。</p> <h4>Security Boundaries</h4> <p>あるシステムの信頼されたコンピューティングベース(trusted computing base, TCB)とは、「セキュリティポリシーが適用されることを確実にするのに十分な正確な機能を持つ(ハードウェア、ソフトウェア、人間、...)の集合であり、より端的に言えば、その失敗がセキュリティポリシーの違反を引き起こす可能性があるもの」である(Anderson, Ross J. 2008. Security Engineering: A Guide to Building Dependable Distributed Systems. Hoboken, NJ: Wiley. からの引用)。</p> <p>TCB と「それ以外のすべて」の間のインターフェイスを、セキュリティ境界(security boundary)と呼ぶ。TCB は、そのセキュリティ境界を超えてくるすべての入力を、信頼できないものとして扱わなければならない。</p> <p>Chapter 4 の web application(ウィジェット販売サイト)を例に挙げる。このサイトは発送先住所を扱う。1個のサーバがすべての機能を提供するモノリシックシステムでは、発送先住所の TCB(TCB_AddressData)はそのシステム全体になる。例えば、発送先住所とは関係ない機能(例えばカタログ検索機能)に SQL インジェクション脆弱性があると、それは即座に発送先住所の漏洩に繋がってしまう。</p> <p>※ 以下の TCB の具体例については、図を見たほうがわかりやすいと思う。p.107 以降を参照のこと。</p> <p>アプリケーションをマイクロサービスに分割することで、TCB を小さくし、セキュリティを改善することができる。上記の例では、カタログ検索機能のバックエンドおよびデータベースを、(発送先住所を含む)販売機能のバックエンドおよびデータベースと分けることで、発送先住所の TCB を小さくできる。</p> <p>ただ、このようにマイクロサービスに分割しても、フロントエンドに全ユーザーの発送先住所を表示できる機能の実装を許すと、TCB の範囲は web frontend まで広がる。Web frontend の脆弱性が、全ユーザーの発送先住所の漏洩に繋がるためである。</p> <p>フロントエンドに強すぎる権限を与える代わりに、フロントエンドとバックエンドの間で、OAuth2 のトークンのような <a href="https://cloud.google.com/security/beyondprod/#google%E2%80%99s_internal_security_services">エンドユーザーコンテキストチケット(EUC)</a> をやり取りするという方法がある。この方法では、フロントエンドは任意のユーザーの EUC を取得することができず、フロントエンドの脆弱性があっても、攻撃者がアクセスできるデータは限定される。</p> <p>また、カタログ検索機能と販売機能のフロントエンドが同一のドメインで動いていたら、片方の XSS 脆弱性が、もう一方にも影響してしまう。つまり TCB は再びシステム全体にまで広がってしまう。両者のフロントエンドが別ドメインで動いていれば、TCB は狭まる。</p> <p>TCB にはセキュリティ上の利点だけでなく、システムをわかりやすくするというメリットもある。TCB として成り立つことを示すためには、コンポーネントはそれ以外の部分から独立していなければならない。そのためには、コンポーネントは明確に定義された、きれいなインターフェイスを持たなければならない。もし、コンポーネントの正しさが、そのコンポーネント外の環境に対する仮定に依存するなら、それは定義上 TCB とは言えない。</p> <p>TCB はしばしばそれ自身の failure domain を持ち、バグの発生や DoS 攻撃、またはその他の運用上の影響に対して、どのように振る舞えばいいかについての理解を与える。Chapter 8 で、システムを区分することによる利点について、さらに詳しく議論する。</p> <h3>Software Design</h3> <p>巨大なシステムを一度、セキュリティ境界によって区分された複数のコンポーネントによって構造化したあとも、あなたはそのすべてのコードとサブコンポーネントを引き続き論証し続ける必要がある。そして大抵の場合、分割後のコードも十分に巨大かつ複雑なソフトウェアになる。</p> <p>この節では、不変条件を、より小さいソフトウェアコンポーネント(モジュールやライブラリ、API)のレベルでさらに論証できるように、ソフトウェアを構成するための技術について議論する。</p> <h4>Using Application Frameworks for Service-Wide Requirements</h4> <p>これまでに議論したように、フレームワークは再利用可能な機能の部品を提供する。あるシステムは、認証フレームワーク、認可フレームワーク、RPC フレームワーク、オーケストレーションフレームワーク、監視フレームワーク、ソフトウェアリリースフレームワーク、などなど……から成るということがありうる。これらのフレームワークは柔軟性を持つが、柔軟性を持ちすぎる。あり得るフレームワークの組み合わせや、その設定方法は無数にあり、エンジニアを圧倒するほどである。</p> <p>Googleでは、この複雑さを管理するために、より高レベルのフレームワークを作ることが有用だと気づいた。これをGoogleでは "application frameworks" と呼ぶ。あるいは、"full-stack" または "batteries-included frameworks" とも呼ばれる。</p> <p>Application frameworks は、サブフレームワークの標準的なセットを、妥当なデフォルト値と、それらのサブフレームワークが相互動作することの保証とともに提供する。</p> <p>例えば、開発者が自分たちのお気に入りのフレームワークを使った開発したとする。そして、認証のための設定はしたが、認可やアクセス制御のための設定をし忘れるということがありうる。Application framework は、すべてのアプリケーションが有効な(valid)認可ポリシーを持つことを保証し、明示的な許可を持たないすべてのアクセスを拒否するというデフォルト設定を持つ。したがって、設定し忘れのような問題を回避できる。</p> <p>全般的に、application frameworks は、アプリケーション開発者やサービスオーナーが必要とするすべての機能(下記)を有効化および設定するための、こうあるべきという方法(an opinionated way)を提供できなければならない。</p> <ul> <li>Request dispatching, request forwarding, and deadline propagation</li> <li>User input sanitization and locale detection</li> <li>Authentication, authorization, and data access auditing</li> <li>Logging and error reporting</li> <li>Health management, monitoring, and diagnostics</li> <li>Quota enforcement</li> <li>Load balancing and traffic management</li> <li>Binary and configuration deployments</li> <li>Integration, prerelease, and load testing</li> <li>Dashboards and alerting</li> <li>Capacity planning and provisioning</li> <li>Handling of planned infrastructure outages</li> </ul> <p>※ "deadline" は SRE 本では「タイムアウト」と訳されている。deadline propagationは「タイムアウトの伝播」。例えば、全体のタイムアウトが30秒で、あるリクエストで10秒かかったら、後続処理のタイムアウト時間は20秒にする、というように伝播させる。</p> <h4>Understanding Complex Data Flows</h4> <p>多くのセキュリティ特性は、システムの中を流れる値(values)についてのアサーションに依存している。</p> <p>例えば、多くの Web サービスは様々な目的に URL を使っている。URL パラメータは string 型。string 型の値は、その URL が well-formed かどうかに関わらず、その値に関する明示的なアサーションを渡すことができない。したがって、セキュリティ特性を論証するためには、システムのなかで、その文字列が正しく渡されていくかを、上流のコード(upstream code)すべてを読んで理解する必要がある。</p> <p>型を用いれば、検証すべきコードを大幅に減らすことができて、システムをわかりやすくする助けになる。URL を型として表現し、例えば Url.parse() のようなコンストラクタにデータ検証処理を実装すれば、あなたはその Url.parse() のコードを理解するだけでセキュリティ特性を論証できるようになる。</p> <p>このような型の実装は、TCB のように振る舞う(すべての URL が well-formed である、という特性に責任を持つ)。しかし、これはその型(のモジュール)を呼び出す側のコードに悪意がなく、周りの環境に欠陥がある(compromised)状態ではない、という仮定があったうえでの話である。そのような仮定が置けない場合は、セキュリティチームは結果として発生する最悪のシナリオに対処する必要がある(Part IV を参照)。</p> <p>より複雑なセキュリティ特性に対して、型を用いることもできる。例えば、インジェクション脆弱性(XSS または SQL インジェクション)は、外部から渡された信用できない入力に対する検証やエンコーディングに依存する。このような脆弱性を防ぐための効果的な方法の一つが、SQL クエリや HTML マークアップのような injection sink context(※なんて訳せばいい??)で安全に使えるとすでにわかっている値とそうでない値を区別するために、型を使うという方法である。</p> <ul> <li>内部的に、SafeSql または SafeHtml のような型を用意する。安全だと検証される前の String と区別する</li> <li>SQL や HTML を受け取る側が、String ではなく、SafeSql または SafeHtml 型を受け取るようにする</li> <li>引き続き String 型を受け取るかもしれないが、その値の安全性に対してなんのアサーションも持ってはならない</li> </ul> <p>このようにすることで、アプリケーション全体が XSS 脆弱性に対して安全かどうかを調べるためには、type と、type-safe sink API の実装のみを理解すればよくなる。Chapter 12 では、呼び出し元についての仮定をなにも持たずに、型の contract を保証するためのアプローチについて議論する。</p> <h4>Considering API Usability</h4> <p>API の適用および利用が、あなたの組織の開発者とその生産性に与える影響について考えるのは良いアイディアだ。もし API が使いづらければ、開発者はその採用に気乗りせず、動きが遅くなってしまう。</p> <p>Secure-by-construction API(※なんて訳せばいい?? 構造による保証?)は、コードをわかりやすくし、エンジニアがそのアプリケーションのロジックに集中できるようにする、という二重のメリットを持つ。加えて、セキュアなアプローチをあなたの組織文化へと自動的に組み込む。</p> <p>開発者にとって利益のあるライブラリやフレームワーク(secure-by-construction APIs のようなもの)を設計することは、可能である。また、これはセキュリティと信頼性の文化を促進する。</p> <p>例として、エスケープを自動的に行う HTML テンプレートシステムを考える。これは、XSS 脆弱性を起こさないことを保証するセキュリティ不変条件であると同時に、開発者の観点では通常の HTML テンプレートと変わらず利用できる。</p> <p>暗号化技術を正しく使うのはとても難しく、微妙なミスが脆弱性を生むことが多い。そのような経験から、Google では Tink という名前のライブラリを開発した。Tink は、Google が開発するアプリケーション内で、<a href="https://www.usenix.org/sites/default/files/conference/protected-files/hotsec15_slides_green.pdf">暗号化技術を安全に使う</a> ことを簡単にする(間違って使うことを難しくする)ような API を提供する。</p> <p>Tink の設計および開発を導いた原則:</p> <ul> <li>Secure by default</li> <li>Usability</li> <li>Readability and auditability</li> <li>Extensibility</li> <li>Agility</li> <li>Interoperability <ul> <li>Tink is available in many languages and on many platforms.</li> </ul> </li> </ul> <p>通常の暗号化ライブラリは、ローカルディスク上に秘密鍵を持つことを簡単にしているが、そのようなライブラリを使うと、鍵管理に関するインシデントを完全に防ぐことは難しい。対象的に、Tink の API は生の鍵情報(raw key material)を受け付けない。その代わりに、Tink はCloud Key Management Service (KMS)、AWS Key Management Service、Android Keystore のような鍵管理サービスと統合された鍵管理機能を提供することで、鍵管理サービスの利用を促進する。</p> <p>注意点として、データの重要さに合わせて、適切な暗号化方法を選ぶのは Tink を利用するエンジニアの責任である。そのような設計レベルのミスを Tink で防ぐことはできない。ソフトウェア開発者とレビュアーは、セキュリティおよび信頼性に関する特性のうち、ライブラリやフレームワークが保証するものとしないものをしっかり理解しなければならない。</p> <p>Tink に限界があるのと同様に、 secure-by-construction web framework も、XSS 脆弱性を防ぐことはできるが、アプリケーションのビジネスロジックに含まれるセキュリティバグは防げない。</p> <h3>Conclusion</h3> <p>システムのわかりやすさと、信頼性およびセキュリティは深く結びついている。</p> <p>わかりやすいシステムを構築するための私たちからの第一のガイダンスは、システムを、明確かつ限られた目的を持つコンポーネントを用いて構築することである。それらのコンポーネントのなかにはそれぞれの TCB を構成するものもあり、セキュリティリスクへの対応に集中するものもある。</p> <p>また、私達は望ましい特性(例えばセキュリティ不変条件や、構造的な回復力、データ耐久性)を、それらのコンポーネント内やコンポーネント間で強制するための戦略についても議論した。これらの戦略は以下を含む。</p> <ul> <li>Narrow, consistent, typed interfaces: 狭く、一貫性があり、型を持つインターフェイス</li> <li>Consistent and carefully implemented authentication, authorization, and accounting strategies: 一貫性があり、注意深く実装された認証、認可、課金の戦略</li> <li>Clear assignment of identities to active entities, whether they are software com‐ ponents or human administrators: アクティブなエンティティ(ソフトウェアコンポーネントや人間の管理者)に対するアイデンティティの明快な割り当て</li> <li>Application framework libraries and data types that encapsulate security invari‐ ants to ensure that components follow best practices consistently: コンポーネントがベストプラクティスに一貫して従うことを保証するように、セキュリティ不変条件を埋め込んだ、アプリケーションフレームワークライブラリやデータ型</li> </ul> <p>あなたの最も重要なシステムが誤動作したときに、システムのわかりやすさが、それをささいなインシデントにするか、あるいは大災害にするかの明暗を分ける。SRE は自らの職務のために、そのシステムのセキュリティ不変条件を知っておかなければならない。極端なケースでは、SRE はセキュリティインシデントの発生時に、セキュリティのために可用性を犠牲にして、サービスをダウンさせなければならないかもしれない。</p> <h2>ここまでの感想</h2> <p>6章も、5章に続いて読み応えのある内容でした。タイトルにある Understandability(わかりやすさ)という言葉からは予想できなかった、説得力のある議論が次々と続いて、読んでいて飽きませんでした。</p> <p>システムのわかりやすさ(understandability)について、明確な定義がなされていて、正直言って一度読んだだけでは理解しきれてない気がしますが、うまく身につけたら今後役立ちそうです。</p> <p>文中で触れられていた A Philosophy of Software Design は、日本語訳がないようですが、ちょっと読んでみたいですね。検索したところ、日本語の解説記事がいくつかあったので、まずはそのあたりから読んでみます。</p> <ul> <li><a href="https://yshibata.blog.ss-blog.jp/2019-03-12">『A Philosophy of Software Design』:柴田 芳樹 (Yoshiki Shibata):SSブログ</a></li> <li><a href="https://qiita.com/shoichiimamura/items/73f9a9c5d7453273e371">A Philosophy of Software Design:要約 - Qiita</a></li> </ul> <p>詳しい説明のなかでは、通常時と障害発生時でメンタルモデルが変わってしまうとシステムがわかりにくくなる、という指摘は、なるほどと思いました。</p> <p>また、コンポーネントの責務を明確にするというのは、つまり特定の不変条件に対して責任を持つコンポーネントを明確にすることで、その結果、ある不変条件が成立していることを論証するために読むべきコード量が減る、というのはうまい説明方法だと思いました。現実には、なかなかそんなふうにきれいな構造のコードになってないことってありますよね……。この説明方法は、今後うまく活用していきたいです。</p> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 5 hatenablog://entry/26006613587976205 2020-06-21T18:58:30+09:00 2020-06-21T18:58:30+09:00 SRS 本の読書メモの続きです。Chapter 5 はなかなか重たい内容だったので、この章のみでメモを上げます。 SRS 本はこちらから無償でダウンロードできます。 前回までの読書メモは SRS Book タグ を参照のこと。 Chapter 5. Design for Least Privilege 最小権限の原則(The principle of least privilege)とは、アクセス主体が人間かシステムかに関わらず、タスクを達成するのに必要な最低限度のアクセス権限のみを与えるべきという原則である。新機能の設計段階から考慮することで、この原則が最も有効に働く。 社員の操作に完璧は期… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>SRS 本の読書メモの続きです。Chapter 5 はなかなか重たい内容だったので、この章のみでメモを上げます。</p> <p>SRS 本はこちらから無償でダウンロードできます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>前回までの読書メモは <a href="https://muziyoshiz.hatenablog.com/archive/category/SRS%20Book">SRS Book タグ</a> を参照のこと。</p> <h2>Chapter 5. Design for Least Privilege</h2> <p><a href="https://ja.wikipedia.org/wiki/%E6%9C%80%E5%B0%8F%E6%A8%A9%E9%99%90%E3%81%AE%E5%8E%9F%E5%89%87">最小権限の原則</a>(The principle of least privilege)とは、アクセス主体が人間かシステムかに関わらず、タスクを達成するのに必要な最低限度のアクセス権限のみを与えるべきという原則である。新機能の設計段階から考慮することで、この原則が最も有効に働く。</p> <p>社員の操作に完璧は期待できない。そこに悪意があるにせよないにせよ。思考実験として、もしあなたがなにか悪いことをしたいと思ったら、自分の組織にどのようなダメージを与えられるか考えてみよう。どんなことを、どのように実行できる? あなたの悪事は気づかれる? あなたの操作履歴を隠すことはできる? あるいは、もし良い意図だとしても、あなたができる最も破壊的なミスはどんなもの? 普段どれくらいのコマンドを手で実行していて、そのなかにどれくらいのタイミングミスやコピペミスがある?</p> <p>そのような悪いアクションによる影響を最小化できる、または取り除けるようにシステムを設計することを推奨する。ここでも SRE の格言を引用すると、hope is not a strategy. である。</p> <h3>Concepts and Terminology</h3> <p>ベストプラクティスの詳細に入る前に、業界および Google での用語の定義について。</p> <ul> <li>Least privilege(最小権限) <ul> <li>セキュリティ業界で確立された、幅広いコンセプト</li> <li>最小権限の目的は、そのシステムのすべての認証・認可のレイヤに渡って拡張されるべき</li> </ul> </li> <li>Zero Trust Networking <ul> <li>ユーザのネットワーク的な位置(それが社内ネットワークかどうか)によって、何の権限も付与しないという原則</li> <li>Google では BeyondCorp program によって大規模な zero trust networking の実装に成功した</li> </ul> </li> <li>Zero Touch <ul> <li>SRE が直接システムやネットワークに触らず、拡張可能な自動化や、安全な API や、回復性のある多要素承認システム(resilient multi-party approval system)を通してのみ変更を行うこと</li> <li>Google ではこれを実現するために Zero Touch Production (ZTP) や Zero Touch Networking (ZTN) などのインターフェイスを開発してきた</li> </ul> </li> </ul> <h3>Classifying Access Based on Risk</h3> <p>すべてのアクセスを同じ方法で一律に制限するのではなく、セキュリティリスクや影響度に応じてアクセスを分類する必要がある。例えば、アクセスされるデータの種類による分類や、その API が書き込み可能かどうかによる分類がありがちだろう。</p> <p>あなたのシステムの分類が明確に定義され、一貫性を持って適用され、広く理解されれば、開発者はそれを共通言語としてシステムやサービスを設計できる。この分類フレームワーク(classification framework)は、データストア、API、サービスやその他のエンティティに幅広く適用されうる。</p> <p>p.64 の Table 5-1. Example access classifications based on risk に、アクセスを Public, Sensitive, Highly sensitive の3種類に分類した例を示す。</p> <h3>Best Practices</h3> <p>著者らが推奨する、最小権限モデルを実装する際のベストプラクティスを紹介する。</p> <ul> <li>Small Functional APIs <ul> <li>さながら UNIX 哲学にあるように、1つのことだけをうまくやる API を作る</li> <li>POSIX API のような巨大な API に対しては、制限や監査ログの記録(audit)は難しい</li> <li>ユーザー向けの API より、管理用の API(Administrative API)のほうが権限が強い分、より一層の注意が必要</li> </ul> </li> <li>Breakglass <ul> <li>ガラスを割って非常ボタンを押すように、非常時に認証システムをバイパスする仕組みを breakglass mechanism と呼ぶ</li> <li>予期せぬ状況から復旧するために、このような仕組みは有用</li> <li>For more context, see “Graceful Failure and Breakglass Mechanisms” on page 74 and “Diagnosing Access Denials” on page 73.</li> </ul> </li> <li>Auditing <ul> <li>監査ログの記録から、意味のある検知ができるかどうかは、そのシステムの「アクセス制限がどれくらいの粒度か」と「リクエストに関するメタデータがどれくらい明確に記録されるか」に依存している</li> </ul> </li> <li>Testing and Least Privilege <ul> <li>最小権限に関連するテストには、2つの重要な次元がある</li> <li>Testing of least privilege <ul> <li>必要なリソースのみに対するアクセス権限を正しく与えられていることを保証する</li> <li>本番環境への悪影響を避けるため、アクセス権限を実際に変更する前に、このテストは自動実行されるべき。テストカバレッジが不完全な場合は、監視やアラートの仕組みで一部補うこともできる</li> </ul> </li> <li>Testing with least privilege <ul> <li>テストのためのインフラが、そのテストに必要なアクセスのみを与えられていることを保証する</li> <li>例えば、新しい機能を開発したい人(データアナリスト)向けに、限られたデータセットへのアクセスのみを許可したいケースがある</li> <li>テスト環境を作る代わりに、本番環境にテストアカウントを作るという方法もあるが、これは監査やACLにノイズを増やすことにもなる。テスト環境は高価だが、それを用意しなかった場合のリスクもある。あなたの状況ごとに、費用対効果をよく考えることが重要</li> </ul> </li> </ul> </li> <li>Dignosting Access Denials <ul> <li>ユーザーの持っている権限によって、アクセス拒否時に渡す情報を変える。情報を与えすぎるとシステムを攻撃するための情報を与えることになりかねないが、与えなさすぎるとセキュリティポリシーチームのサポート負荷が限界を超えてしまう</li> <li>Zero trust model の実装の初期段階では、アクセス拒否時にトークンを提示し、サポートチャンネルに問い合わせさせることを推奨する</li> </ul> </li> <li>Graceful Failure and Breakglass Mechanisms <ul> <li>breakglass mechanism を導入する際に考慮すべきガイドライン: <ul> <li>breakglass mechanism の利用は強く制限されるべき。一般的に、そのシステムの SLA に責任を持つ SRE チームに制限するべき</li> <li>Zero trust networking のための breakglass mechanism は、特定の場所(例えば、物理的なアクセス制限のある panic rooms)からのみ利用できるようにすべき。ネットワーク上の位置を信頼しないという ZTN のコンセプトに反しているように見えるかもしれないが、この場合は、物理的なアクセス制限を前提として信頼する</li> <li>breakglass mechanism の全ての利用は入念に監視されるべき</li> <li>breakglass mechanism は、本番サービスに責任を持つチームによって定期的にテストされるべき</li> </ul> </li> </ul> </li> </ul> <p>Auditing のベストプラクティスについては、この節のなかで更に深堀りされている。</p> <ul> <li>よい監査ログを集める <ul> <li>よい監査ログを集めるうえで、Small Functional APIs には強いアドバンテージがある。Small Functional APIs がないと、一時的に強くて広い権限の API へのアクセスを与えるか、事前に監査を受けた上でシステムの直接操作を許可することになる。いずれも監査ログの追跡を難しくする</li> <li>最終的には、管理用 API と自動化を構築するチームは、監査を容易にする方法でそれらを設計する必要がある。そのためには、監査を重視する文化が必要。文化なしでは、監査は常に承認され、breakglass は日常利用され、意味をなさなくなってしまう</li> </ul> </li> <li>監査者(auditor)を選ぶ <ul> <li>監査の目的次第で、どのような監査者を選ぶべきかは変わる。Google では監査を以下の大きな2カテゴリに分類している <ul> <li>ベストプラクティスに沿っていることを確実にするために監査する(Audits to ensure best practices are being followed)</li> <li>セキュリティ違反を特定するために監査する(Audits to identify security breaches)</li> </ul> </li> <li>前者は、例えば breakglass を多用しすぎていないかを毎週の SRE チームミーティングでレビューすること。Google では breakglass review をチームレベルで分散して、社会規範化(social norming)を促進している。これは、現行の administrative APIs の欠点を明らかにし、改善を促すことにもなる</li> <li>後者は、Google では central auditing team に集約している。そのような攻撃は、複数の組織の監査ログを俯瞰的に見ないとわからないことがある</li> <li>著者らは、Google にて、structured justification(構造化された正当化)というものを使って、audit log events を構造化されたデータと関連付けている。これは、バグ番号や、チケット番号、カスタマーケース番号などに対する構造化された参照のことである。このような構造化されたデータがあれば、監査ログを自動的に検証できる</li> </ul> </li> </ul> <h3>Worked Example: Configuration Distribution</h3> <p>具体例として、Web サーバ群に設定ファイルを配布する事例を考える。設定ファイルの管理に関するベストプラクティスは次のようになる。</p> <ol> <li>バージョン管理システム上に設定ファイルを保管する</li> <li>そのファイルに対する変更をコードレビューする</li> <li>その変更をまず canary set に配布し、ヘルスチェックを通ったら、すべての Web サーバに対して段階的に配布する。このステップは、この自動的なアクセスに対して、設定ファイルの更新権限を与えることを要求する</li> </ol> <p>この更新機能を実現するために公開する Small API のアプローチはいくつかある。この節では以下の4通りを考える(p.75 の Table 5-2 に詳細)。</p> <ul> <li>POSIX API via OpenSSH</li> <li>Software update API</li> <li>Custom OpenSSH ForceCommand</li> <li>Custom HTTP receiver</li> </ul> <p>POSIX API via OpenSSH はシンプルで一般的だが、何でもできてしまうため様々なリスクがある。Software update API は apt-get などのパッケージを使った更新のことだが、バイナリの更新と設定ファイルの更新を同時に行うため、やりたいことに対して操作が高価かつ破壊的すぎる(詳しくは Chapter 9 で触れる)。</p> <p>Custom OpenSSH ForceCommand は OpenSSH 経由の操作を安全にできるが、いろいろな操作に広げていくことが難しい。OpenSSH の上でいろいろなコマンドを送れるようにしていくと、それは結局独自の RPC メカニズムを作ることになる。それなら gRPC や Thrift の上に作ったほうが良い。</p> <p>Custom HTTP Receiver は Sidecar として実装する方法と、In-Process に実装する方法がある。In-Process の方法が最も柔軟性があり、Google での設定ファイルの管理方法にとても近い。</p> <h3>A Policy Framework for Authentication and Authorization Decisions</h3> <p>API に対するアクセス制限として、認証(Authentication)と認可(Authorization)の2つのステップをどのように行うかを決めなければいけない。この節では、Google で有用とわかったさまざまなテクニックについて議論する。</p> <ul> <li>Using Advanced Authorization Controls <ul> <li>認証、認可を正しく実装するのは大変なので、AWS や GCP が提供する IAM 機能を使ったほうがいい</li> </ul> </li> <li>Investing in a Widely Used Authorization Framework <ul> <li>認証、認可のフレームワークを共通化することで、すべてのサービスエンドポイントに対する機能の強化(後述する MFA や MPA のサポート追加など)や設定変更が可能になる</li> </ul> </li> <li>Avoiding Potential Pitfalls <ul> <li>ポリシー言語の設計は難しい。ポリシー言語をシンプルにしすぎると目的を達成できず、汎用的にしすぎるとその内容を推測するのが難しくなる。いずれかの極端によらないよう、反復的なアプローチで設計するのがよい</li> </ul> </li> </ul> <h3>Advanced Controls</h3> <p>多くの認可に関する判断は yes か no かの二択になるが、厳密な二択にする代わりに、逃がし弁としての "maybe"(追加のチェック) を用意することで、システムにおける緊張を劇的に緩和できる。</p> <p>以下で示す方法は、単独でも使えるし、組み合わせて使うこともできる。どのような使い方が適切かは、データの重要性、操作の危険性や、既存のビジネスプロセス次第である。</p> <ul> <li>Multi-Party Authorization (MPA) <ul> <li>他の人に認可を与えてもらうこと。ミスを防げる、悪事への抑止効果がある、などのいくつかのメリットがある</li> <li>MPA は、広範なアクセス権限を与えるために使われがちであるが、可能なら Small Functional API と組み合わせたほうがよい</li> <li>MPA を導入するだけでなく、組織的、あるいは仕組み的に No といえる環境を用意する必要がある。悩んだ場合はセキュリティチームにエスカレーションできるような仕組みがあれば、組織的な圧力を弱めることができる</li> </ul> </li> <li>Three-Factor Authorization (3FA) <ul> <li>1個のプラットフォーム(例えば全員が共通で使っているワークステーション1台)が攻撃されただけでは権限を奪われないようにしたい。MPA だとこの種の攻撃は防げない</li> <li>少なくとも2個のプラットフォームを用意したい。安価な方法としては、リスクが高い操作については、セキュリティ的に強化されたモバイルプラットフォーム(hardened mobile platform)からの認可を求める、という方法がある</li> <li>3FA と Two-factor authentication(2FA、二要素認証)や Multi-factor authentication(MFA、多要素認証)は別のものである。3FA は強い認可を提供するものであり、強い認証を提供するものではない。ただし、3FA の 3 が誤解を招く用語であることは確か。3FA は第2のプラットフォームからの認可を求めるものであり、第3ではない</li> <li>MPAと3FAによって防がれる脅威は別のものである、ということを理解することが重要。そうすることで、一貫したポリシーに基づいて、これらの技術を適用できるようになる</li> </ul> </li> <li>Business Justifications <ul> <li>認可を求める際に、ビジネス的な正当性を、バグID、インシデントID、チケットID、ケースID、関連アカウントなどと紐付けることを強制する</li> <li>また、それらの ID に関連して、アクセスを許可するデータも特定のものに限定すべきである。適切に構成されたシステムでは、入力されたチケット ID に関連する、特定の顧客に関連するデータへのアクセスしか許可しないことも可能になる</li> </ul> </li> <li>Temporary Access <ul> <li>一時的なアクセス権限を与えることで、認可に関する決定によるリスクを限定することができる。これは、特に、すべての操作に対して細かなアクセス権限を設定できない場合に有用である。また、root 権限のような ambient authority(環境全体に関する認可)を減らすことにも繋がる</li> </ul> </li> <li>Proxies <ul> <li>バックエンドサービスに対する細かなアクセス権限を設定できない場合、次善の策として、強く監視され、利用が制限されたプロクシ(あるいは踏み台)を用いることができる</li> <li>例えば、緊急時に、他の API による操作では復旧できない場合に、プロクシ経由の操作を許可する</li> </ul> </li> </ul> <h3>Tradeoffs and Tensions</h3> <p>最小権限アクセスモデルを導入することで、あなたの組織のセキュリティに対する姿勢は間違いなく改善される。しかし、これまでに説明した利点と、モデルを導入することによるコストを割り引いて考えなければいけない。この節ではそれらのコストについて考える。</p> <ul> <li>セキュリティの複雑性が増す。このユーザーはこのデータにアクセスできるのか? このデータにアクセスできるのは誰なのか?</li> <li>すべてのデータへのアクセスを同様に禁じると、情報の透明性がなくなり、組織文化に影響する。例えば、ソースコードも機密情報の一種である。しかし、ある程度のリスクを許容して、開発者にソースコードへの広範なアクセス権限を与えた場合、開発者はソースコードから学んだり、コントリビュートすることができる。この問題については Chapter 21 で詳しく触れる</li> <li>最小権限を与えるためのデータ(コンテキスト)の品質が悪いと、セキュリティに影響する。セキュリティに影響するデータの品質をできるだけ高くするために、それらのデータを作るシステムをレビューすべきである</li> <li>ワークフローを行うユーザーにとっての利便性が下がる。ユーザーの苦痛をなるべく小さくするためのナビゲーションや、自己診断〜サポートへの連絡を助ける方法が必要である</li> <li>最小権限のためのモデルが導入されたら、開発者はそれに従う必要がある。開発者にこのモデルを理解してもらうために、トレーニング教材や API ドキュメントを整備すべきである。また、開発者がセキュリティエンジニアによるレビューを気軽かつ迅速に受けられるようにすべきである</li> </ul> <h3>Conclusion</h3> <p>複雑なシステムを設計するにあたって、最小権限モデルは、クライアントにその目的を達成するために必要な能力を与え、かつそれ以上のものを与えないための最も安全な方法である。</p> <p>Google はこのモデルを実装するために莫大な時間および労力を投じてきた。最後に、最小権限モデルを実装するための主要なコンポーネントを挙げる。</p> <ul> <li>あなたのシステムの機能に関する包括的な知識。この知識があることで、あなたはそれぞれの機能が持つセキュリティリスクのレベルに従って、それらの機能を分類できる</li> <li>この分類に基づく、できるだけ細かいレベルでの、あなたのシステムおよびあなたのデータへのアクセスの分割(partitioning)</li> <li>あなたのシステムへのアクセスを試みるユーザーのクレデンシャルを検証するための認証システム</li> <li>適切に分割されたシステムに対してアタッチされた、うまく定義されたセキュリティポリシーを適用するための認可システム</li> <li>細かな認可を与えるための、高度な制御機能。例えば、一時的な認可、MPA、3FA など</li> <li>これらのキーコンセプトを支えるための、あなたのシステムに対する運用面での要件。少なくとも、以下が必要である <ul> <li>すべてのアクセスを監査し、あなたが脅威を見つけてフォレンジック調査を行うきっかけとなるシグナルを生成する能力</li> <li>セキュリティポリシーを論理的に考えて、定義し、テストし、デバッグするための手段、およびそのポリシーに関するエンドユーザーサポートを提供する手段</li> <li>あなたのシステムが想定通りに動かなかった場合に breakglass mechanism を提供する手段</li> </ul> </li> </ul> <h2>ここまでの感想</h2> <p>5章だけで30ページ近くあり、具体例も豊富で勉強になりました。例えば、Auditor には2種類ある、というのは僕にとっては新しい観点でした。MPA と 3FA で目的が違う(MFA もまた違う)、というのも本書を読んでよく理解できました。</p> <p>扱われている話題の範囲も広く、Google が実現しているレベルに達するのはかなり大変そうだ……というのが率直な感想です。</p> <p>その一方で、いままで自分たちもやっていたことだけど、Google ではそう呼んでいるのか、と気づいた部分もありました。システムに対する作業を、今の仕事では Backlog の課題キー(チケット ID に相当するもの)と関連付けて記録しているのですが、これはまさに本章で "Business Justification" と呼ばれているものでした。</p> <p>Google の事例を見て落ち込みすぎず、本書の内容を手本として、ベストプラクティスをできるところから少しずつ取り入れていきたいですね。</p> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 3 & 4 hatenablog://entry/26006613577199788 2020-05-31T22:46:57+09:00 2020-05-31T22:52:35+09:00 SRS 本の読書メモの続きです。Chapter 5 が結構長いので、とりあえず Chapter 3〜4 の読書メモを書きました。 SRS 本はこちらから無償でダウンロードできます。 前回までの読書メモはこちら。 Part II. Designing Systems Part II (Chapter 3〜10) では、セキュリティと信頼性に関する要求を実装するための最もコスト効率の良い方法、すなわちソフトウェア開発サイクルのできるだけ早い段階、システムの設計時にそれらに着手するということにフォーカスする。 Chapter 3. Case Study: Safe Proxies この章は Goog… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>SRS 本の読書メモの続きです。Chapter 5 が結構長いので、とりあえず Chapter 3〜4 の読書メモを書きました。</p> <p>SRS 本はこちらから無償でダウンロードできます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>前回までの読書メモはこちら。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2020%2F04%2F30%2F014824" title="Building Secure and Reliable Systems 読書メモ - Chapter 1 &amp; 2 - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p> <h2>Part II. Designing Systems</h2> <p>Part II (Chapter 3〜10) では、セキュリティと信頼性に関する要求を実装するための最もコスト効率の良い方法、すなわちソフトウェア開発サイクルのできるだけ早い段階、システムの設計時にそれらに着手するということにフォーカスする。</p> <h3>Chapter 3. Case Study: Safe Proxies</h3> <p>この章は Google でのケーススタディ(Safe proxies)の簡単な紹介のみ。このケーススタディに含まれる要素は、Chapter 4 以降で詳しく紹介される。</p> <p>Safe proxies とは、認可された人に対して、物理サーバや仮想マシン、特定のアプリケーションへのアクセスや状態変更を許可するためのフレームワーク。Google では、システムへの SSH 接続の必要なしに、リスクのあるコマンドのレビュー、承認、実行を行うことが出来る。</p> <p>Safe proxies は本番環境への単一のエントリーポイントとなり、以下のようなことを可能にする(Figure 3-1 に Safe proxy model が図示されている)。</p> <ul> <li>fleet 内でのすべての操作の監査</li> <li>リソースへのアクセス制御</li> <li>人的ミスが本番環境へ大規模に広がることに対する保護</li> </ul> <p><a href="https://www.usenix.org/conference/srecon19emea/presentation/czapinski">Zero Touch Prod</a> という Google のプロジェクトがある。その目的は、本番環境に対する変更はすべて自動的に行われるか、ソフトウェアによって事前検証されるか、監査済みの breakglass mechanism を通して実行されるようにすることにある。Safe proxies はこれらの原則を達成するために用いられるツールセットの一つである。</p> <p>Safe proxies の導入によって生じる摩擦を減らすために、この章の著者らはエンジニアと密に連携し、緊急時には brakeglass mechanism を通してエンジニアがシステムにアクセスできるようにしている。breakglass mechanism とは、緊急時にセキュリティポリシーをバイパスして操作できるようにするためのメカニズムのこと(火災報知器を鳴らすときにガラスを割る=breakglassからの連想)。breakglass mechanism は権限が強いゆえに、Multi-Party Authorization (MPA) や厳密な監査ログなどとセットで実現される。これらの詳細は Chapter 5 に書かれている。</p> <p>Google Tool Proxy(Safe proxies と呼ばれるプロクシ群の1つ?)は、CLI の実行をプロクシするツールである。エンジニアはマシン上で直接コマンドを実行できない。Tool Proxy が任意のコマンドを gRPC で受け取り、ポリシーと照らし合わせ、監査ログを記録し、MPA を要求した後にコマンドを実行する。文中では borg CLI を例に挙げている。</p> <h3>Chapter 4. Design Tradeoffs</h3> <p>セキュリティ、信頼性、および機能面での要求の間のトレードオフに関する章。</p> <p>セキュリティと信頼性を後回しにして一時的に開発速度を上げても、あとから重大なコストとリスクを生じる。しかし、システムのライフサイクルの初期からこれらを考慮した設計にすることで、この三者をすべて満たすことができる、というのがこの章での主張。</p> <p>典型的には、機能要件(feature requirements, functional requirements)が最初に作られ、これがシステム設計に関する決定の推進力になる。それに対して、特定の機能に紐付かない、セキュリティや信頼性に関するものは非機能要件に含まれる。また、開発やデプロイのベロシティに関する要件も非機能要件に含まれる。</p> <p>機能要件は仕様を書き出して、実装して、仕様通りかをテストする、という流れがわかりやすいが、セキュリティや信頼性についてはそれが難しい。信頼性とセキュリティは、システムデザインから現れてくる特性(emergent property)であり、単一の機能を実装するという類のものではない。コラム "Reliability and Security as Emergent Properties of System Design"に、この特性に関係する要素がいくつか挙げられている。</p> <p>システムの初期段階から信頼性とセキュリティについて考える方法の一例として、Google で用いられている Design document template がある。このテンプレートには信頼性およびセキュリティに関するセクションがあり、p.47以降で各セクションが詳しく紹介されている。</p> <p>機能要件と非機能要件のバランス、トレードオフの解決は難しい。"Example: Payment Processing" では支払い処理を例に挙げて、reliability risk を避けようとすると、security risks が出てくる、というケースを説明している。</p> <p>Google ではマイクロサービスのための社内向けフレームワーク(Google Web Application Framework)を進化させてきた。</p> <p>Google Web Application Framework は、アプリケーションコードがコーディングガイドラインやベストプラクティスに一致するかどうかのチェック(conformance checks)を静的または動的に適用することができる。また、開発やデプロイで必要となる共通タスクが最初から組み込まれている。フレームワークにこれらの機能が含まれているため、それを開発者が自分で作った場合に起こる脆弱性の混入を防いでくれる。</p> <p>また、ビルドから SLA の計測まで自動化されていることで、error budget を消費した製品についてはリリースを止めることもできる(コラム "Reliability and Security Benefits of Software Development Frameworks" 内の記載)。</p> <p>セキュリティと信頼性に対する優先度を上げることは、他の優先すべきこと(機能要件)を妨げない。むしろ上記の検査などが自動化されていれば、開発速度は上がる。セキュリティ問題に柔軟に対応できる設計ということは、新機能を追加しやすい設計ということでもある。</p> <p>開発初期のベロシティ(Initial Velocity)と、長期的なベロシティ(Sustained Velocity)を区別して考える必要がある。開発初期のベロシティを重視してセキュリティと信頼性を考慮しないと、長期的にはスローダウンする。そのため、セキュリティと信頼性をチームの文化に埋め込む必要がある(チームの文化については Chapter 21)。</p> <h2>ここまでの感想</h2> <p>Chapter 3〜4 を読むと、Google はそのスケールメリットを生かして、セキュリティと信頼性に関わるツールやフレームワークを共通化しているということがよくわかります。しかし、このアプローチは Google ほどの規模がないと難しそうですし、普通の会社はどうしたらいいんだろう……というのが、ここまで読んだ率直な感想でした。</p> <p>あと、個人的には Chapter 4 の文章がところどころ胸に刺さりました。例えば、コラム "Cost of Adding Reliability and Security to Existing Systems" の以下の記載。</p> <blockquote><p>Accommodating security and reliability requirements in an existing system often requires significant design changes, major refactorings, or even partial rewrites, and can become very expensive and time-consuming. Furthermore, such changes might have to be made under time pressure in response to a security or reliability incident— but making significant design changes to a deployed system in a hurry comes with a significant risk of introducing additional flaws.</p> <p>既存システムのセキュリティと信頼性の要件を満たすためには、多くの場合、大幅な設計変更、大規模なリファクタリング、あるいは部分的な書き換えが必要となり、非常に高価で時間のかかる作業になることがあります。 さらに、このような変更は、セキュリティや信頼性のインシデントに対応するために、時間的なプレッシャーの中で行わなければならないかもしれませんが、デプロイされたシステムの大幅な設計変更を急いで行うことは、さらなる不具合を導入する大きなリスクを伴います。</p></blockquote> <p>あとは "Initial Velocity Versus Sustained Velocity" の節にある以下の文章も個人的には刺さりました。</p> <blockquote><p>Furthermore, tests retrofitted to a mature system can sometimes fall into the trap of exercising the current buggy behavior more than the correct, intended behavior.</p> <p>さらに、成熟したシステムにあとから組み込まれたテストは、正しい、意図された振る舞いをテストするというより、現在のバグった振る舞いを再現していることをテストする、という罠に陥ることがあります。</p></blockquote> <p>そういうことってありますよね……。</p> <p>いまあるシステムにとっては何の慰めにもならない文章ばかりですが、これから作るシステムについてはせめて最初からセキュリティと信頼性について考えよう、と思わせてくれる内容でした。</p> muziyoshiz Building Secure and Reliable Systems 読書メモ - Chapter 1 & 2 hatenablog://entry/26006613558640600 2020-04-30T01:48:24+09:00 2020-05-31T21:36:56+09:00 今月中旬に、Google SRE による SRE 本の3冊目 "Building Secure and Reliable Systems" が無償公開されました。 www.publickey1.jp 以下のサイトから PDF, EPUB, MOBI 形式でダウンロードできます。過去の2冊は HTML で公開されていますが、今回は電子書籍のデータ形式での公開のようです。 landing.google.com 日本語版は、もし出版されたとしても2年後くらいになりそうなので、僕もそろそろ重い腰を上げて読み始めました。 導入にあたる Part I(Chapter 1 & 2)まで読み終わったので、ここ… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200430/20200430014145.png" alt="f:id:muziyoshiz:20200430014145p:plain:w320" title="f:id:muziyoshiz:20200430014145p:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>今月中旬に、Google SRE による SRE 本の3冊目 "Building Secure and Reliable Systems" が無償公開されました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.publickey1.jp%2Fblog%2F20%2Fgooglesrebuilding_secure_and_reliable_systems.html" title="Google、SRE本の第三弾「Building Secure and Reliable Systems」を無料公開" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.publickey1.jp/blog/20/googlesrebuilding_secure_and_reliable_systems.html">www.publickey1.jp</a></cite></p> <p>以下のサイトから PDF, EPUB, MOBI 形式でダウンロードできます。過去の2冊は HTML で公開されていますが、今回は電子書籍のデータ形式での公開のようです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flanding.google.com%2Fsre%2Fbooks%2F" title="Google - Site Reliability Engineering" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://landing.google.com/sre/books/">landing.google.com</a></cite></p> <p>日本語版は、もし出版されたとしても2年後くらいになりそうなので、僕もそろそろ重い腰を上げて読み始めました。</p> <p>導入にあたる Part I(Chapter 1 &amp; 2)まで読み終わったので、ここまでの読書メモと感想を書いておきます。久しぶりに洋書読んでて結構疲れたので、自分への動機づけのために、今後、何章か読むたびに読書メモを書いていこうと思います。</p> <h2>読書メモ</h2> <p>以下、内容に関する僕の理解と、僕が特に重要と思った箇所のメモです。また、一部はメモに加えて、原文を引用しています。</p> <p>あくまで内容の一部ですし、まだ全部読み終わってないので誤解も多いと思います。気になったキーワードがあったら原著をあたってください。</p> <h3>Foreword by Royal Hansen (Vice President, Security Engineering)</h3> <p>SRE モデル(DevOps の SRE-like version)が一般的になるにつれ、SRE が取り組んでいる問題領域は、同様の原動力をセキュリティの問題にももたらすのではないかと気づいた。いくつかの組織はこの2つを "DevSecOps" と呼ばれるアプローチに統合している。</p> <p>SRE と security engineer には似たところが多い。SRE はチーム間を結びつけるモデル(error budget などのこと?)を作ったが、security engineer にも同様のものが必要。Hansen 氏とその同僚は、セキュリティは first-class であるべきと主張してきた。大企業内でのセキュリティに対するアプローチはこの20年間で劇的に変わった。</p> <p>SRE が信頼性をソフトウェアのライフサイクルに組み込んだように、セキュリティもソフトウェアのライフサイクルに組み込むことが重要と思う。</p> <h3>Foreword by Michael Wildpaner (Senior Director, Site Reliability Engineering)</h3> <p>Site Reliability Engineering と Security Engineering はシステムの可用性を保つことに関係している。セキュリティインシデントはユーザーの信頼を壊し、システムの可用性を壊す。システムセキュリティは SRE の心の常にトップを占める。</p> <p>Gmail の SRE テックリードの一人だったときに、SRE が、悪い設計や悪い実装によるセキュリティへの悪影響を防ぐ最後の壁として働くのを目にした。</p> <p>Google の SRE に関する過去の2冊の書籍は、信頼性とセキュリティの交点(intersection of reliability and security)についての詳細は触れなかった。本書はそのギャップを埋め、セキュリティに特化したトピックにも紙面を取っている。</p> <h2>Preface</h2> <p>本書の目的は、セキュリティと信頼性に特化した実践者からの、システム設計、実装、およびメンテナンスに関する知見を提供すること。</p> <blockquote><p>We argue that everyone should be thinking about the fundamentals of reliability and security from the very beginning of the development process, and integrating those principles early in the system lifecycle.</p></blockquote> <p>私達は、すべての人々がその開発プロセスの初期から、信頼性とセキュリティの基盤について考え、それらの原則をシステムライフサイクルに統合すべきと強く考えている。</p> <blockquote><p>Because security and reliability are everyone’s responsibility, we’re targeting a broad audience: people who design, implement, and maintain systems. We’re challenging the dividing lines between the traditional professional roles of developers, architects, Site Reliability Engineers (SREs), systems administrators, and security engineers.</p></blockquote> <p>セキュリティと信頼性は全員の義務であるという考えから、本書は広い範囲の読者を対象としている。私達は従来の役割の線引き(開発者、アーキテクト、SRE、システム管理者、セキュリティエンジニア)を超えた話をしようとしている。自分のいまの立場とは関係なく、それぞれの立場に立って読んでみてほしい。</p> <p>Chapter 1 と 2 を最初に読み、そのあとはあなたが最も興味を持った章を読むことをお勧めする。</p> <h2>Chapter 1. The Intersection of Security and Reliability</h2> <p>Google で2012年に起きた、社内システムの障害の事例。ある WiFi パスワード変更の告知がきっかけで、社内向けのパスワードマネージャ(数年前に作られたまま放置状態)に想定外の高負荷がかかりダウン。その信頼性の低さに反して、サーバ再起動のためのセキュリティが厳重で、最終的に金庫を電動ドリルで開けて HSM を取り出す羽目になった。</p> <p>セキュリティと信頼性は、真に信用に足るシステムの重要な構成要素だが、セキュリティと信頼性の両方を満たすシステムを作るのは難しい。共通点もあるが、設計時に考慮すべき点は異なる。両者の微妙な連携が崩れると予想外の結果が生じる。</p> <p>信頼性を上げるための設計が、セキュリティに影響する。トレードオフがある。冗長性を上げると攻撃対象が増える。インシデント対応のためにログの情報量を増やすと、ログも攻撃の対象になりうる。</p> <blockquote><p>Both security and reliability are concerned with the confidentiality, integrity, and availability of systems, but they view these properties through different lenses. The key difference between the two viewpoints is the presence or lack of a malicious adversary.</p></blockquote> <p>セキュリティと信頼性は、いずれも CIA(機密性、完全性、可用性)に関係するが、悪意ある攻撃者を想定するかどうか、という点が大きな違い。</p> <p>セキュリティと信頼性は、いずれもシステムの設計から現れる特性である。いずれもシステムの設計初期から考慮しなければならないが、一見無害に思える変更で容易に壊れてしまう。その他にもいくつかの共通点がある。</p> <ul> <li>Invisibility <ul> <li>いずれもうまく行っているときは目に見えず、問題が生じたときだけ目につく</li> <li>いずれも、損なった場合の損害が大きい</li> </ul> </li> <li>Assessment <ul> <li>いずれも悪影響が起きたときのコストを評価する必要があるが、セキュリティの方はその評価が更に難しい</li> </ul> </li> <li>Simplicity <ul> <li>いずれも、システム設計をできるだけシンプルに保つことで達成しやすくなる</li> </ul> </li> <li>Evolution <ul> <li>市場の要求に答えるための機能追加などによりシステムは徐々に複雑になり、その影響は読みづらい</li> <li>セキュリティに関しては攻撃手段も日々進化する</li> </ul> </li> <li>Resilience <ul> <li>システムが複雑になるにつれ、システムが回復性を持つと証明することは難しくなっていく</li> <li>Defense in depth(多重防御、縦深防御)、Distinct failure domains(障害の影響範囲の明確化)、The princeple of least privilege(最小限の権限の原則)などで脅威による影響を狭める</li> </ul> </li> <li>From Design to Production <ul> <li>本番へのデプロイ後も設計を維持する必要がある。コードレビューや共通フレームワークの活用、テスト、デプロイのためのシステムでそれを助ける</li> </ul> </li> <li>Investigating Systems and Logging <ul> <li>セキュリティと信頼性を完全に維持することは難しいため、それが崩れたときに検知する仕組みが必要</li> <li>検知のためにはログは多く、詳細なほどいいが、コストや情報漏えいのリスクとのトレードオフがある</li> </ul> </li> <li>Crisis response <ul> <li>Google は Incident Management at Google (IMAG) と呼ばれるプログラムに体系化している。IMAG はアメリカ政府の Incident Command System (ICS) をモデルにしている</li> <li>ある危機が起きてから次の危機が起こるまでには長いインターバルがあるため、その間にスキルとモチベーションを維持するために Disaster Recovery Testing program (DiRT) を定期的に実行している。内部システム障害をシミュレートし、チームでの対処を強制する</li> </ul> </li> <li>Recovery <ul> <li>障害からの復旧は迅速に行いたいが、全体に同時にデプロイすると、新たな不具合や脆弱性も同様に全体へデプロイされる危険がある</li> <li>変更を段階的にデプロイし、問題が起きたらすぐ発見できる仕組みが必要</li> </ul> </li> </ul> <h2>Chapter 2. Understanding Adversaries</h2> <p>実際の攻撃者の分類についての詳細な解説。古典的なイメージのハッカーから離れて、実際の攻撃者、国家的な組織や犯罪者などについて詳しく知ることで、防御について考えることができる。</p> <p>また、インサイダー(内部関係者)によるリスクにかなりのページを割いている。悪意あるインサイダーだけでなく、操作ミスなどによる影響もここに含む。Table 2-1. General categories of insiders and examples と Table 2-2. Framework for modeling insider risk はこのテーマについて話すときの必須資料になりそう。</p> <p>インサイダーへの対策として、以下のコンセプトを取り上げている。これらは3章以降で詳しく説明される。</p> <ul> <li>Least privilege</li> <li>Zero trust</li> <li>Multi-party authorization</li> <li>Business justifications</li> <li>Auditing and detection</li> <li>Recoverability</li> </ul> <p>攻撃者について理解するために、攻撃方法についての知識を得る方法を紹介している。</p> <ul> <li>セキュリティファームによる threat intelligence(脅威情報) <ul> <li>攻撃者やマルウェアの分析レポート、Indicators of compromise (IOCs)</li> </ul> </li> <li>Cyber Kill Chain (TM) <ul> <li>攻撃者の行動を、攻撃者が最終的な目標達成までに取るステージという形で理解するためのフレームワーク</li> </ul> </li> <li>攻撃方法をカタログ化したフレームワーク <ul> <li>Tactics, Techniques, and Procedures (TTP) のカタログ</li> <li><a href="https://attack.mitre.org/">ATT&amp;CK framework</a></li> </ul> </li> </ul> <p>著者らが見出した、リスクを評価する上での心構え。</p> <ul> <li>You may not realize you’re a target. (自分たちが狙われる明確な理由はなさそうでも、他の攻撃の土台としてターゲットになりうる)</li> <li>Attack sophistication is not a true predictor of success. (複雑な攻撃方法を気にするより、基本的な攻撃方法から対処せよ)</li> <li>Don’t underestimate your adversary. (攻撃者があなたにかける労力を過小評価するな)</li> <li>Attribution is hard. (攻撃者を特定しようとはせずに、攻撃者の取りうる行動、TTP への対処に集中せよ)</li> <li>Attackers aren’t always afraid of being caught. (攻撃者は国をまたぐことも多く、もし特定できても逮捕は難しい)</li> </ul> <h2>ここまでの感想</h2> <p>自分の経験上も SRE とセキュリティって強い関連性があると思います。たいていの会社ではセキュリティエンジニアって希少で、セキュリティ上の問題が起こると SRE は必ず何らかの形で動くことになるんじゃないでしょうか?</p> <p>本書の序文でもセキュリティエンジニアについて言及されていましたが、ここまで読んだ限りでは、ここから SRE とセキュリティエンジニアの連携の話が始まるのか、SRE がセキュリティエンジニアの役割を兼ねる話が始まるのかはよくわかりませんでした。あと、いわゆる情シスとの関係ってどうなんでしょう? Chapter 3 以降で詳しい話が出てくると思うので、この先が楽しみです。</p> <p>本書は全体的に具体例が多く、読んでいて飽きないです。ただ、その分、読んでいると余計なことをいろいろ考えてしまいます。</p> <p>特に、Chapter 1 の冒頭にあるパスワードマネージャの障害の話。勝手な想像ですけど、最初はなにかの片手間で作ったようなシステムが、いつの間にか全社で使われるようになって、あとから社内監査で文句を言われてセキュリティが強化された、とかですよねきっと……。具体例があるあるすぎて、つい我が身を振り返ってしまいます。</p> <h2>次は?</h2> <p>Chapter 6 と 21 あたりが気になってます。次は、これらの章か、Chapter 6 の前提知識になりそうな Chapter 3〜5 あたりを読んでいこうと思います。</p> <ul> <li>Chapter 6. Design for Understandability</li> <li>Chapter 21. Defining a Healthy Security and Reliability Culture</li> </ul> <p>目次を読むだけでも刺さる単語がいくつか出てきて、自分の現場にも持ち帰れる知見がありそうです。</p> muziyoshiz Ansible で文字列比較の結果を boolean 変数に代入する方法 hatenablog://entry/26006613542381432 2020-03-29T22:16:16+09:00 2020-03-29T22:20:55+09:00 きっかけ 今回は、時々つまづく Ansible の変数の仕様に関するメモです。 最近、Amazon Linux 1(そろそろ完全に廃止しないといけない……)と Amazon Linux 2 で処理を分岐させたいことがあり、同僚にこういう書き方でできるよと教えてもらいました。 - name: Task for Amazon Linux 2 debug: msg="Task for Amazon Linux 2" when: (ansible_distribution_file_variety == "Amazon" and ansible_distribution_major_version =… <div align="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20160331/20160331232512.png" alt="f:id:muziyoshiz:20160331232512p:plain:w300" title="f:id:muziyoshiz:20160331232512p:plain:w300" class="hatena-fotolife" style="width:300px" itemprop="image"></span></div> <h2>きっかけ</h2> <p>今回は、時々つまづく Ansible の変数の仕様に関するメモです。</p> <p>最近、Amazon Linux 1(そろそろ完全に廃止しないといけない……)と Amazon Linux 2 で処理を分岐させたいことがあり、同僚にこういう書き方でできるよと教えてもらいました。</p> <pre class="code" data-lang="" data-unlink>- name: Task for Amazon Linux 2 debug: msg=&#34;Task for Amazon Linux 2&#34; when: (ansible_distribution_file_variety == &#34;Amazon&#34; and ansible_distribution_major_version == &#34;2&#34;)</pre> <p>以前は <code>ansible_distribution_major_version</code> がいずれも <code>NA</code> になっていたようなのですが、現在は Amazon Linux 2 なら "2" が返されるようです。</p> <p>ただ、毎回この長い when を書くのは面倒なので、以下のように playbook の冒頭で定義するようにしてみました。</p> <pre class="code" data-lang="" data-unlink>- hosts: hogehoge vars: amzn2: (ansible_distribution_file_variety == &#34;Amazon&#34; and ansible_distribution_major_version == &#34;2&#34;) tasks: - name: Task for Amazon Linux 2 debug: msg=&#34;Task for Amazon Linux 2&#34; when: amzn2 - name: Task NOT for Amazon Linux 2 debug: msg=&#34;Task NOT for Amazon Linux 2&#34; when: not amzn2</pre> <p>しかし、この書き方をすると、以下の DEPRECATION WARNING が出てしまいます。</p> <pre class="code" data-lang="" data-unlink>TASK [Task for Amazon Linux 2] *************************************************************************************** [DEPRECATION WARNING]: evaluating (ansible_distribution_file_variety == &#34;Amazon&#34; and ansible_distribution_major_version == &#34;2&#34;) as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. ok: [hogehoge] =&gt; { &#34;msg&#34;: &#34;Task for Amazon Linux 2&#34; } TASK [Task NOT for Amazon Linux 2] *********************************************************************************** skipping: [hogehoge]</pre> <p>なるほど。じゃあ、面倒ですけど、警告文にあるように <code>|bool</code> を書き足します。</p> <pre class="code" data-lang="" data-unlink>- hosts: hogehoge vars: amzn2: (ansible_distribution_file_variety == &#34;Amazon&#34; and ansible_distribution_major_version == &#34;2&#34;) tasks: - name: Task for Amazon Linux 2 debug: msg=&#34;Task for Amazon Linux 2&#34; when: amzn2|bool - name: Task NOT for Amazon Linux 2 debug: msg=&#34;Task NOT for Amazon Linux 2&#34; when: not amzn2|bool</pre> <p>すると、DEPRECATION WARNING は出なくなったのですが、実行結果が期待と真逆になってしまいました……なんで?</p> <pre class="code" data-lang="" data-unlink>TASK [Task for Amazon Linux 2] *************************************************************************************** skipping: [hogehoge] TASK [Task NOT for Amazon Linux 2] *********************************************************************************** ok: [hogehoge] =&gt; { &#34;msg&#34;: &#34;Task NOT for Amazon Linux 2&#34; }</pre> <h2>結論</h2> <p>文字列比較の結果を代入する際に <code>"{{ }}"</code> で囲むと、文字列ではなく boolean として代入されます。DEPRECATION WARNING にある <code>|bool</code> は不要です。</p> <p>上の例で言うと、</p> <pre class="code" data-lang="" data-unlink> vars: amzn2: &#34;{{ ansible_distribution_file_variety == \&#34;Amazon\&#34; and ansible_distribution_major_version == \&#34;2\&#34; }}&#34;</pre> <p>と書くと、以下のように DEPRECATION WARNING が出ず、実行結果も期待通りになりました。</p> <pre class="code" data-lang="" data-unlink>TASK [Task for Amazon Linux 2] *************************************************************************************** ok: [hogehoge] =&gt; { &#34;msg&#34;: &#34;Task for Amazon Linux 2&#34; } TASK [Task NOT for Amazon Linux 2] *********************************************************************************** skipping: [hogehoge]</pre> <h2>実験</h2> <p>文字列比較の内容は何でもいいので、<code>("1" == "1")</code> という単純な条件式で実験します。以下の実験は、Ansible 2.9 の最新版(2.9.6)で行いました。</p> <h3>いろいろな方法での代入</h3> <p>まず、代入した値をそのまま debug モジュールで出力してみます。</p> <p>playbook:</p> <pre class="code" data-lang="" data-unlink>- hosts: localhost connection: local vars: var1: True var2: False var3: &#34;True&#34; var4: &#34;False&#34; var5: (&#34;1&#34; == &#34;1&#34;) var6: (&#34;1&#34; == &#34;1&#34;)|bool var7: &#34;{{ (&#39;1&#39; == &#39;1&#39;) }}&#34; var8: &#34;{{ (&#39;1&#39; == &#39;1&#39;)|bool }}&#34; tasks: - name: Print vars debug: msg=&#34;{{ item }}&#34; with_items: - &#34;{{ var1 }}&#34; - &#34;{{ var2 }}&#34; - &#34;{{ var3 }}&#34; - &#34;{{ var4 }}&#34; - &#34;{{ var5 }}&#34; - &#34;{{ var6 }}&#34; - &#34;{{ var7 }}&#34; - &#34;{{ var8 }}&#34;</pre> <p>結果:</p> <pre class="code" data-lang="" data-unlink>% ansible-playbook test.yml [WARNING]: No inventory was parsed, only implicit localhost is available [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match &#39;all&#39; PLAY [localhost] ***************************************************************************************************** TASK [Gathering Facts] *********************************************************************************************** ok: [localhost] TASK [Print vars] **************************************************************************************************** ok: [localhost] =&gt; (item=True) =&gt; { &#34;msg&#34;: true } ok: [localhost] =&gt; (item=False) =&gt; { &#34;msg&#34;: false } ok: [localhost] =&gt; (item=True) =&gt; { &#34;msg&#34;: true } ok: [localhost] =&gt; (item=False) =&gt; { &#34;msg&#34;: false } ok: [localhost] =&gt; (item=(&#34;1&#34; == &#34;1&#34;)) =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } ok: [localhost] =&gt; (item=(&#34;1&#34; == &#34;1&#34;)|bool) =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)|bool&#34; } ok: [localhost] =&gt; (item=True) =&gt; { &#34;msg&#34;: true } ok: [localhost] =&gt; (item=True) =&gt; { &#34;msg&#34;: true } PLAY RECAP *********************************************************************************************************** localhost : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0</pre> <table> <thead> <tr> <th> 変数名 </th> <th> 代入方法 </th> <th> 結果 </th> </tr> </thead> <tbody> <tr> <td> var1 </td> <td> True を代入 </td> <td> boolean <code>true</code> </td> </tr> <tr> <td> var2 </td> <td> False を代入 </td> <td> boolean <code>false</code> </td> </tr> <tr> <td> var3 </td> <td> "True" という文字列を代入 </td> <td> boolean <code>true</code> </td> </tr> <tr> <td> var4 </td> <td> "False" という文字列を代入 </td> <td> boolean <code>false</code> </td> </tr> <tr> <td> var5 </td> <td> 条件式を代入 </td> <td> 条件式の文字列 </td> </tr> <tr> <td> var6 </td> <td> 条件式を <code>|bool</code> 付きで代入 </td> <td> 条件式の文字列 </td> </tr> <tr> <td> var7 </td> <td> 条件式を <code>"{{ }}"</code> で囲んで代入 </td> <td> boolean <code>true</code> </td> </tr> <tr> <td> var8 </td> <td> 条件式に <code>|bool</code> を付けた上で <code>"{{ }}"</code> で囲んで代入 </td> <td> boolean <code>true</code> </td> </tr> </tbody> </table> <p>条件式を <code>"{{ }}"</code> で囲めば、その結果が boolean として代入されるし、囲まなければ文字列として代入されることがわかります。いずれにせよ、代入の時点で <code>|bool</code> の有無は全く関係ないようです。</p> <h3>when 節への文字列の渡し方</h3> <p>代入時に boolean になっている場合は当然成功するので、ここからは代入時に文字列になってしまった場合のみを考えます。</p> <p><code>|bool</code> の有無と、結果が True になるかどうかの4通りで実験しました。Playbook が長くなるので、以下には var1 のタスクだけ記載しています。</p> <pre class="code" data-lang="" data-unlink>--- - hosts: localhost connection: local vars: var1: (&#34;1&#34; == &#34;1&#34;) var2: (&#34;1&#34; == &#34;1&#34;)|bool var3: (&#34;1&#34; == &#34;2&#34;) var4: (&#34;1&#34; == &#34;2&#34;)|bool tasks: - name: 1. var1 should be printed debug: msg=&#34;{{ var1 }}&#34; when: var1 - name: 2. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: not var1 - name: 3. var1 should be printed debug: msg=&#34;{{ var1 }}&#34; when: var1|bool - name: 4. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: not var1|bool - name: 5. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: not (var1|bool) - name: 6. var1 should be printed debug: msg=&#34;{{ var1 }}&#34; when: &#34;{{ var1 }}&#34; - name: 7. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: &#34;{{ not var1 }}&#34; # Template error # - name: 8. var1 should NOT be printed # debug: msg=&#34;{{ var1 }}&#34; # when: not &#34;{{ var1 }}&#34; - name: 9. var1 should be printed debug: msg=&#34;{{ var1 }}&#34; when: &#34;{{ var1|bool }}&#34; - name: 10. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: &#34;{{ not var1|bool }}&#34; - name: 11. var1 should NOT be printed debug: msg=&#34;{{ var1 }}&#34; when: not &#34;{{ var1|bool }}&#34;</pre> <p>結果はこうなりました。</p> <pre class="code" data-lang="" data-unlink>% ansible-playbook test.yml [WARNING]: No inventory was parsed, only implicit localhost is available [WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match &#39;all&#39; PLAY [localhost] ***************************************************************************************************** TASK [Gathering Facts] *********************************************************************************************** ok: [localhost] TASK [1. var1 should be printed] ************************************************************************************* [DEPRECATION WARNING]: evaluating u&#39;var1&#39; as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle. This feature will be removed in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. ok: [localhost] =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } TASK [2. var1 should NOT be printed] ********************************************************************************* skipping: [localhost] TASK [3. var1 should be printed] ************************************************************************************* skipping: [localhost] TASK [4. var1 should NOT be printed] ********************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } TASK [5. var1 should NOT be printed] ********************************************************************************* ok: [localhost] =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } TASK [6. var1 should be printed] ************************************************************************************* [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: {{ var1 }} ok: [localhost] =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } TASK [7. var1 should NOT be printed] ********************************************************************************* [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: {{ not var1 }} skipping: [localhost] TASK [9. var1 should be printed] ************************************************************************************* [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: {{ var1|bool }} skipping: [localhost] TASK [10. var1 should NOT be printed] ******************************************************************************** [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: {{ not var1|bool }} ok: [localhost] =&gt; { &#34;msg&#34;: &#34;(\&#34;1\&#34; == \&#34;1\&#34;)&#34; } TASK [11. var1 should NOT be printed] ******************************************************************************** [WARNING]: conditional statements should not include jinja2 templating delimiters such as {{ }} or {% %}. Found: not &#34;{{ var1|bool }}&#34; skipping: [localhost]</pre> <p>まとめると、1番の <code>when: varX</code> または 6番の <code>when: {{ varX }}</code> の書き方をすると、DEPRECATION WARNING は出るが、想定通りの結果になりました。それ以外は、文字列の中身に関わらず同じ結果になりました。</p> <table> <thead> <tr> <th> when の書き方 </th> <th> var1 </th> <th> var2 </th> <th> var3 </th> <th> var4 </th> </tr> </thead> <tbody> <tr> <td> 1. <code>varX</code> </td> <td> ok </td> <td> ok </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 2. <code>not varX</code> </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 3. <code>varX|bool</code> </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 4. <code>not varX|bool</code> </td> <td> ok </td> <td> ok </td> <td> ok </td> <td> ok </td> </tr> <tr> <td> 5. <code>not (varX|bool)</code> </td> <td> ok </td> <td> ok </td> <td> ok </td> <td> ok </td> </tr> <tr> <td> 6. <code>{{ varX }}</code> </td> <td> ok </td> <td> ok </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 7. <code>{{ not varX }}</code> </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 9. <code>{{ varX|bool }}</code> </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> </tr> <tr> <td> 10. <code>{{ not varX|bool }}</code> </td> <td> ok </td> <td> ok </td> <td> ok </td> <td> ok </td> </tr> <tr> <td> 11. <code>not {{ varX|bool }}</code> </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> <td> skipping </td> </tr> </tbody> </table> <p>結局、この DEPRECATION WARNING で <code>|bool</code> を付けろ、と言っている意味はわからずじまいでした。誰か詳しい人いたら教えてください……。</p> <blockquote><p>[DEPRECATION WARNING]: evaluating (ansible_distribution_file_variety == "Amazon" and ansible_distribution_major_version == "2") as a bare variable, this behaviour will go away and you might need to add |bool to the expression in the future. Also see CONDITIONAL_BARE_VARS configuration toggle.. This feature will be removed in version 2.12. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.</p></blockquote> <h2>過去の「Ansible のこの仕様なんなん?」と思って書いた記事</h2> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2016%2F03%2F31%2F232655" title="Ansible でインベントリのホスト変数を when に渡した際の不思議な動作(Ansible 1.9/2.0 共通) - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2016/03/31/232655">muziyoshiz.hatenablog.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2016%2F09%2F29%2F225621" title="Ansible の --extra-vars 引数を安全に使うためのラッパーを書いてみた - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2016/09/29/225621">muziyoshiz.hatenablog.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F01%2F15%2F231213" title="Ansible 2.4 で import_tasks/include_tasks に tags を付けるときの注意点 - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/01/15/231213">muziyoshiz.hatenablog.com</a></cite></p> muziyoshiz SRE NEXT 2020 の個人的おすすめセッション動画 hatenablog://entry/26006613527552578 2020-02-28T22:25:21+09:00 2020-03-16T22:06:15+09:00 SRE NEXT 2020 のセッション動画が公開されました! SRE NEXT 2020 の参加者には、2/23(日)に「SRE NEXT 2020 参加者特典のご案内(セッション動画限定公開)」という Subject のメールが届いていると思います。 このメールに書かれている YouTube の URL から、全セッションの動画を見ることができます! さきほど参加者様全員にSRE NEXT 2020 講演動画プレイリストの限定公開URLをお送りいたしました! (URLのSNSでの拡散はお控えください)また、一般公開は3月中旬を予定しています。 #srenext https://t.co/5… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200127/20200127000336.png" alt="f:id:muziyoshiz:20200127000336p:plain:w640" title="f:id:muziyoshiz:20200127000336p:plain:w640" class="hatena-fotolife" style="width:640px" itemprop="image"></span></div> <h2>SRE NEXT 2020 のセッション動画が公開されました!</h2> <p>SRE NEXT 2020 の参加者には、2/23(日)に「SRE NEXT 2020 参加者特典のご案内(セッション動画限定公開)」という Subject のメールが届いていると思います。</p> <p>このメールに書かれている YouTube の URL から、全セッションの動画を見ることができます!</p> <p><blockquote class="twitter-tweet" data-lang="en"><p lang="ja" dir="ltr">さきほど参加者様全員にSRE NEXT 2020 講演動画プレイリストの限定公開URLをお送りいたしました! (URLのSNSでの拡散はお控えください)<br>また、一般公開は3月中旬を予定しています。 <a href="https://twitter.com/hashtag/srenext?src=hash&amp;ref_src=twsrc%5Etfw">#srenext</a> <a href="https://t.co/5t3SCp6RzA">https://t.co/5t3SCp6RzA</a></p>&mdash; SRE NEXT (@srenext) <a href="https://twitter.com/srenext/status/1231478513758158850?ref_src=twsrc%5Etfw">February 23, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <p>いい機会なので、今回は SRE NEXT 2020 のセッションのなかから、個人的に動画を見ることをおすすめしたいものをご紹介します。これらの動画は3月中旬以降に一般公開される予定ですので、SRE NEXT に参加されていなかった方はひとまずプレゼン資料を読んでお待ちください 🙇</p> <p><strong>※2020-03-16追記</strong><br /> 動画の一般公開が始まりましたので、この記事にも、セッション動画へのリンクを追加しました。</p> <p><blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">お待たせしました!<br>SRE NEXT 2020 セッション動画をYouTubeにて一般公開しました。 <a href="https://twitter.com/hashtag/srenext?src=hash&amp;ref_src=twsrc%5Etfw">#srenext</a><a href="https://t.co/gatomPYY34">https://t.co/gatomPYY34</a></p>&mdash; SRE NEXT (@srenext) <a href="https://twitter.com/srenext/status/1239387979010859008?ref_src=twsrc%5Etfw">2020年3月16日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> </p> <h2>今回のおすすめの基準</h2> <p>有志の方がまとめてくださった <a href="https://qiita.com/Hassan/items/6f7fb1c206f77716ee2a">【SRE Next 2020】発表資料まとめ - Qiita</a> から辿って、プレゼン資料を一通りすべて読みました。</p> <p>そして、そのなかで自分が特に参考にしたいと思った(=僕の現状にマッチした)セッションの動画を 1.5 倍速で再生して見まくりました。今回は、その中で特に参考になったものをおすすめとしてご紹介します。ちなみに、全員見ていそうな基調講演やパネルディスカッションは除外しました。</p> <p>今回ご紹介していないセッションについても、どれも濃い内容でしたので、一通りスライドを読んで、興味のあるキーワードを含むセッションの動画を見てみることをおすすめします。</p> <p><strong>※2020-03-16追記</strong><br /> SRE NEXT 公式サイトのタイムテーブルにも、各セッションのスライドと動画が表示されるようになりました。スライドを見るなら、いまはこちらから見たほうが楽です。神アプデ!</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-next.dev%2Fschedule" title="タイムテーブル | SRE NEXT 2020" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-next.dev/schedule">sre-next.dev</a></cite></p> <h2>SRE 入門</h2> <h3>[A7] サイト信頼性エンジニアリングの原則</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/5tkQ_LexR2w" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fymotongpoo.hatenablog.com%2Fentry%2F2020%2F01%2F27%2F173000" title=" SRE NEXT 2020で「サイト信頼性エンジニアリングの原則」というタイトルで登壇してきました #srenext - YAMAGUCHI::weblog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://ymotongpoo.hatenablog.com/entry/2020/01/27/173000">ymotongpoo.hatenablog.com</a></cite></p> <p><a href="https://sre-next.dev/schedule/#a7">SRE NEXT サイト内の紹介文</a></p> <p>Google の山口さんによる講演。SRE が守るべき基本的なセオリーを1つずつ取り上げて解説されている講演で、SRE 入門としておすすめです。特にポストモーテムの重要性を詳しく解説しています。</p> <p>スライドは公開されていないのですが、上記のブログ記事でその内容が詳しく紹介されています。</p> <h2>メルカリのマイクロサービスの事例</h2> <p>個人的に、メルカリのマイクロサービス化は先進的な事例として以前から注目しています。今回も非常に勉強になりました。</p> <p>メルカリの SRE は、マイクロサービスの基盤を担当する Microservices Platform チームと、サービス開発者と協働する SRE チームに分かれているのですが、SRE NEXT 2020 ではそれぞれのチームの方による発表がありました。</p> <h3>[B7] SRE Practices in Mercari Microservices</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/6enw2nqPB4w" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="1af1bddd18484d61ae524fbaf8dafc4b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#b7">SRE NEXT サイト内の紹介文</a></p> <p>Microservices Platform チームのテックリードの deeeet さんによる講演。</p> <p>Microservices Platform チームの活動でどういうことを工夫しているかを、SLI/SLO, On-call, Toil という3つの観点から紹介されていました。個人的にはこちらが今回のベストセッションでした!</p> <p>以下は内容のメモです。</p> <ul> <li>そもそもなぜメルカリがマイクロサービス化を進めているか <ul> <li><a href="https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/">Successful Software Developmentの三角形</a> <ul> <li>マイクロサービス化によって可能になることをシンプルな図で表しているもの</li> <li>ArchitectureがOrganizationを可能にし、このArchitectureとOrganizationが、Processを可能にする <ul> <li>実現したいのはProcess=Continuous delivery/deployment</li> </ul> </li> <li>マイクロサービスはその技術だけじゃなく、どういう組織を作るかということが重要</li> </ul> </li> <li>SRE と Platform Team の違いを KPI から説明 <ul> <li>SRE は、SLI/SLO を KPI として追ってる</li> <li>Platform Team は、deploy/developer/day など、開発効率の指標を KPI として追ってる</li> </ul> </li> <li>2つの信頼性 <ul> <li>Reliabilities for platform → 講演前半の話</li> <li>Reliabilities for microservices → 講演後半の話</li> </ul> </li> </ul> </li> <li>SLI/SLOを導入するにあたって重要だと考えている点 <ul> <li>適切なプロジェクトマネジメントが行われているかどうか。プロダクトバックログ、スプリント、といったフローに沿って開発しているかどうか <ul> <li>好き勝手に各自が開発していたら、SLI/SLOは機能しない</li> </ul> </li> <li>プロダクトバックログの優先度を決める基準の一つとしてSLI/SLOが使われてこそ意味がある</li> </ul> </li> <li>SLI/SLO <ul> <li>SLO Document <ul> <li><a href="https://landing.google.com/sre/workbook/chapters/slo-document/">SRE Workbook のテンプレート</a> をそのまま使っている</li> </ul> </li> <li>ここで重要なのは Approver(s) と Revisit date <ul> <li>Approver(s): SLOを満たせなかったときに、実際に開発を止める判断をできる人</li> <li>Revisit date: SLI/SLO を更新する日。定義した時点で Revisit dateを決めて、Google Calendarに登録してしまう</li> </ul> </li> <li>SLI specification と implementationを分けて書くのも良いプラクティス <ul> <li>エンジニアだと how を先に考えがちだが、what を先に考えるべき</li> </ul> </li> <li>このドキュメントを GitHub に置いて、GitHub のプルリクで更新</li> <li>SLO Documentの具体例:Spinnaker(Platformチームが、社内のエンジニアに提供するサービス) <ul> <li>マイクロサービスのデプロイの基盤として使っている</li> <li>Spinnaker に対する SLO を設定している <ul> <li>パイプラインの成功率、パイプラインの実行時間</li> </ul> </li> </ul> </li> <li>SLI/SLO の revisit meeting <ul> <li>社内の Slack に対するエゴサーチと、開発者に対する Google Form でのアンケート</li> <li><a href="https://landing.google.com/sre/workbook/chapters/implementing-slos/">SRE Workbook の SLO Decision Matrix</a> に従って SLO を更新している</li> </ul> </li> </ul> </li> <li>On-call <ul> <li>オンコールを誰がするかは、マイクロサービスによってどういう組織に作っていきたいかによる</li> <li>メルカリでは、運用を含めたソフトウェアサイクルを自分たちで回せる、クロスファンクショナルなチームを作っていくこと。だからサービスチームがオンコール対応する <ul> <li>100個くらいあるマイクロサービスを運用チームが見るのは現実的に不可能</li> </ul> </li> <li>k8s のネームスペースを、サービス用と、基盤用で分けている。そこを責任分界点にしている</li> <li>アラートの設定基準 <ul> <li>RED でアラート、USE で調査</li> <li>Actionable Alert=Alert 1個につき、必ずPlaybookを1個用意する <ul> <li>コンポーネントのPlaybookもGitHubで管理している</li> </ul> </li> </ul> </li> </ul> </li> <li>Toil <ul> <li>自分たちはあまりToilという単語を使っていなくて、外部要因で発生するタスクのことをReactive Taskと呼んでいる <ul> <li>Toilもその1つとして扱っている</li> <li>サービスが成長し続ける限り、reactive taskはゼロにはならない、ということを念頭に置くのが大事</li> </ul> </li> <li>PlatformチームがReactive Tasksへの向き合い方をどう変化させてきたか? <ul> <li>チームごとに役割をローテーション(※吉澤注:<a href="https://muziyoshiz.hatenablog.com/entry/2019/05/27/231106">6 Week Release Cycle についての過去の講演のメモ</a>)</li> <li>on-support teamはreactive tasksをどんどんさばく。時間が余ったらtoilを撲滅する</li> </ul> </li> </ul> </li> <li>マイクロサービスのreliabilityのために僕らが取り組んでいること <ul> <li>Platformチームがベストプラクティスを提供し、サービスチーム自身がソフトウェアサイクルを回せるようになってもらう(self-service)</li> <li>2つのベストプラクティス:Design Doc, Production Readiness Check <ul> <li>マイクロサービスの開発前にDesign Docを書いてもらう(テンプレートを提供している)</li> <li>本番運用のために、アプリケーションが満たすべきことをチェックリスト(Production Readiness Check)で確認 <ul> <li>Production Readiness Checkは、GitHubのissue templateとして準備している</li> <li>サービスチームはリリース前にissueを作り、それを自分たちでチェックして、そのレビューをSREなどに依頼できるようになっている</li> </ul> </li> </ul> </li> </ul> </li> </ul> <h3>[C1] 絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/a0D5H8xV9yk" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="8fce8cdcf0fa4b50b9f8bdfb23e5f2dc" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#c1">SRE NEXT サイト内の紹介文</a></p> <p>前半はメルカリの SRE チームの EM を担当されている渋谷さん、後半はメルペイの SRE の EM を担当されている高木さんによる講演。ちなみに、渋谷さんは SRE NEXT 2020 のコアスタッフとして Web サイトなどを担当してくれました。</p> <p>前半の講演のなかで、SRE チームのこれまでの組織体制と、今年の1月に行われた SRE チームの編成のマイナーアップデートについてご紹介されていました。僕は前半の組織体制の話について、興味深く聞きました。</p> <p>以下は前半の内容のメモです。</p> <ul> <li>メルカリ・メルペイそれぞれのチーム体制 <ul> <li>SREチームとMicroservices Platformチームの住み分け</li> <li>SREもマイクロサービス化に貢献している→chocon(チョコン)というプロクシを開発</li> </ul> </li> <li><a href="https://tech.mercari.com/entry/2019/12/01/microservices-migration-progress">メルカリのマイクロサービス移行の進捗 (2019年冬) - Mercari Engineering Blog</a></li> <li>いままではSREが本番環境を支えるいわば「門番」だった <ul> <li>門番モデルではSREチームがボトルネックになるリスクがある</li> <li>マイクロサービス化により開発チームのスケーラビリティが上がっていくのに追従していけるよう、SREチームの体制もアップデートしたいと考えた</li> </ul> </li> <li>今月(2020年1月)から、SREチームの編成をマイナーアップデートした <ul> <li>SRE Core:DatastoreやMail/SMS deliveryなどの共通基盤を担う</li> <li>SRE Edge:クライアントから直接リクエストを受ける部分に近いCDN、ロードバランサ、ゲートウェイなどを担う</li> <li>SRE Advocacy:マイクロサービス開発チームの一員として、信頼性向上やオペレーションを担う</li> </ul> </li> </ul> <h2>負荷テスト</h2> <h3>[B2] 計画的に負荷リスクを排除するためのキャパシティプランニング</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/eB14bNvEGVs" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="c51d71b9ed584554b67b0aace451617b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#b2">SRE NEXT サイト内の紹介文</a></p> <p>タップル誕生の SRE の赤野さんによる講演。</p> <p>負荷試験の実行環境を、バックエンドエンジニアなら誰でも作れるようにセルフサービス化しています。さらに、その負荷試験の結果を施策の導入可否にまで影響させているとのこと。ここまで実現しているのは本当にすごい!</p> <p>以下は内容のメモです。</p> <ul> <li>タップルSREが負荷的な観点でのセキュアベースになるための取り組み <ul> <li>セキュアベース:挑戦できる環境づくり</li> <li><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B07HYQ9KDQ/muziyoshiz-22/">セキュアベース・リーダーシップ</a></li> </ul> </li> <li>定期的に負荷試験を実施できる環境づくり <ul> <li>負荷試験用のAWSアカウントを別に用意 <ul> <li>できるだけ本番環境に影響が出ない、という安心感を得るため</li> <li><a href="https://locust.io/">Locust</a>クラスタをFargateで稼働</li> <li>バックエンドエンジニアなら誰でも負荷試験環境を構築できるようにスクリプトを整備</li> </ul> </li> <li>限界値を把握するためのロードテスト、スパイクテスト <ul> <li>いくつかのテストの種類</li> <li>ECSタスク数ごとのスパイク限界値を測定→予定されたスパイクアクセスに対応できるか確認したいため</li> <li>性能劣化をチェックするテスト→SREは実施前のテスト計画のレビューと、テスト結果のレビューのみしている</li> </ul> </li> <li>SREが決めたSLOはあったが、UXを考慮したSLOではなかった</li> <li>レイテンシSLOを決めるにあたって、API遅延体感チェック会を実施 <ul> <li>SLOを満たさない場合はリリースしないようにしたい、という目的でこの会を開催した</li> <li>「全体リクエストのレイテンシのp90が223ms以下で、1ヶ月のうち99%以上稼働」に決定</li> <li>現在もこのSLOで運用している</li> </ul> </li> </ul> </li> <li>施策開発フローに負荷レビューを組み込む <ul> <li>施策のロードマップを立てた段階で、SREが、負荷の観点から実現可能かをチェック</li> <li>すべての施策についてはレビューしきれないので、「DAU増加」か「カードのフリック数の増加」を狙いとした施策のみレビューしている</li> <li>レビューに必要な情報はプランナーに提出してもらっている</li> <li>PUSHについてはレビュー結果をもとに、ECSタスク数や、PUSHを分割する・しないを判断する</li> </ul> </li> </ul> <h2>障害対応</h2> <h3>[A3] freee のエンジニアは障害から何を学び、どう改善しているのか?</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/P380-bWVS0A" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="978d3411e39b4d2a8bd582460cbcf08d" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#a3">SRE NEXT サイト内の紹介文</a></p> <p>freee の SRE 坂井さんによる講演。過去に発生した障害をきっかけに、障害対応フローをどのように整備したかを解説してくださいました。自分たちの障害対応フローを見直すうえで、とても参考になりそうです。</p> <p>以下は内容のメモです。</p> <ul> <li>今日のゴール <ul> <li>障害対応に課題を感じている人が、改善のための第一歩を踏み出そうと思えるようになること</li> </ul> </li> <li>freeeのプロダクトは、お金や人に関する情報を扱うものが多い <ul> <li>会計freeeは電子決済等代行業に当たる</li> <li>2019年に上場し、以前にも増して、障害に対してよりシビアな対応が求められる</li> </ul> </li> <li>障害をゼロにすることは難しい <ul> <li>障害を受け入れながらも、安定したプロダクト、という相反するものを目指す</li> </ul> </li> <li>自分が入社した頃(2016年)から、障害対応フローがどう変わってきたか <ul> <li>徐々にポストモーテムを書くようになるが、フォーマットや情報の粒度、書く場所もバラバラ → 障害対応の学びが属人的</li> <li>SOC1取得に向けた準備を始めた2018年に、準備の一環で障害対応フローが策定された(レベル1〜5の障害定義など)</li> <li>2018年10月(月末)に起きた障害で全サービス停止</li> <li>障害から得られた組織としての学び <ul> <li>障害対応フローのブラッシュアップ(初動対応、役割、社内外コミュニケーション)</li> <li>障害対応エリアの設置(物理的に集まれるエリア「ブリッジ」)</li> <li>初動の省力化(チャットボットでのドキュメント検索、ポストモーテムの自動作成、関係者への通知の自動化)</li> </ul> </li> </ul> </li> <li>振り返りのためのいろいろな取り組み <ul> <li>freeeの開発文化「失敗して攻めよう」</li> <li>失敗.js</li> <li>割れ窓を改善し隊</li> <li>alertを振り返り隊(今年から始めた新しい取り組みで、成果が出るかはこれから)</li> </ul> </li> <li>まとめ <ul> <li>自分たちの組織やプロダクトに合った障害対応フローを作る</li> <li>大きな障害は学びの宝庫</li> <li>障害からの学びが属人的にならないように工夫する</li> </ul> </li> </ul> <h2>SLI/SLO</h2> <h3>[C4] SLO Review</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/bwHOov2Ti-A" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="3152b144d1d34befbda1d90717b32dda" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#c4">SRE NEXT サイト内の紹介文</a></p> <p>Quipper の SRE であり、SRE NEXT 2020 のコアスタッフでもあった chaspy さんの講演。</p> <p>2019年に Quipper 社内で SLO をどうやって徐々に導入していったか、という事例紹介です。内容ももちろん勉強になるんですが、chaspy さんはとにかく話がうまくて、聞いてて面白いです。</p> <p>以下は内容のメモ。</p> <ul> <li>最近受講した:<a href="https://ja.coursera.org/learn/site-reliability-engineering-slos">Coursera の Site Reliability Engineering: Measuring and Managing Reliability コース</a></li> <li>エラーバジェット導入に向けて、SLO導入をどういうステップを踏んで実現したか <ul> <li>エラーバジェット導入は今後の課題</li> </ul> </li> <li>reliabilityとagilityのバランスを取るためのツールがSLO <ul> <li>マイクロサービスに取り組むなら必須のツール</li> <li>依存先のサービスの信頼性を、依存元が超えることはできない</li> </ul> </li> <li>Quipperでのケーススタディ <ul> <li>いろいろなツールでメトリクスを取り、すべてをDataDogに送っている <ul> <li>Synthetics Clients:Pingdom</li> <li>Frontend:Centry</li> <li>Load Balancer:Nginx, envoy</li> <li>Application:New Relic</li> </ul> </li> <li>今年のSREチームの目標:Self-Contained <ul> <li>開発チームが自分たち自身のみでプロダクト開発を完結できること、を目指している</li> <li>そのための支援をSREチームがしていく</li> <li>すでに提供している:Design Doc、Production Readiness Check、インフラ管理の移譲(Terraform)</li> <li>その延長でSLI/SLOにも取り組んでいる</li> </ul> </li> <li>2019年に行った取り組み <ul> <li>Define the Ownership <ul> <li>多拠点に複数の開発チーム。各マイクロサービスに誰がオーナーシップを持つのかの定義から</li> <li>Design Docでステークホルダーを明確化(Design DocはSREがレビューする)</li> <li>オーナーを決める文化が根付いてきたので、この活動はおすすめ</li> </ul> </li> <li>SLO review by myself <ul> <li>まずは自分(chaspyさん自身)でやってみた</li> <li>誰でもできる方法 <ul> <li>週1でSlackにリマインダを飛ばして、その時点でのSLIをDataDog上で確認し、GitHub Issueに記録する</li> </ul> </li> <li>Availability Table、どれくらいの稼働率が良いのかの肌感を得た(99.9%くらいが良さそう)</li> <li>SLO reviewや、ペアプロやユニットテストのような「良い習慣」なのではないかと気づいた</li> </ul> </li> <li>SLO review with Devs <ul> <li>開発者からいろいろ要望が出てきて対応した <ul> <li>Dos detector(Rate limitting)がSLIのノイズになる</li> <li>マイクロサービスで同じドメイン名を共有している(パスは違う)場合に、ログにパスを付与</li> </ul> </li> </ul> </li> <li>Set Error Budget Policy <ul> <li>今年の4月くらいからエラーバジェットを決めて、エグゼクティブと合意してやっていけたらと思ってる</li> </ul> </li> </ul> </li> </ul> </li> <li>SLO導入に向けておすすめするポイント <ul> <li>最初のSLIはSREが設定したほうがいい。プロダクトに詳しいのは開発者だが、今取れる情報についてはSREのほうが詳しい <ul> <li>AvailabilityやLatencyなど、当然見ると思われるものを最初に設定しておけばよかったと反省している</li> </ul> </li> <li>SLI/SLOの設定もコードしたほうが良い(Terraform)</li> <li>少ない時間で成果を出すことを意識する <ul> <li>ドキュメントを最初から書いておけば楽だったと思う</li> <li>15チームにそれぞれ説明して、徐々に導入していった</li> </ul> </li> </ul> </li> </ul> <h2>開発者と SRE</h2> <h3>[C6] Designing fault-tolerant microservices with SRE and circuit breaker centric architecture</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/3ybhOFeDzvE" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <script async class="speakerdeck-embed" data-id="cd1a7fdf3b8b4b3298d6f49f2fb4e4da" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p><a href="https://sre-next.dev/schedule/#c6">SRE NEXT サイト内の紹介文</a></p> <p>Cookpad の海外チームの SRE を担当している渡辺さんによる講演。</p> <p>この講演での話題は、新しい技術スタック(機械学習関係)を採用した、試作的なプロダクトを導入するケースです。その試作的なプロダクトがメインのサービスに与える影響の範囲を限定しつつ、どうやって試作を行うチームの生産性を損なわないようにしたか、という事例紹介でした。</p> <p>マイクロサービスの特徴がうまくマッチした事例として、こういうケースがあるのか!と参考になりました。</p> <p>以下は内容のメモです。</p> <ul> <li>Cookpad Global(Cookpad のグローバルサービス) <ul> <li>23 backend developers</li> <li>5 SREs</li> </ul> </li> <li>Search-v2, ML APIs:新規機能、実験的な機能 <ul> <li>これを入れていくときのアプローチについての講演</li> <li>特殊な状況での事例紹介</li> </ul> </li> <li>独立性の高いチームと、既存のチームの間での衝突を少なくするために、circuit breaker、SLOを導入している</li> <li>technology stackをcookpadでは制限している <ul> <li>しかし、新しい機能では、rails以外の言語を使う必要が出てきた</li> </ul> </li> <li>24/7サポートには8人のエンジニアが欲しい。いろいろな本で8人と書かれている</li> <li>関係者の間での調整のためにdesign documentを書く</li> <li>それにプラスアルファで、目的別の対策</li> <li>Delegation and resource isolationも必要 <ul> <li>AWSアカウントを分離して、VPC peering</li> <li>自分たちが使う技術の範囲は自分たちで運用する(SREが管理するのではなく、MLのdevelopersが管理する)</li> </ul> </li> <li>circuit breaker <ul> <li>Traefik</li> <li>SLOに応じて設定。そのSLOはDesign Docで調整</li> </ul> </li> <li>開発者がSLOを決めるのは難しい。だからSREがavailability classを提供している <ul> <li>availability classを定義し、それぞれのサービスの目標値を決める。それをcircuit breakerの設定に反映させる</li> </ul> </li> <li>PrometheusとAlertmanagerのコンフィグはJsonnetで書いている <ul> <li>よく使う設定はSREがライブラリ化してる</li> </ul> </li> <li>Search-v2についてはオンコール対応不要にした <ul> <li>動かないときはSearch-v1にフォールバックするようにした</li> </ul> </li> <li>Bonus Track <ul> <li>オンコールローテーションルールは、そのチームのメンバーの好き好きによって決めるべきで、組織全体の統一ルールを作るべきではない</li> <li>Cookpadのバックエンドエンジニアは世界中にいるので、1日を午前午後で分けて、営業時間内だけオンコール対応している</li> <li>SREも日本とイギリスで分散しているので、同様にローテーションしている</li> </ul> </li> </ul> <h3>[D4] 100万回線のIoT通信を支えるソラコムにおけるOpsDevの実践</h3> <iframe width="560" height="315" src="https://www.youtube.com/embed/fQajSy4iOJ4" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> <iframe src="//www.slideshare.net/slideshow/embed_code/key/ieK7OfNPTswYOG" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <p> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/SORACOM/100iot-opsdev-sre-next-2020-in-tokyo" title="100万回線のIoT通信を支える ソラコムにおけるOpsDevの実践 / SRE NEXT 2020 in TOKYO" target="_blank">100万回線のIoT通信を支える ソラコムにおけるOpsDevの実践 / SRE NEXT 2020 in TOKYO</a> </strong> from <strong><a href="https://www.slideshare.net/SORACOM" target="_blank">SORACOM,INC</a></strong> </div></p> <p><a href="https://sre-next.dev/schedule/#d4">SRE NEXT サイト内の紹介文</a></p> <p>ソラコムの OpsDev エンジニア(DevOps エンジニアの誤記じゃないです)の酒井さんによる講演。開発者が全員で運用し、サポートまで行う現場の事例紹介でした。</p> <p>以下は内容のメモです。</p> <ul> <li>OpsDev Engineer≒SRE</li> <li>開発と運用の基本原則 <ul> <li>開発者:全員がDevOpsを実践。運用もする</li> <li>OpsDevエンジニア(≒SRE):運用作業の傍ら、運用作業省力化のための開発をする</li> <li>チーム全体で運用に責任を持つ</li> </ul> </li> <li>運用しやすいシステムを作るための基本的な原則 <ul> <li>Horizontal Scalability:小さいサーバを横に並べることでスケールアウトできる設計</li> <li>Built-in Resilience:障害を前提とした設計、障害が起きたシステムを単独でプロセス再起動できる設計</li> </ul> </li> <li>サポートプライマリ制度:サポート・運用タスクについてはエンジニアが交代制で対応する <ul> <li>お客様と直接コミュニケーションすることで改善点に気づける、モチベーションが上がる、自身の問い合わせスキルが上がる</li> </ul> </li> <li>一部のエンジニアは嫌がるのでは?トレードオフがあるのでは? <ul> <li>ソラコムのリーダーシップステートメントで、上記のような行動を推奨 <ul> <li>リーダーシップステートメントに沿って行動することで評価も上がる</li> </ul> </li> <li>サポート・運用タスクのタスクコントロールを工夫</li> </ul> </li> <li>インシデント対応 <ul> <li>なにか怪しいことがあったら #andon チャンネルで報告。間違った報告でも責めない</li> <li>チャットボットで障害対応をサポート(障害報告書のひな型作成など)</li> <li>ポストモーテム:2週間のイテレーションの最後に関係者全員で andon 振り返り</li> </ul> </li> </ul> <p>ちなみに、過去に SRE Lounge #8 で酒井さんの講演を聞いたことがあって、その時の内容を以下の記事にまとめています。SRE NEXT の講演に含まれていない内容もありますので、興味が湧いた方はこちらもどうぞ。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F03%2F15%2F220735" title="SRE Lounge #8 の感想(取り入れたいと思った活動の話を中心に) - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/03/15/220735">muziyoshiz.hatenablog.com</a></cite></p> muziyoshiz SRE NEXT 2020 にスタッフ参加しての感想(ロゴデザイン、CFP レビュー、司会などの裏話) hatenablog://entry/26006613503012348 2020-01-27T00:06:40+09:00 2020-01-27T09:14:40+09:00 SRE NEXT ご参加いただきありがとうございました! sre-next.dev 1月25日(土)に、SRE に関する国内初の大規模テックカンファレンス、SRE NEXT 2020 が開催されました。私も、こちらのイベントにコアスタッフとして参加していました。参加者、登壇者、スポンサーおよびすべてのスタッフの皆様、本当にありがとうございました。お疲れさまでした! 発表内容は全然聞けていない(詳しくは後述)ので、内容についての感想はまだ書けません。しかし、「参加ブログを書くまでが SRE NEXT」と言われてしまったので、取り急ぎスタッフとしての感想を書いてみます。 スタッフ参加の経緯 元々 … <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200127/20200127000336.png" alt="f:id:muziyoshiz:20200127000336p:plain:w640" title="f:id:muziyoshiz:20200127000336p:plain:w640" class="hatena-fotolife" style="width:640px" itemprop="image"></span></div> <h2>SRE NEXT ご参加いただきありがとうございました!</h2> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-next.dev%2F" title="SRE NEXT 2020" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-next.dev/">sre-next.dev</a></cite></p> <p>1月25日(土)に、SRE に関する国内初の大規模テックカンファレンス、SRE NEXT 2020 が開催されました。私も、こちらのイベントにコアスタッフとして参加していました。参加者、登壇者、スポンサーおよびすべてのスタッフの皆様、本当にありがとうございました。お疲れさまでした!</p> <p>発表内容は全然聞けていない(詳しくは後述)ので、内容についての感想はまだ書けません。しかし、「参加ブログを書くまでが SRE NEXT」と言われてしまったので、取り急ぎスタッフとしての感想を書いてみます。</p> <h2>スタッフ参加の経緯</h2> <p>元々 <a href="https://sre-lounge.connpass.com/">SRE Lounge</a> のボランティアスタッフだったので、こういうイベントを開催したいというアイディアは北野さんや小熊さんから聞いていて、最初から参加させてもらってました。</p> <p>本格的に動き出したのって、4月頃の飲み会でしたっけ?(うろ覚え)</p> <p>この頃に、プロジェクト管理に <a href="https://backlog.com/ja/">Backlog</a> を使うことを僕から提案して、SRE NEXT のための Backlog スペースを用意しました。最初に作られた課題(チケット)を見てみたら、作成日は2019年4月14日でした。</p> <h2>スタッフとして担当したこと</h2> <p>先に自分がやってないことから書くと、イベント全体のディレクションや、当日の設備周りなどは、他の優秀なメンバーに任せっきりにしてしまってました。</p> <p>あとから考えると、僕は勉強会の運営側にまわったことがほとんどなくて、「SRE NEXT をどうしたい」というビジョンが全然無かったなぁと。SRE Lounge みたいな話がたくさん聞けるイベントがあったらいいなあ、くらいでしたね。</p> <p>そのため、僕はサポート役として「面倒だけどやらないとまずい」系のタスクを色々拾ってました。</p> <ul> <li>SRE NEXT の Backlog スペースのアカウント管理</li> <li>ロゴデザインの発注</li> <li>Tシャツデザイン、サイズ確認、発注、配布</li> <li>ステッカー発注</li> <li>CFP のレビュー(複数人でのレビュー会に参加)</li> <li>Room A(メイン会場)の司会</li> </ul> <h2>ロゴ、ノベルティデザイン</h2> <p>デザイン関係については、いままで全くやったことがなかったので、四苦八苦しながら進めました。</p> <p>新しくイベントを始めたい場合、僕と同じように困る人も多いと思うので、ロゴとノベルティに関する情報をまとめておきます。<strong>「SRE NEXT みたいにいい感じに作ってよ」</strong> と言われた場合、以下の通りにすればなんとかなります。</p> <p>ちなみに、以下の情報は全部 Backlog の課題に記録しておいた情報から引っ張ってきました。Backlog は素晴らしいサービスですね! なんと SRE も<a href="https://www.wantedly.com/projects/355602">東京</a>、<a href="https://www.wantedly.com/projects/355344">福岡</a>、<a href="https://www.wantedly.com/projects/355607">京都</a>で募集中みたいですよ!(SRE NEXT ツールスポンサー関係者による熱いダイレクトマーケティング)</p> <h3>ロゴ</h3> <p><a href="https://99designs.jp/logo-design/contests/create-logo-open-source-software-embulk-463935">Embulk</a> や <a href="https://99designs.jp/logo-business-card-design/contests/%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E8%A8%BC%E5%88%B8%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AB-%E3%83%9D%E3%83%BC%E3%83%88%E3%83%95%E3%82%A9%E3%83%AA%E3%82%AA-%E3%82%92%E3%83%A2%E3%83%81%E3%83%BC%E3%83%95%E3%81%AB%E3%81%97%E3%81%9F%E4%BC%9A%E7%A4%BE%E3%81%AE%E3%83%AD%E3%82%B4%E3%83%9E%E3%83%BC%E3%82%AF%E3%82%92%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84-577621">Folio</a> のデザインの事例を見て、ここでよさそうということで発注先を <a href="https://99designs.jp/">99designs</a> に決定。</p> <p>色々プランがあって悩んだのですが、<a href="https://99designs.jp/pricing">ロゴコンペのブロンズプラン</a>を利用しました。「非公開コンペ」などのオプションは付けませんでした。</p> <p>そして説明文を書いて発注。公開コンペなので、具体例はこちらから確認できます。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2F99designs.jp%2Flogo-design%2Fcontests%2F%25E6%2596%25B0%25E3%2581%2597%25E3%2581%2584%25E3%2582%25BF%25E3%2582%25A4%25E3%2583%2597%25E3%2581%25AE%25E3%2582%25A8%25E3%2583%25B3%25E3%2582%25B8%25E3%2583%258B%25E3%2582%25A2-sre-%25E5%2590%2591%25E3%2581%2591%25E3%2581%25AE%25E6%258A%2580%25E8%25A1%2593%25E3%2582%25AB%25E3%2583%25B3%25E3%2583%2595%25E3%2582%25A1%25E3%2583%25AC%25E3%2583%25B3%25E3%2582%25B9%25E3%2581%25AE%25E3%2583%25AD%25E3%2582%25B4%25E3%2583%259E%25E3%2583%25BC%25E3%2582%25AF%25E3%2582%2592%25E3%2583%2587%25E3%2582%25B6%25E3%2582%25A4%25E3%2583%25B3%25E3%2581%2597%25E3%2581%25A6%25E3%2581%258F%25E3%2581%25A0%25E3%2581%2595%25E3%2581%2584-918741" title="muziyoshiz さんの新しい ロゴデザイン を99designsでチェックしましょう" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://99designs.jp/logo-design/contests/%E6%96%B0%E3%81%97%E3%81%84%E3%82%BF%E3%82%A4%E3%83%97%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2-sre-%E5%90%91%E3%81%91%E3%81%AE%E6%8A%80%E8%A1%93%E3%82%AB%E3%83%B3%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9%E3%81%AE%E3%83%AD%E3%82%B4%E3%83%9E%E3%83%BC%E3%82%AF%E3%82%92%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84-918741">99designs.jp</a></cite></p> <p>優秀なデザインが集まるか不安だったのですが、最終的にはデザイナー15名から応募がありました。説明文は日本語で書いたのですが、デザイナーに日本人はいなかったようで、やり取りは結局すべて英語でした。</p> <p>その多数のデザインから最終案まで少しずつ絞っていくのが大変で、もらったデザインの画像を Slack に貼り付けて、poll 機能で投票してもらう、という作業を何回も繰り返しました。</p> <p>99designs 自体にも<a href="https://support.99designs.com/hc/ja/articles/204109499">アンケート機能</a>があるのですが、選択肢が最大8個までという制限があります。99designs では1人のデザイナーが、1個のデザインの複数のバリエーションを投稿してくるので、そのなかから大体の方向性を絞りたい、という段階では全然使えませんでした。最終選考のときだけは使えたかもしれませんけど……。</p> <h3>Tシャツ</h3> <p>Tシャツは、僕の方でロゴを加工して、いくつかデザイン案を作って、Slack の poll 機能で選考。デザイン決定後、僕が以前に使ったことのある <a href="https://www.firstball.net/">FirstBall</a> に発注しました。</p> <p>デザインのベースは <a href="https://www.firstball.net/itemDetails/30">TR180/Trysail5.9oz Tシャツ</a>。色はスタッフ用がサックスブルー、プレゼント用(登壇者、個人スポンサー)がブラック。スタッフ用は「スタッフが見つかりやすいように目立つ色」「SRE 本が青だからやっぱり青系でしょ」というコンセプトでした。</p> <p>FirstBall では、印刷してから3ヶ月なら版の追加料金がかからないため、「試しに1枚刷る→問題なければ全員分刷る」というステップを取りました。実際、最初の試し刷りでは、実際に着てみるとロゴが大きすぎることに気づいたので、このステップを取ってよかったです……。</p> <p><figure class="figure-image figure-image-fotolife" title="一歩間違えたらスタッフ全員に配布されていたクソデカロゴT"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200126/20200126232601.jpg" alt="f:id:muziyoshiz:20200126232601j:plain" title="f:id:muziyoshiz:20200126232601j:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>一歩間違えたらスタッフ全員に配布されていたクソデカロゴT</figcaption></figure></p> <h3>ステッカー</h3> <p>ステッカーって、扱ってくれる会社も多いし、選べるオプションも多くてホントに困りました。そのため、以下の基本方針を決めてから、いくつかのサイトを見て回りました。</p> <ul> <li>ノートパソコンに貼ったときに剥がしやすい</li> <li>光沢のある感じよりは、マットな感じにしたい</li> <li>発注枚数は1000枚(参加者分だけなら500枚で足りるが、少し余分に作る)</li> </ul> <p>この条件を満たすなかで、一番安かったのは<a href="https://www.digitaprint.jp/simple_order.php">デジタ</a> でした。以下のオプションで発注すると、SRE NEXT ステッカーと同じ感じになります。</p> <ul> <li>アート紙</li> <li>再剥離のり</li> <li>マットラミネート</li> <li>四角形裁ち落とし</li> <li>5x5cm</li> <li>裏スリットなし</li> <li>シートの形は40パス以内無料</li> <li>7営業日</li> </ul> <p>Sのところでステッカーの外枠もカーブしてるのが素敵。こちら、スタッフの奥さん(デザイナーの方)のアイディアで、パスの調整までしてくれました。</p> <p><figure class="figure-image figure-image-fotolife" title="Sのところでステッカーの外枠もカーブしてるのがチャームポイント"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200126/20200126233252.jpg" alt="f:id:muziyoshiz:20200126233252j:plain" title="f:id:muziyoshiz:20200126233252j:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Sのところでステッカーの外枠もカーブしてるのがチャームポイント</figcaption></figure></p> <h2>CFP のレビュー</h2> <p>スタッフの仕事の中で一番楽しかったのが、CFP のレビューでした。</p> <p>SRE NEXT に来場した方はわかると思うのですが、実績があって、プレゼンも面白いエンジニアからの CFP が本当にたくさん届きました!</p> <p>そういう優秀なエンジニアが書いた CFP の具体例にたくさん触れるのは勉強になりましたし、更にそれを自分と同様に SRE をしているメンバーと「ここがよい」「この点ではこちらがよい」と議論するのは楽しかったです。ここだけで、苦労の元が取れた気がしました。</p> <p>反省点としては、自分にとっての面白さだけでセッションを投票してしまって、SRE NEXT 全体としてのバランスにはあまり配慮できなかったことでした。そのあたりは他のメンバーに助けられましたが、そういう意識が最初からあれば、もっとうまくできたのでは……と反省したところです。</p> <h2>Room A(メイン会場)の司会</h2> <p>いままで、小さな勉強会の司会くらいしか経験したことなかったので、それと同じくらいの気分で「Room A はメイン会場だから、最初から最後まで面白いセッションが聞けるだろう」と立候補しました。ただ、もう全然そんなことなかったですね。面白くなかった、という意味ではなくて、全然集中できなかった、という意味で……。</p> <p>今回は参加者が400名を超え、メイン会場のキャパは Room A〜B を繋いで大部屋にした状態で300名。これが小さな勉強会と同じはずもなく、</p> <ul> <li>セッション開始時以外にもたくさんある各種アナウンス</li> <li>音響スタッフとの、オープニング動画を流すタイミングの調整</li> <li>登壇者への段取りの説明</li> <li>質疑応答をする・しないのタイムスケジュール管理</li> <li>インカムからの指示による臨時のアナウンス追加</li> </ul> <p>などなどがあり、講演を聞いてる最中もまったく集中できませんでした(気づくのが遅い)。</p> <p>途中で代わってもらえたら、もうちょっとイベント自体を楽しめたかもですね。前日に急遽決まったオペレーションも多かったので、司会業をうまくマニュアル化できず、複数人で分担できなかったというのが今回の反省点でした。1人で仕事を抱える SRE はダメな SRE……。</p> <p>聞いていた方はどうだったんでしょうね。耳障りでなければよかったんですけど。とりあえず今日になって <a href="https://twitter.com/search?q=%23srenext%20%E5%8F%B8%E4%BC%9A&amp;src=recent_search_click">#srenext 司会</a> で検索して、特にネガティブなコメントはなかったので一安心してるところです。</p> <p><figure class="figure-image figure-image-fotolife" title="基調講演に使われたメイン会場(photo by weekendcycler)"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20200126/20200126233556.jpg" alt="f:id:muziyoshiz:20200126233556j:plain" title="f:id:muziyoshiz:20200126233556j:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>基調講演に使われたメイン会場(photo by <a href="https://twitter.com/weekendcycler">weekendcycler</a>)</figcaption></figure></p> <h2>SRE NEXT プロジェクト全体を通しての感想</h2> <p>大変でしたけど、大規模なテックカンファレンスの裏側を体験することができて面白かったです。また、自分の興味がある技術分野で、同じ分野にいる同業者と知り合いになれて、普段会わない人(特に自分より若い人)の考えを聞く機会がたくさん得られました。</p> <p>SRE NEXT 2021 が開催されるかはまだわかりませんが、SRE として働いていて(あるいはまだ働いていないけど興味があって)、この分野の技術コミュニティに参加したいという方には、スタッフとして参加することをお勧めしたいと思います。もし <a href="https://sre-lounge.connpass.com/">SRE Lounge</a> に参加したことがなければ、まずはこちらに参加してみてください。<a href="https://srelounge.slack.com/">SRE Lounge の Slack ワークスペース</a> に入ってもらえたら、次回の開催情報もそのうち流れると思います。</p> <p>さて、これからしばらくは全講演のスライドを見て、感想ブログを読み漁る生活だ……。</p> muziyoshiz 2019 年に SRE をしながら考えが変わったこと hatenablog://entry/26006613491022585 2019-12-30T21:07:07+09:00 2019-12-30T21:07:07+09:00 今回の記事は年末スペシャルです。 僕が SRE をしながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました(職場の理解のおかげです。いつも感謝してます)。 ただ、それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。なので、今回はそれらの記事を引っ張りながら、今年 SRE をしながら考えていたことをつらつらと書いていこうと思います。 この1年で考えが大きく変わったこと SRE のあるべき組織体制について、1年前はこう考えていました。 複数の開発チームをまたぐ形で SRE をマトリックス的に配置して、S… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191230/20191230205919.png" alt="f:id:muziyoshiz:20191230205919p:plain" title="f:id:muziyoshiz:20191230205919p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>今回の記事は年末スペシャルです。</p> <p>僕が SRE をしながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました(職場の理解のおかげです。いつも感謝してます)。</p> <p>ただ、それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。なので、今回はそれらの記事を引っ張りながら、今年 SRE をしながら考えていたことをつらつらと書いていこうと思います。</p> <h2>この1年で考えが大きく変わったこと</h2> <p>SRE のあるべき組織体制について、1年前はこう考えていました。</p> <ul> <li>複数の開発チームをまたぐ形で SRE をマトリックス的に配置して、SRE はアプリの開発状況を細かく把握しながら監視・運用すべき</li> </ul> <p>ただ、この1年で考えが変わり、いまはこう考えています。</p> <ul> <li>SRE をマトリックス的に配置するのは、確かに、開発速度を一時的に上げるのには効果的</li> <li>ただ、そんなスキルがある SRE をたくさん集めるのは難しいし、集められたとしてもそんな働き方をさせたらすぐ疲弊して退職しかねない</li> <li>持続性を優先するなら、アプリの監視・運用の責任は開発チームが持ち、SRE はそれを支えるシステム作りに労力を割くべき</li> </ul> <p>こう書くと、なんか、結局当たり前の結論に帰ってきてしまった感じがしますね……。SRE って元々そういうものだろ、と言われそうな気もします。ただまあ、どういう過程を経てそういう考えに落ち着いたのかを振り返ってみます。</p> <h2>1年前(2018年末)に考えていたこと</h2> <p>去年の年末の時点で、僕個人はこういう状況でした。</p> <ul> <li>SRE は複数の開発チームをまたぐ形でマトリックス的に配置されていた</li> <li>僕個人は、Play 化プロジェクトに関わる開発チームに参加して、監視・運用全般を担当していた</li> </ul> <p>2018年前半から、「SRE をマトリックス的に配置したほうがうまくいくだろう」という議論があり、それまで1つの SRE チームだったものを複数の開発チームにまたがる形にしました。Dev と Ops が分離してしまっていた当時の状況では、それが最適なチーム構成だろう、と僕も強く同意していました。</p> <p><figure class="figure-image figure-image-fotolife" title="SRE Lounge #5 の発表資料からの引用"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191230/20191230210236.png" alt="f:id:muziyoshiz:20191230210236p:plain" title="f:id:muziyoshiz:20191230210236p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>SRE Lounge #5 の発表資料からの引用</figcaption></figure></p> <p>このあたりの話に興味のある方は、SRE チームの黎明期を知るメンバに繰り返しインタビューして書いた発表資料やブログ記事がありますので、そちらをぜひどうぞ。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F09%2F27%2F234149" title="SRE Lounge #5 にて Backlog における SRE の事例について講演しました - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/09/27/234149">muziyoshiz.hatenablog.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab.com%2Fja%2Fblog%2Fbacklog%2Fbacklog-sre-service-level-management%2F" title="サービス品質向上のためにBacklogのSREが行ってきたサービスレベル管理の取り組み | 株式会社ヌーラボ(Nulab inc.)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://nulab.com/ja/blog/backlog/backlog-sre-service-level-management/">nulab.com</a></cite></p> <p>で、この人員配置の中で、僕は2018年4月から今年の7月まで「Play 化プロジェクト」というリプレイスプロジェクトに参加してました。もちろん、SRE 同士の横の連携はありましたが、このプロジェクトの状況を熟知して動いていた SRE は1人だけという状況でした。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fthe-story-of-large-scale-replacement-with-play-framework-over-4-years%2F" title="時系列でみる!4年の歳月をかけてPlay Frameworkで「大規模リプレイス」した話【Backlog Play 化プロジェクト】 | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/the-story-of-large-scale-replacement-with-play-framework-over-4-years/">backlog.com</a></cite></p> <p>開発チームに SRE が入り、インフラとアプリの両方に目配せすることで、いろいろな問題を未然に防げたという手応えはありました。その一方で、このプロジェクトで SRE として1人頑張り続けることのつらさも強く感じていました。2018年末はそんな状況でした。</p> <h2>2019 年に考えていたこととやったこと</h2> <p>そこから1年経って、2019年末(現時点)の状況はこう変わりました。</p> <ul> <li>SRE は開発チームから出て SRE チームに所属する。SRE チームは開発チームを支援するかたわら、SRE 主導での改善プロジェクトも進める</li> <li>アプリの監視は、開発チームに徐々に移行しつつある</li> <li>僕個人は、改善プロジェクトの1つを進めている(※この内容も、いずれテックブログに書きます)</li> </ul> <p>SRE と開発チームの分離は、2019年の年始に、SRE が改善活動を主導できる体制作りを目的に行われました。実は、僕は当初この分離には反対していました。</p> <p>しかし、リプレイスプロジェクトでの経験を経て、<strong>SRE を特定の開発チームに割り当てるのは、短期的には有効だけど、長期的には持続可能じゃない</strong>という考えに変わりました。</p> <p>考えが変わった理由の第一は、開発速度が早い開発チームに SRE として張り付け続けるつらさを実体験したからです。リリースが少ない安定したサービスならともなく、リリースが日々活発に行われるサービスでは、張り付けられた SRE の負荷が大きすぎる。これでは SRE はすぐ疲弊して、退職されてしまうだろうと……。どれくらい大変かの具体的な話は、リプレイスプロジェクトが終わったときのブログ記事に書いたので、よかったらこちらをどうぞ。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fhow-sre-resolved-the-problems-on-large-scale-replacement-with-play-framework%2F" title="SREは大規模なリプレイスプロジェクトで発生した様々な問題にどう取り組んだか【Backlog Play 化プロジェクト】 | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/how-sre-resolved-the-problems-on-large-scale-replacement-with-play-framework/">backlog.com</a></cite></p> <p>考えが変わったもう一つの理由は、<a href="https://sre-lounge.connpass.com/">SRE Lounge</a> などの勉強会で、いろいろな他社事例に触れたことです。特にメルカリの Microservices Platform Team の事例では、開発チームへの監視・運用の移行がここまで現実に可能なのかと驚かされました。例えば、いろいろな勉強会で触れられている microservices-starter-kit について以下のイベントで初めて知り、懇親会でメルカリのエンジニアに詳しい話を聞いて感銘を受けました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F05%2F27%2F231106" title="Mercari Meetup for Microservices Platform #2 参加レポート - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/05/27/231106">muziyoshiz.hatenablog.com</a></cite></p> <p>それまでは、マイクロサービスは自分の現場に合うのかどうかがずっと疑問でしたが、「SRE とアプリ開発者の責任分界点を明確にするため」という目的さえブレなければ、マイクロサービス化を推し進めていいのではないかと考え始めました。</p> <p>メルカリの事例に強く影響を受けて、その後、自分の現場でも、アプリ開発者に監視業務を移行するためのアラート通知システムを整備しました。マイクロサービス化まではまだ進んでいませんが、責任分界点を明確にするためには、これからマイクロサービス化を段階的に進めていく必要があると思っています。</p> <p><figure class="figure-image figure-image-fotolife" title="開発チームを巻き込んだ監視システムの全体像(下記ブログから引用)"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191230/20191230210434.png" alt="f:id:muziyoshiz:20191230210434p:plain:w600" title="f:id:muziyoshiz:20191230210434p:plain:w600" class="hatena-fotolife" style="width:600px" itemprop="image"></span><figcaption>開発チームを巻き込んだ監視システムの全体像(下記ブログから引用)</figcaption></figure></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fbacklog.com%2Fja%2Fblog%2Fon-call-system-for-backlog-developers%2F" title="Backlog開発チーム自身によるオンコール対応を支えるアラート通知システム | Backlogブログ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://backlog.com/ja/blog/on-call-system-for-backlog-developers/">backlog.com</a></cite></p> <p>ちなみに、開発チームに1年以上いたおかげで、アプリ監視の業務設計ができて、結果的にこのアラート通知システムも作れました。その点は、1年以上悪戦苦闘したのも無駄な努力ではなかったのかな、と。</p> <h2>来年1発目のイベントは SRE NEXT</h2> <p>上記でメルカリの事例について軽く触れましたが、SRE の業務について考えるにあたって、他社の事例を聞くのはとても参考になると実感した1年でもありました。</p> <p>僕は去年から <a href="https://sre-lounge.connpass.com/">SRE Lounge</a> というコミュニティのスタッフとして参加しているのですが、同じコミュニティ主催の大規模イベント <a href="https://sre-next.dev/">SRE NEXT</a> がとうとう来年1/25(土)に開催されます。いまのところ、僕は Room A の司会としてスタッフ参加している予定です。</p> <p>すでにチケットは売り切れてしまっています(すみません!)が、発表スライドは後ほどいろいろな登壇者が公開してくれると思います。僕もイベント当日は見てる余裕がなさそうなので、あとから発表スライドやレポートブログなどをゆっくり読ませてもらうつもりです。</p> <p>来年末も、今とはまたいろいろ考えが変わってるのかなあ。どうなんだろう……。</p> muziyoshiz Amazon Elasticsearch Service の認証・認可に関する面倒くさい仕様をなるべくわかりやすく説明する hatenablog://entry/26006613473735640 2019-11-30T14:42:13+09:00 2022-01-13T16:22:22+09:00 はじめに 最近、仕事で Amazon Elasticsearch Service(以下、Amazon ES)を本格的に使う機会があって、認証周りの仕様で苦労させられました。 Elasticsearch を本格的に使う人は、自分で Elasticsearch クラスタを立てたり、Elastic Cloud を使ったりしてしまうからか、Amazon ES 周りの情報は意外と見つかりませんでした。せっかくなので、今回の記事では、自分が Amazon ES を使うにあたって調べた情報をまとめてみます。 はじめに いろいろな Elasticsearch Amazon ES の基本 Amazon ES が… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191130/20191130143741.png" alt="f:id:muziyoshiz:20191130143741p:plain" width="300" height="300" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span></div> <h2 id="はじめに">はじめに</h2> <p>最近、仕事で Amazon Elasticsearch Service(以下、Amazon ES)を本格的に使う機会があって、認証周りの仕様で苦労させられました。</p> <p>Elasticsearch を本格的に使う人は、自分で Elasticsearch クラスタを立てたり、Elastic Cloud を使ったりしてしまうからか、Amazon ES 周りの情報は意外と見つかりませんでした。せっかくなので、今回の記事では、自分が Amazon ES を使うにあたって調べた情報をまとめてみます。</p> <ul class="table-of-contents"> <li><a href="#はじめに">はじめに</a></li> <li><a href="#いろいろな-Elasticsearch">いろいろな Elasticsearch</a></li> <li><a href="#Amazon-ES-の基本">Amazon ES の基本</a></li> <li><a href="#Amazon-ES-が提供する認証認可">Amazon ES が提供する認証・認可</a><ul> <li><a href="#パブリックアクセスの場合">パブリックアクセスの場合</a></li> <li><a href="#VPC-アクセスの場合">VPC アクセスの場合</a></li> <li><a href="#IP-アドレス以外の認証認可方法は-AWS-署名しかない">IP アドレス以外の認証・認可方法は AWS 署名しかない</a></li> </ul> </li> <li><a href="#Elasticsearch-API-へのリクエストを-AWS-署名する">Elasticsearch API へのリクエストを AWS 署名する</a><ul> <li><a href="#プログラムから-Elasticsearch-API-を呼ぶ">プログラムから Elasticsearch API を呼ぶ</a></li> <li><a href="#コマンドラインから-Elasticsearch-API-を呼ぶ">コマンドラインから Elasticsearch API を呼ぶ</a></li> <li><a href="#実際に使う人向けawscurl-に関するもうちょっと詳しい話">実際に使う人向け:awscurl に関するもうちょっと詳しい話</a></li> <li><a href="#2020-11-29追記">2020-11-29追記</a></li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> <li><a href="#更新履歴">更新履歴</a></li> </ul> <h2 id="いろいろな-Elasticsearch">いろいろな Elasticsearch</h2> <p>Amazon ES は、オープンソースの全文検索エンジン Elasticsearch をベースにしたマネージド型サービスです。</p> <p>Elasticsearch は、Elasticsearch 社<a href="#f-ac45f21c" name="fn-ac45f21c" title="昔は Elastic Co. だったと思うのですが、いまは Elasticsearch B.V. になっている?">*1</a>が主に開発しているオープンソースソフトウェア(OSS)です。しかし、いまはその派生が色々出てきてしまっているので、この記事では以下のように呼び分けます。</p> <table> <thead> <tr> <th> 提供形態 </th> <th> 名称 </th> <th> 概要 </th> <th> この記事での呼称 </th> </tr> </thead> <tbody> <tr> <td> OSS </td> <td> Elasticsearch </td> <td> Elasticsearch 社が主に開発している OSS。<a href="https://www.elastic.co/guide/jp/x-pack/current/xpack-introduction.html">X-Pack</a> と呼ばれる拡張機能があり、その大半は有償オプションで利用できる。 </td> <td> OSS 版 </td> </tr> <tr> <td> マネージドサービス </td> <td> Elasticsearch Service </td> <td> Elasticsearch 社が提供する Elastic Cloud と呼ばれるサービス群の一つ。AWS, GCP, Azure にデプロイされるマネージドサービス。X-Pack の機能を含む。AWS 等に固有の機能はない。 </td> <td> Elastic Cloud </td> </tr> <tr> <td> マネージドサービス </td> <td> Amazon Elasticsearch Service </td> <td> AWS が提供する Elasticsearch のマネージドサービス。AWS のサービス群と統合するために、各種拡張が行われている。X-Pack の機能は含まないが、同等の機能が一部実装されている。 </td> <td> Amazon ES </td> </tr> <tr> <td> OSS </td> <td> Open Distro for Elasticsearch </td> <td> 「Elasticsearch へのタダ乗り」との批判を受けて、Amazon ES のソースコードの一部を OSS として公開したもの。Amazon ES と同一ではない、と宣言されている。この記事では触れない。 </td> <td> - </td> </tr> </tbody> </table> <p>なぜこんな話が必要かというと、Amazon ES と、Elasticsearch 社が提供する OSS 版および Elastic Cloud では、大きく違っている機能が多いからです。この記事で解説する認証・認可の方法も、そのような機能の一つです。</p> <h2 id="Amazon-ES-の基本">Amazon ES の基本</h2> <p>Amazon ES では、「ドメイン」という概念が新たに導入されています。このドメインと Elasticsearch のクラスタは1対1対応です。なので、Elasticsearch をすでに知ってる人は、Amazon ES のドキュメントでドメインという単語が出てきたら、クラスタと読み替えてもらえればとりあえず OK です(参考:<a href="https://aws.amazon.com/jp/elasticsearch-service/faqs/">よくある質問 - Amazon Elasticsearch Service</a>の「Q: Amazon Elasticsearch Service ドメインとは何ですか?」)。</p> <p>Amazon ES のドメインを作る際には、パブリックネットワークに設置するか、VPC に設置するかを選ぶ必要があります。それぞれ「パブリックアクセス」、「VPC アクセス」と呼ばれます。</p> <ul> <li>パブリックアクセス <ul> <li>グローバル IP アドレスを持ち、インターネットから直接アクセス可能なドメインを構築</li> <li>構築後にパブリックアクセスから VPC アクセスに変更することはできない(逆もできない)</li> </ul> </li> <li>VPC アクセス <ul> <li>グローバル IP アドレスを持たず、VPC に設置されて、インターネットから直接アクセス不可なドメインを構築</li> <li>構築時に選んだ VPC とは別の VPC に移すことはできない</li> <li>ドメインの作成時にパブリックサブネットを選択しても、エンドポイントにグローバル IP アドレスを設定することはできない</li> </ul> </li> </ul> <p>VPC アクセスには、グローバル IP アドレスの有無以外に、機能面でも少し違いがあります。詳しくは <a href="https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-vpc.html">Amazon Elasticsearch Service ドメインの VPC サポート</a> の「制約事項」の項をご覧ください。</p> <p>で、ここからお話するのは、この「制約事項」の項は書かれておらず、その次の「VPC ドメインのアクセスポリシーについて」の項でわずかに触れられている(しかし結構重要な)認証・認可についての制約事項の話です。</p> <blockquote><p>注記</p> <p>セキュリティグループには IP ベースのアクセス権限ポリシーですでに強化されているため、VPC 内に存在する Amazon ES ドメインに IP ベースのアクセス権限ポリシーを適用することはできません。パブリックエンドポイントを使用する場合、IP ベースのポリシーを引き続き利用できます。</p></blockquote> <h2 id="Amazon-ES-が提供する認証認可">Amazon ES が提供する認証・認可</h2> <p>Amazon ES では、ドメインに対して、セキュリティポリシーとセキュリティグループを設定できます。セキュリティグループは、VPC アクセスの場合のみ設定できます。</p> <p>さらに、ドメインに対するセキュリティポリシーには、以下の3種類を利用できます。公式ドキュメントでは <a href="https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-ac.html">Amazon Elasticsearch Service の Identity and Access Management</a> に詳しく書かれています。</p> <ul> <li>リソースベースのポリシー <ul> <li>リクエストの送信先 URL(特定インデックスの URL も指定可能)</li> </ul> </li> <li>アイデンティティベースのポリシー <ul> <li>リクエストの送信元 IAM ユーザーまたは IAM ロール</li> </ul> </li> <li>IP ベースのポリシー <ul> <li>リクエストの送信元 IP アドレス</li> </ul> </li> </ul> <p>そして、さっき上で引用したように、VPC アクセスの場合は IP ベースのポリシーは使えません。</p> <p>この関係を図に表すと、以下のようになります。</p> <p><figure class="figure-image figure-image-fotolife" title="Amazon ES の認証・認可"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191130/20191130141129.png" alt="f:id:muziyoshiz:20191130141129p:plain" width="820" height="340" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>Amazon ES の認証・認可</figcaption></figure></p> <p>これを見て「なるほど、じゃあパブリックアクセスと VPC アクセスの認証・認可機能は同等なんですね。よかったよかった」と思われましたよね。僕も最初そう思いました。でもそうじゃない、そうじゃないんですよ……。</p> <h3 id="パブリックアクセスの場合">パブリックアクセスの場合</h3> <p>リソースベース、アイデンティティベース、IP ベースのポリシーは組み合わせて使えます。また、複数のステートメントを並べて書くこともできます。</p> <p>例えば、「すべてのユーザに test-index の読み込みを許す」かつ「IAM ロール "power-user-role" を持ち、送信元 IP アドレスが 192.0.2.0/24 のユーザに対してのみ、すべての操作を許す」というセキュリティポリシーは、以下のように書けます。</p> <pre class="code" data-lang="" data-unlink>{ &#34;Version&#34;: &#34;2012-10-17&#34;, &#34;Statement&#34;: [ { &#34;Effect&#34;: &#34;Allow&#34;, &#34;Principal&#34;: { &#34;AWS&#34;: &#34;*&#34; }, &#34;Action&#34;: [ &#34;es:ESHttpGet&#34; ], &#34;Resource&#34;: &#34;arn:aws:es:us-west-1:987654321098:domain/test-domain/test-index/*&#34; }, { &#34;Effect&#34;: &#34;Allow&#34;, &#34;Principal&#34;: { &#34;AWS&#34;: &#34;arn:aws:iam::123456789012:role/power-user-role&#34; }, &#34;Action&#34;: [ &#34;es:*&#34; ], &#34;Condition&#34;: { &#34;IpAddress&#34;: { &#34;aws:SourceIp&#34;: [ &#34;192.0.2.0/24&#34; ] } }, &#34;Resource&#34;: &#34;arn:aws:es:us-west-1:987654321098:domain/test-domain/*&#34; } ] }</pre> <p>この関係を図に表すとこうなります。</p> <p><figure class="figure-image figure-image-fotolife" title="パブリックアクセスの場合"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191130/20191130143201.png" alt="f:id:muziyoshiz:20191130143201p:plain" width="710" height="350" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>パブリックアクセスの場合</figcaption></figure></p> <h3 id="VPC-アクセスの場合">VPC アクセスの場合</h3> <p>リソースベース、アイデンティティベースのポリシーは組み合わせて使えますが、IP ベースのポリシーは使えます。また、<strong>それとは独立に</strong> セキュリティグループも設定することができます。つまり図にするとこうなります。</p> <p><figure class="figure-image figure-image-fotolife" title="VPC アクセスの場合"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191130/20191130143330.png" alt="f:id:muziyoshiz:20191130143330p:plain" width="820" height="350" loading="lazy" title="" class="hatena-fotolife" itemprop="image"></span><figcaption>VPC アクセスの場合</figcaption></figure></p> <p>どうですか?</p> <p>セキュリティポリシーとセキュリティグループは独立なので、例えばこの図でいうと「ステートメント1 AND セキュリティグループ1」という横の繋がりは強制できません。つまり、さっきパブリックアクセスの例に挙げた、以下のようなアクセス制御はできません。</p> <blockquote><p>「すべてのユーザに test-index の読み込みを許す」かつ「IAM ロール "power-user-role" を持ち、送信元 IP アドレスが 192.0.2.0/24 のユーザに対してのみ、すべての操作を許す」</p></blockquote> <h3 id="IP-アドレス以外の認証認可方法は-AWS-署名しかない">IP アドレス以外の認証・認可方法は AWS 署名しかない</h3> <p>Oh... じゃあ仕方ない、VPC アクセスを使う場合は IP アドレスでユーザを識別して認可するのは諦めよう!と考えたとします。すると次に出てくるのは AWS 署名の問題です。</p> <p>Amazon ES は、IP アドレス以外の認証・認可方法として、AWS 署名のみを許可しています。<strong>OSS 版や Elastic Cloud は Basic 認証に対応していますが、Amazon ES は対応してません。</strong> Basic 認証は X-Pack の機能ですが、いまや OSS 版でも使えるというのに!(<a href="https://www.elastic.co/jp/blog/security-for-elasticsearch-is-now-free">Security for Elasticsearch is now free | Elastic Blog</a>)</p> <p>認証方法を強制的に IAM に統一できる、というのはもちろん強いメリットと言うこともできます。認証情報は集中管理できたほうがいいですよね。しかし、自分は実際に使ってみて、3つの問題を感じました。</p> <p>まず1つ目は、<strong>Elasticsearch の REST API(以下、Elasticsearch API)の呼び出しも AWS 署名する必要が生じる</strong> ことです。</p> <p>こう言うと、詳しい方は「aws コマンドには es サブコマンドがあるじゃないか」と言うかもしれません。確かに、Amazon ES のドメインを操作するための、AWS が提供する API の呼び出しは、aws コマンドで実行できます。だから、AWS 署名を意識する必要はありません。</p> <p>しかし、Elasticsearch API は aws コマンドの範囲外です。もちろんライブラリを使えばそういうコードは書けますが、運用中は <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/rest-apis.html">REST APIs</a> を色々駆使したくなります。各 API に対応するコードを書くのかと言われるとちょっと……。</p> <p>2つ目は、<strong>IAM ユーザや IAM ロールの設定範囲が、Elasticsearch に対して与えたい権限と必ずしも一致しない場合がある</strong> ことです。</p> <p>例えば、既存の EC2 インスタンスに、Amazon ES へのアクセスを新たに追加したい場合に、「インスタンス1にはインデックスAへのアクセスを許可し、インスタンス2にはインデックスBへのアクセスを許可したい」と思ったとします。その場合、IAM ロールの付け替えが必要になります。既存の IAM ロールの ARN をあちこちから参照していたりしたら、付け替えは地獄の作業になります。</p> <p>そして3つ目は、AWS 署名を必須にすると <strong>Kibana を使うために Cognito が必須になる</strong> という問題です。</p> <p>Amazon ES では Elasticsearch API と Kibana のエンドポイントの FQDN は同じです。リソースベースのポリシーはリクエストの送信先 URL なので、当然 Kibana にも影響します。しかし Web ブラウザは(当たり前ですが)HTTP リクエストに AWS 署名を付ける機能なんて持ってません。</p> <p>じゃあどうしたらいいの?というと、AWS は「Amazon Cognito を使用して Kibana のユーザー名とパスワードを管理する機能」をオプションとして提供しています。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.aws.amazon.com%2Fja_jp%2Felasticsearch-service%2Flatest%2Fdeveloperguide%2Fes-cognito-auth.html" title="Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-cognito-auth.html">docs.aws.amazon.com</a></cite></p> <p>Kibana へのアクセスを認証するためだけに、Cognito のユーザープールやら ID プールやらの設定をしなきゃいけないんですか?? ちょっと、やりたいことに対して Cognito の機能は過剰すぎませんかね……。</p> <h2 id="Elasticsearch-API-へのリクエストを-AWS-署名する">Elasticsearch API へのリクエストを AWS 署名する</h2> <p>そろそろ「そこまでして Amazon ES 使うの? Elastic Cloud で良くない?」という声が脳内に直接聞こえてきたのではないでしょうか。とはいえ、AWS ですぐ使えるのはやっぱり便利なので Amazon ES で我慢しよう、という判断をしたとします。</p> <p>色々調べた結果、AWS 署名についてはこうするのが良いだろう、という自分なりの答えは出たので以下にてご紹介します。もっといい方法があったらぜひ教えてください。</p> <h3 id="プログラムから-Elasticsearch-API-を呼ぶ">プログラムから Elasticsearch API を呼ぶ</h3> <p>プログラムから Elasticsearch API を呼ぶなら、各種ライブラリが AWS クレデンシャルの取得に対応しているので、それを使うのが一番楽です。</p> <p>EC2 インスタンスや Lambda 関数でプログラムを動かすなら、IAM ロールに対してアクセス権限を与えれば、ほとんど何も意識せずにコーディングできます。以下のページに公式のサンプルコードがあります。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.aws.amazon.com%2Fja_jp%2Felasticsearch-service%2Flatest%2Fdeveloperguide%2Fes-request-signing.html" title="Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-request-signing.html">docs.aws.amazon.com</a></cite></p> <p>より使いやすいライブラリもあります。例えば、Scala 用には elastic4s があります。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fsksamuel%2Felastic4s" title="GitHub - sksamuel/elastic4s: Elasticsearch Scala Client - Reactive, Non Blocking, Type Safe, HTTP Client" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/sksamuel/elastic4s">github.com</a></cite></p> <p>Python でのやり方についてはこちらで詳しく説明されていました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdev.classmethod.jp%2Fcloud%2Faws%2Fpython-v4-signature-without-boto3%2F" title="[Python] Boto3以外でV4署名リクエストを行う | DevelopersIO" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://dev.classmethod.jp/cloud/aws/python-v4-signature-without-boto3/">dev.classmethod.jp</a></cite></p> <p>IAM ロールの設定範囲が Elasticsearch に対して与えたい権限と一致しない場合は、何の権限もない IAM ユーザを Amazon ES 専用に作るのが良いと思います。</p> <h3 id="コマンドラインから-Elasticsearch-API-を呼ぶ">コマンドラインから Elasticsearch API を呼ぶ</h3> <p>Elasticsearch を運用する際には、コマンドラインから curl を使って、<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/rest-apis.html">REST APIs</a> にある APIs を呼び出したいです。Amazon ES の管理コンソールは Elastic Cloud のものほどリッチではないので尚更です。しかし、curl には AWS 署名機能はありません。</p> <p>そこで代替手段を色々探したところ、<a href="https://github.com/okigan/awscurl">awscurl</a> が、Elasticsearch APIs の利用に必要な機能をすべて備えていました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fokigan%2Fawscurl" title="GitHub - okigan/awscurl: curl-like access to AWS resources with AWS Signature Version 4 request signing." class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/okigan/awscurl">github.com</a></cite></p> <p>ただし、awscurl の v0.17 までは日本語を含むリクエストの送受信に対応していませんでした。プルリクを送って対応してもらったので、v0.19 以降であれば大丈夫です<a href="#f-90a7525c" name="fn-90a7525c" title="v0.18 は? v0.18 は僕のプルリクに別のバグが含まれていて、v0.19 で bugfix リリースしてもらってました。申し訳ない……。">*2</a>。</p> <h3 id="実際に使う人向けawscurl-に関するもうちょっと詳しい話">実際に使う人向け:awscurl に関するもうちょっと詳しい話</h3> <p>awscurl は便利なのですが、<a href="https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html">一時的セキュリティ認証情報</a> をサポートしていませんでした。だから、例えば Amazon ES 管理用の EC2 インスタンスを立てて、そこでコマンド実行したい、という場合には不便です。</p> <p>もう少し詳しく話すと、AWS CLI の動作については <a href="https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-chap-configure.html#config-settings-and-precedence">AWS CLI の設定</a> の「構成設定と優先順位」に記載があります。このなかの「6. インスタンスプロファイル認証情報」のサポートに当たるものが awscurl にはありませんでした。</p> <p>そこで、僕は管理用サーバの <code>/usr/local/bin/awscurl-on-ec2</code> に、awscurl をラップするシェルスクリプトを置きました。</p> <pre class="code" data-lang="" data-unlink>#!/bin/env bash ROLE_NAME=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/` CRED=`curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/${ROLE_NAME}` AWS_ACCESS_KEY_ID=`echo $CRED | jq -r &#34;.AccessKeyId&#34;` AWS_SECRET_ACCESS_KEY=`echo $CRED | jq -r &#34;.SecretAccessKey&#34;` AWS_SESSION_TOKEN=`echo $CRED | jq -r &#34;.Token&#34;` awscurl &#34;$@&#34;</pre> <p>また、<code>awscurl-on-ec2</code> コマンドの実行時に Endpoint URL をいちいち調べるのは面倒なので、作業用サーバの環境変数に設定しました。</p> <p>awscurl と curl を比べて、使いやすい点・使いづらい点は次のような感じです。</p> <ul> <li>curl より使いやすい点 <ul> <li>ボディに json を含めるために <code>-H 'Content-Type: application/json'</code> を指定する必要がない</li> <li>邪魔な表示を消すために <code>-s</code> を指定する必要がない</li> </ul> </li> <li>curl より使いづらい点 <ul> <li>AWS 署名を取得するサービスを特定するために、常に <code>--service es</code> を指定する必要がある <ul> <li><code>awscurl-on-ec2</code> のようなラッパーのなかで、デフォルトで <code>--service es</code> を付けてもいいと思います</li> </ul> </li> <li>AWS 署名を取得するリージョンを特定するために、常に <code>--region リージョン名</code> を指定する必要がある <ul> <li>こちらも、使うリージョンが固定なら、ラッパーに含めてもいいと思います</li> </ul> </li> <li>ステータスコードを取得したいときに <code>-w '%{http_code}'</code> が使えない</li> <li>2xx 以外のときは例外がスローされる(インデックスの存在確認をするときなど、4xx が返されるのが正常な場合もある)</li> </ul> </li> </ul> <h3 id="2020-11-29追記">2020-11-29追記</h3> <p>pipx を使った awscurl のインストール方法をまとめました。こちらもご参考ください。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2020%2F11%2F29%2F181354" title="Amazon Linux 2 に awscurl を安全にインストールする簡単な方法 - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2020/11/29/181354">muziyoshiz.hatenablog.com</a></cite></p> <h2 id="まとめ">まとめ</h2> <p>今回は Amazon Elasticsearch Service(Amazon ES)を実際に使ってみて、認証・認可周りで困ったことと、どうやって無理やり使い続けているかを紹介しました。長々と書きましたが、まとめるとこんな感じです。</p> <ul> <li>Amazon ES にはパブリックアクセスと VPC アクセスがある</li> <li>パブリックアクセスと VPC アクセスでは IP アドレス認証の動作に違いがあり、VPC アクセスのほうが不便</li> <li>Basic 認証は使えなくて、AWS 署名を使う必要がある</li> <li>AWS 署名と Kibana を両方使いたいなら Cognito を強制される</li> <li>AWS 署名ありで運用する場合は awscurl が便利</li> </ul> <p>僕と同じく、Amazon ES を使う決心をした人は頑張りましょう! そしてもっといい方法があったら誰か教えてください!(切実)</p> <h2 id="更新履歴">更新履歴</h2> <ul> <li>2019-12-03:awscurl のバージョンアップに伴って、日本語対応に関する記載を修正しました。</li> </ul> <div class="footnote"> <p class="footnote"><a href="#fn-ac45f21c" name="f-ac45f21c" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">昔は Elastic Co. だったと思うのですが、いまは Elasticsearch B.V. になっている?</span></p> <p class="footnote"><a href="#fn-90a7525c" name="f-90a7525c" class="footnote-number">*2</a><span class="footnote-delimiter">:</span><span class="footnote-text">v0.18 は? v0.18 は僕のプルリクに別のバグが含まれていて、v0.19 で bugfix リリースしてもらってました。申し訳ない……。</span></p> </div> muziyoshiz 「サテライトロッキー」の新バージョン「Satellite V2.0」が B-PUMP などのジムにも多数対応し、ムービーの共有機能も追加! hatenablog://entry/26006613455808169 2019-10-27T10:05:21+09:00 2019-10-27T10:20:25+09:00 「サテライトロッキー」改め「Satellite V2.0」とは? 去年の10月10日に、「Rocky」というボルダリングジムが、「サテライトロッキー」というアプリを初めてリリースしました。 「サテライトロッキー」は、それまでに他のジムが提供していたアプリ(会員証程度のもの)とは一線を画していて、当時あまりにも感動してブログ記事を書いたりしました。 muziyoshiz.hatenablog.com あれから約1年経った今月の10月23日、このサテライトロッキーが大幅にリニューアルされて、名前も「Satellite V2.0」に変わりました! 【BIG NEWS】ついに。明日10/23(水)早朝… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><a href="http://f.hatena.ne.jp/muziyoshiz/20191026212556" class="hatena-fotolife" itemprop="url"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026212556.jpg" alt="f:id:muziyoshiz:20191026212556j:image:w800" title="f:id:muziyoshiz:20191026212556j:image:w800" class="hatena-fotolife" style="width:800px" itemprop="image"></a></span></div> <h2>「サテライトロッキー」改め「Satellite V2.0」とは?</h2> <p>去年の10月10日に、<a href="https://www.rockyclimbing.com/">「Rocky」</a>というボルダリングジムが、「サテライトロッキー」というアプリを初めてリリースしました。</p> <p>「サテライトロッキー」は、それまでに他のジムが提供していたアプリ(会員証程度のもの)とは一線を画していて、当時あまりにも感動してブログ記事を書いたりしました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F10%2F27%2F221753" title="ボルダリングジム Rocky がリリースした新アプリ「サテライトロッキー」がすごい! - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/10/27/221753">muziyoshiz.hatenablog.com</a></cite></p> <p>あれから約1年経った今月の10月23日、このサテライトロッキーが大幅にリニューアルされて、名前も「Satellite V2.0」に変わりました!</p> <p><blockquote class="twitter-tweet" data-lang="HASH(0x562da3429978)"><p lang="ja" dir="ltr">【BIG NEWS】<br><br>ついに。明日10/23(水)早朝。<br>Satellite V2.0がリリースされます。<br><br>インストールは以下URLより<br>※リリース前はサテロキになっています。<br><br>app store: <a href="https://t.co/W44l73qiqc">https://t.co/W44l73qiqc</a><br><br>Android: <a href="https://t.co/VpflqscpSP">https://t.co/VpflqscpSP</a> <a href="https://t.co/HzRs0jJPGJ">pic.twitter.com/HzRs0jJPGJ</a></p>&mdash; Satellite App &amp; Holds (@Satelliteclimb) <a href="https://twitter.com/Satelliteclimb/status/1186565591189950464?ref_src=twsrc%5Etfw">October 22, 2019</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> <p>このアプリも期待を上回る素晴らしさだったので、今回改めて紹介記事を書いてみたいと思います。</p> <p>(「サテライトロッキー」でググると以前のブログ記事が結構上位に出てしまうので、そのアップデートという気持ちもあり……)</p> <h2>そもそもボルダリングって何?</h2> <p><a href="https://muziyoshiz.hatenablog.com/entry/2018/10/27/221753">以前のブログ記事</a>の冒頭で、「ボルダリングって何?」って方向けにボルダリングの軽い解説も書いてます。もし興味あればこちらをどうぞ。</p> <p>最近だと<a href="https://www.amazon.co.jp/exec/obidos/ASIN/B07YLNPN25/muziyoshiz-22/">「フリクションガール」</a>というボルダリング漫画があって、こちらもおすすめです。ガチのクライマーの方が書いていて、品川ロッキーも取材協力してます(出てくるジムが思いっきり品ロキ)。このジムは初心者向け課題も多くておすすめですよ。</p> <p><a href="https://www.amazon.co.jp/exec/obidos/ASIN/B07YLNPN25/muziyoshiz-22/"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191027/20191027101203.jpg" alt="f:id:muziyoshiz:20191027101203j:image:w200" title="f:id:muziyoshiz:20191027101203j:image:w200" class="hatena-fotolife" style="width:200px" itemprop="image"></a></p> <h2>サテライトロッキーから引き継がれた基本機能</h2> <p>Satellite V2.0 の話に戻ります。</p> <p>僕が思うサテライトロッキーの基本機能は以下の3つなんですが、Satellite V2.0 もこれらの機能をすべて持っています(詳しくは<a href="https://muziyoshiz.hatenablog.com/entry/2018/10/27/221753">以前のブログ記事</a>を)。</p> <ul> <li>機能1. 完登した課題を記録して、あとから写真込みで確認できる</li> <li>機能2. 全来店者でのランキングを確認できる</li> <li>機能3. 他のクライマーをフレンド登録して、フレンドのチャレンジ結果も確認できる</li> </ul> <p><figure class="figure-image figure-image-fotolife" title="サテライトロッキーから引き継がれた基本機能"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026224732.png" alt="f:id:muziyoshiz:20191026224732p:plain" title="f:id:muziyoshiz:20191026224732p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Satellite V2.0 の基本機能</figcaption></figure></p> <p>また、ブログ記事を書いたあとのアップデートで、以下の機能もサテライトロッキーに追加されていました。これらも Satellite V2.0 に引き継がれています。</p> <ul> <li>来店回数や月間ランキングに応じたポイント付与機能</li> <li>会員証機能(会員番号のバーコード表示)</li> <li>YTM(有酸素トレーニングモード) … 指定した級の課題がランダムに10個選ばれ、それを1時間以内に完登することを目指すモード</li> </ul> <h2>Satellite V2.0 での新機能</h2> <h3>新機能1. ロッキー以外のボルダリングジム、クライミングジムにも対応!</h3> <p>リリース時点で、荻窪 B-PUMP、横浜 B-PUMP、Base Camp 全店舗といった有名ジムに対応していました。また、リリース後も続々と対応店舗を増やしているようです。</p> <p><figure class="figure-image figure-image-fotolife" title="全国の Satellite 対応ジム"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026225029.png" alt="f:id:muziyoshiz:20191026225029p:plain" title="f:id:muziyoshiz:20191026225029p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>全国の Satellite 対応ジム</figcaption></figure></p> <p>しかも、今回からはリードにも対応! 例えば Base Camp 入間店を見るとリードの課題も表示されるようになっています。</p> <p><figure class="figure-image figure-image-fotolife" title="Base Camp 入間店のリード課題"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026225343.png" alt="f:id:muziyoshiz:20191026225343p:plain" title="f:id:muziyoshiz:20191026225343p:plain" class="hatena-fotolife" itemprop="image"></span> <span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026225423.png" alt="f:id:muziyoshiz:20191026225423p:plain" title="f:id:muziyoshiz:20191026225423p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>Base Camp 入間店のリード課題</figcaption></figure></p> <p><a href="https://www.satelliteapp.jp/jp/">Satellite の公式サイト</a> を見ると、<strong>月額 7,980 円/1店舗</strong> という低価格でジムの囲い込みを進めているようです。課題の写真をアップロードする工数がネックになりそうですが、そこも店舗向けマニュアルで PicsArt を使った方法を丁寧に解説してて手厚さを感じました(なぜか店舗向けマニュアルにまで目を通してる人)。</p> <h3>新機能2. ムービーリンク機能で、完登した課題の Instagram 動画などを共有できる!</h3> <p>これは前からずっと欲しくて、1年前のサテライトロッキーの紹介ブログにも書いていた機能!</p> <p>自分が完登した課題の一覧から、「動画を追加する」リンクをクリックすると、Twitter や Instagram のリンクを追加できます。嬉しくて、Instagram にアップロードした過去1年分の動画を一気に登録しちゃいました。</p> <p><figure class="figure-image figure-image-fotolife" title="ムービーリンクの追加"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026230257.png" alt="f:id:muziyoshiz:20191026230257p:plain" title="f:id:muziyoshiz:20191026230257p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>ムービーリンクの追加</figcaption></figure></p> <p>登録したムービーは、各ユーザーのプロフィール画面の「ムービー」から確認できます。</p> <p><figure class="figure-image figure-image-fotolife" title="過去に登録したムービーの一覧"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026230451.png" alt="f:id:muziyoshiz:20191026230451p:plain" title="f:id:muziyoshiz:20191026230451p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>過去に登録したムービーの一覧</figcaption></figure></p> <p>また、「この課題をクリアした人の動画を参考にしたい!」といったときに、課題を完登したユーザーの一覧から「ムービーリンク付きユーザー」を探せるようになりました。</p> <p><figure class="figure-image figure-image-fotolife" title="課題のページに表示されるムービーリンク付きユーザー"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026230622.png" alt="f:id:muziyoshiz:20191026230622p:plain" title="f:id:muziyoshiz:20191026230622p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>課題のページに表示されるムービーリンク付きユーザー</figcaption></figure></p> <p>これまでは、完登動画を探したかったら Instagram で店舗のタグ(#宿ロキ とか)で検索したうえで、目当ての課題をクリアしてる動画を目視で探すしかなくて、なかなかつらみがありました。それと比べると、この Satellite の機能は断然便利です!</p> <h3>その他の細かな改善</h3> <p>その他の機能としては、バッジ機能も追加されました。</p> <p>これはざっくりいうと「○級の課題を△△個以上完登!」とか「○級の課題をすべて完登!」などの条件でバッジをもらえるという機能です。(一定期間で課題は入れ替わってしまうから)特定の級をすべて完登しようとすると意外と苦戦するので、これは新たな目標になりそうです。僕はまだロッキー新宿曙橋店の3級全完登できてないので、それを目指してがんばります……。</p> <p>他の細かな UI 改善としては、会員証の表示画面で、画面の明るさが自動的に強くなるようになりました。いままでは、バーコードリーダーでの読み込みが悪いときに、手動で明るさを変える必要があって手間でした。これは細かい点ですが嬉しい改善です。</p> <p><figure class="figure-image figure-image-fotolife" title="過去に取得したバッジの一覧"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026230754.png" alt="f:id:muziyoshiz:20191026230754p:plain" title="f:id:muziyoshiz:20191026230754p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>過去に取得したバッジの一覧</figcaption></figure></p> <h2>今後のアップデートで予定されている機能</h2> <p><a href="https://www.satelliteapp.jp/jp/">Satellite の公式サイト</a> にて、Rocky の General Manager 竹内俊明さんが今後のアップデートに関してコメントされてます。</p> <blockquote><p>すでに物凄い多機能なアプリですが、次の大きなアップデートである「バトルモード」「トレーニングログ」ではクライミングジム界に革命をもたらす機能の提供を予定しております。</p></blockquote> <p>どういう機能なんでしょう……?</p> <p>勝手に予想すると、「バトルモード」は大勢でコンペみたいに、一定時間で何課題クリアできるか競うようなモードでしょうか? 「トレーニングログ」はトレーニングボードなどを使った筋トレ回数を記録する機能とか? アップデートが今から楽しみです。</p> <h2>ちょっと不満なところ</h2> <p>色々紹介しましたが、最後にちょっと不満なところをいくつか。とはいえ UI に関する細かいところだけなので、今後のアップデートで直ってほしいなと……。</p> <h3>ムービーリンク機能の動線がまだ少しおかしい</h3> <p>新しく追加されたムービーリンク機能で、動線がまだ少しおかしいところがあります。</p> <p>まず、ムービーリンクの追加場所が少し分かりづらいです。課題を完登したら「店舗」→「セット」→「級」と表示して、課題の左にある ○ をクリックして完登済みのチェックをつけることができます。ただ、この画面からムービーリンクを追加することはできなくて、一旦自分のプロフィールに戻って、「完登した課題の一覧」からその課題を探し直す必要があります。これが最初なかなか見つけられませんでした。</p> <p>あと、他のユーザーのムービーが見たいときに、「ムービーリンク付きユーザー」から探せるよ、という話をしましたが、なぜかこの画面から直接ムービーのページに移動できません。</p> <p><figure class="figure-image figure-image-fotolife" title="なぜかムービーに直接飛べない"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026231752.png" alt="f:id:muziyoshiz:20191026231752p:plain" title="f:id:muziyoshiz:20191026231752p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>なぜかムービーに直接飛べない</figcaption></figure></p> <p>そのため、一旦その人のプロフィールを表示してから、「ムービー」を選んで、見たい課題を改めて探す必要があります。これは本当にどうにかならないでしょうか……。</p> <h3>タップできる箇所が分かりづらい</h3> <p>サテライトロッキーのときは白背景だったものが、Satellite V2.0になったタイミングで黒背景になったことが原因かもしれませんが、タップできる箇所が分かりづらいです。</p> <p>特にムービーリンク関係が厳しくて、例えば以下の「動画を追加する」リンクのタップできる箇所がとても狭いです。この範囲外をクリックすると、課題を完登したユーザー一覧が表示されてしまい、(Android の場合)そこから「戻る」ボタンを押すと「完登した課題の一覧」の先頭まで戻されてしまいます。これは、過去のムービーリンクを追加するときに何度も引っかかってストレスでした。ぜひ改善をお願いします……。</p> <p><figure class="figure-image figure-image-fotolife" title="厳しいタップ範囲(ムービーリンクの追加の場合)"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026232405.png" alt="f:id:muziyoshiz:20191026232405p:plain" title="f:id:muziyoshiz:20191026232405p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>厳しいタップ範囲(ムービーリンクの追加の場合)</figcaption></figure></p> <h3>ロッキー独自の番号システムのサポートがなくなった</h3> <p>ロッキーではもともと、すべての課題に異なる番号が、難易度順に振られていました。ロッキー以外のジムにも対応するために仕方なかったのだと思いますが、Satellite V2.0 からはこの番号の表示機能がなくなっています。</p> <p>これは若干不便になったんですが、その代わりに「課題一覧で写真が表示されるようになった」「新しい課題が NEW と表示されるようになった」という改善も入っているので、実際使うとそこまで問題にはなりませんでした。</p> <p><figure class="figure-image figure-image-fotolife" title="同じ級の課題はすべて同じ番号(ポイント)"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20191026/20191026233240.png" alt="f:id:muziyoshiz:20191026233240p:plain" title="f:id:muziyoshiz:20191026233240p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>同じ級の課題はすべて同じ番号(ポイント)</figcaption></figure></p> <h2>まとめ</h2> <p>Satellite V2.0 は、もともと非常に高機能だったアプリ「サテライトロッキー」を順当に進化させて、ロッキーという1つのジムに収まらない、今後の可能性を感じさせるアプリになりました。これからボルダリングを始める人には、ぜひこの「サテライトロッキー」で近場のクライミングジムを探して、ボルダリングに挑戦してみてほしいです!</p> <p>インストールは以下のツイート内のリンクからどうぞ。</p> <p><blockquote class="twitter-tweet" data-lang="HASH(0x562da3429978)"><p lang="ja" dir="ltr">【BIG NEWS】<br><br>ついに。明日10/23(水)早朝。<br>Satellite V2.0がリリースされます。<br><br>インストールは以下URLより<br>※リリース前はサテロキになっています。<br><br>app store: <a href="https://t.co/W44l73qiqc">https://t.co/W44l73qiqc</a><br><br>Android: <a href="https://t.co/VpflqscpSP">https://t.co/VpflqscpSP</a> <a href="https://t.co/HzRs0jJPGJ">pic.twitter.com/HzRs0jJPGJ</a></p>&mdash; Satellite App &amp; Holds (@Satelliteclimb) <a href="https://twitter.com/Satelliteclimb/status/1186565591189950464?ref_src=twsrc%5Etfw">October 22, 2019</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> muziyoshiz Admiral Stats のサービス提供終了に向けた作業予定 hatenablog://entry/26006613442351155 2019-09-29T20:18:36+09:00 2019-10-05T13:36:20+09:00 お知らせ(繰り返し) 先日お伝えした通り、2019年9月末をもって Admiral Stats のサービス提供は終了します。 Admiral Stats 上のプレイデータはすべて閲覧できなくなるため、必要な方は今月中(つまり明日まで!)にエクスポート機能を使って CSV ファイルのダウンロードをお願いします。 今後の作業予定 といいつつ、サービス提供終了に向けた準備がなかなか進んでいないため、10月になってもまだしばらく Admiral Stats は動いていると思います……。 ただ、10月1日以降は、準備ができた段階で追加のお知らせなど無しにサービスを停止していきますので、予めご了承ください… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20170128/20170128164643.png" alt="f:id:muziyoshiz:20170128164643p:plain" title="f:id:muziyoshiz:20170128164643p:plain" class="hatena-fotolife" itemprop="image"></span></div> <h2>お知らせ(繰り返し)</h2> <p>先日お伝えした通り、2019年9月末をもって Admiral Stats のサービス提供は終了します。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F07%2F27%2F191007" title="Admiral Stats のサービス提供終了のお知らせ - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p> <p>Admiral Stats 上のプレイデータはすべて閲覧できなくなるため、必要な方は今月中(つまり明日まで!)にエクスポート機能を使って CSV ファイルのダウンロードをお願いします。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F08%2F31%2F161643" title="Admiral Stats のエクスポート機能提供のお知らせ(2019年9月末まで使えます) - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe></p> <h2>今後の作業予定</h2> <p>といいつつ、サービス提供終了に向けた準備がなかなか進んでいないため、10月になってもまだしばらく Admiral Stats は動いていると思います……。</p> <p>ただ、10月1日以降は、準備ができた段階で追加のお知らせなど無しにサービスを停止していきますので、予めご了承ください。</p> <p>今後は、次のように作業を進めていき、遅くとも10月以内には完了させるつもりです。</p> <ul> <li>Admiral Stats の終了をお知らせするページを作成(おそらく GitHub Pages で作成)</li> <li>admiral-stats.com で表示されるページを、現在の Admiral Stats から上記のページに変更</li> <li>Admiral Stats 関係のサーバをすべて停止</li> <li>Mackerel 上でサーバを退役</li> <li>Admiral Stats の Twitter アプリ設定を削除</li> <li>GitHub 上のソースコードの README に、サービス提供終了の旨を追記</li> <li>Travis CI でのビルド設定を削除</li> <li>Admiral Stats をせっかく3年近く運用してきたので、そのまとめ記事を何か書く(やってみてよかったこととか、かかった費用の内訳とか)</li> </ul> muziyoshiz Admiral Stats のエクスポート機能提供のお知らせ(2019年9月末まで使えます) hatenablog://entry/26006613412463363 2019-08-31T16:16:43+09:00 2019-08-31T16:16:43+09:00 先日お伝えした通り、Admiral Stats のサービス提供は9月末をもって終了します。 その際にお約束していたエクスポート機能の開発が完了しました。 2019年9月末にサービスを終了するため、エクスポートしたい方はそれまでにお試しください。 muziyoshiz.hatenablog.com エクスポート機能の使い方 ログイン後に、メニューから「エクスポート」をクリックしてください。次のようなページが表示されます。このページのリンクをクリックすると、CSV ファイルのダウンロードが始まります。 ファイル形式の解説 基本的に、MySQL のテーブルに保存されている値をそのまま出力しています。… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20170128/20170128164643.png" alt="f:id:muziyoshiz:20170128164643p:plain" title="f:id:muziyoshiz:20170128164643p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>先日お伝えした通り、Admiral Stats のサービス提供は9月末をもって終了します。 その際にお約束していたエクスポート機能の開発が完了しました。</p> <p><strong>2019年9月末にサービスを終了するため、エクスポートしたい方はそれまでにお試しください。</strong></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F07%2F27%2F191007" title="Admiral Stats のサービス提供終了のお知らせ - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/07/27/191007">muziyoshiz.hatenablog.com</a></cite></p> <h2>エクスポート機能の使い方</h2> <p>ログイン後に、メニューから「エクスポート」をクリックしてください。次のようなページが表示されます。このページのリンクをクリックすると、CSV ファイルのダウンロードが始まります。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20190831/20190831161449.png" alt="f:id:muziyoshiz:20190831161449p:plain" title="f:id:muziyoshiz:20190831161449p:plain" class="hatena-fotolife" itemprop="image"></span></div> <h2>ファイル形式の解説</h2> <p>基本的に、MySQL のテーブルに保存されている値をそのまま出力しています。ただし、ログイン中のユーザの情報だけをエクスポートしているので、admiral_id カラムは出力していません。</p> <h3>提督情報 - 基本情報 (admiral_statuses.csv)</h3> <table> <thead> <tr> <th> カラム名 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> exported_at </td> <td> SEGA の「提督情報」からエクスポートされた日時 </td> </tr> <tr> <td> fuel </td> <td> 燃料 </td> </tr> <tr> <td> ammo </td> <td> 弾薬 </td> </tr> <tr> <td> steel </td> <td> 鋼材 </td> </tr> <tr> <td> bauxite </td> <td> ボーキサイト </td> </tr> <tr> <td> bucket </td> <td> 修復バケツ </td> </tr> <tr> <td> level </td> <td> 艦隊司令部Level </td> </tr> <tr> <td> room_item_coin </td> <td> 家具コイン </td> </tr> <tr> <td> result_point </td> <td> 戦果 </td> </tr> <tr> <td> rank </td> <td> 暫定順位 </td> </tr> <tr> <td> title_id </td> <td> 階級を表す数値 </td> </tr> <tr> <td> strategy_point </td> <td> 戦略ポイント </td> </tr> <tr> <td> kou_medal </td> <td> 甲種勲章の数 </td> </tr> </tbody> </table> <table> <thead> <tr> <th> title_id の値 </th> <th> 意味 </th> </tr> </thead> <tbody> <tr> <td> 0 </td> <td> 新米少佐 </td> </tr> <tr> <td> 1 </td> <td> 中堅少佐 </td> </tr> <tr> <td> 2 </td> <td> 少佐 </td> </tr> <tr> <td> 3 </td> <td> 新米中佐 </td> </tr> <tr> <td> 4 </td> <td> 中佐 </td> </tr> <tr> <td> 5 </td> <td> 大佐 </td> </tr> <tr> <td> 6 </td> <td> 少将 </td> </tr> <tr> <td> 7 </td> <td> 中将 </td> </tr> <tr> <td> 8 </td> <td> 大将 </td> </tr> <tr> <td> 9 </td> <td> 元帥 </td> </tr> <tr> <td> 10 </td> <td> 集計中 </td> </tr> </tbody> </table> <h3>提督情報 - イベントの進捗 (event_progress_statuses.csv)</h3> <table> <thead> <tr> <th> カラム名 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> exported_at </td> <td> SEGA の「提督情報」からエクスポートされた日時 </td> </tr> <tr> <td> event_no </td> <td> イベント No. (例:第壱回なら 1) </td> </tr> <tr> <td> level </td> <td> 難易度(HEI, OTU, KOU) </td> </tr> <tr> <td> period </td> <td> 作戦(前段作戦: 0, 後段作戦: 1, Extra Operation (EO): 2) </td> </tr> <tr> <td> opened </td> <td> 難易度が解放済みかどうか </td> </tr> <tr> <td> current_loop_counts </td> <td> 現在の周回数(1〜) </td> </tr> <tr> <td> cleared_loop_counts </td> <td> 最終ステージまで攻略済みの周回数(0〜) </td> </tr> <tr> <td> cleared_stage_no </td> <td> 現在の周回で攻略済みのステージ番号(0 〜) </td> </tr> <tr> <td> current_military_gauge_left </td> <td> 攻略中のステージの海域ゲージの現在値(0〜) </td> </tr> </tbody> </table> <h3>提督情報 - 輸送イベントの進捗 (cop_event_progress_statuses.csv)</h3> <table> <thead> <tr> <th> カラム名 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> exported_at </td> <td> SEGA の「提督情報」からエクスポートされた日時 </td> </tr> <tr> <td> event_no </td> <td> イベント No. (例:第壱回なら 1) </td> </tr> <tr> <td> numerator </td> <td> TPゲージの残量 </td> </tr> <tr> <td> denominator </td> <td> TPゲージの最大数 </td> </tr> <tr> <td> achievement_number </td> <td> 現在の周回数(1周目=クリア周回数0の場合は1) </td> </tr> <tr> <td> area_achievement_claim </td> <td> "全提督協力作戦 達成報酬獲得権利" の権利獲得済かどうか </td> </tr> <tr> <td> limited_frame_num </td> <td> 限定フレームの所持数 </td> </tr> </tbody> </table> <h3>艦娘情報 (ship_statuses.csv)</h3> <table> <thead> <tr> <th> カラム名 </th> <th> 内容 </th> </tr> </thead> <tbody> <tr> <td> exported_at </td> <td> SEGA の「提督情報」からエクスポートされた日時 </td> </tr> <tr> <td> book_no </td> <td> 艦娘図鑑の図鑑 No. </td> </tr> <tr> <td> remodel_level </td> <td> 解像度合いを表す数値 </td> </tr> <tr> <td> level </td> <td> レベル </td> </tr> <tr> <td> star_num </td> <td> 星の数 </td> </tr> <tr> <td> exp_percent </td> <td> 経験値の獲得割合(%) </td> </tr> <tr> <td> blueprint_total_num </td> <td> 改装設計図の枚数 </td> </tr> <tr> <td> married </td> <td> ケッコンカッコカリ済みかどうか </td> </tr> </tbody> </table> <table> <thead> <tr> <th> remodel_level の値 </th> <th> 意味 </th> </tr> </thead> <tbody> <tr> <td> 0 </td> <td> 未改造 </td> </tr> <tr> <td> 1 </td> <td> 改 </td> </tr> <tr> <td> 2 </td> <td> 改二, 千歳/千代田 甲 </td> </tr> <tr> <td> 3 </td> <td> 千歳/千代田 航 </td> </tr> <tr> <td> 4 </td> <td> 千歳/千代田 航改 </td> </tr> <tr> <td> 5 </td> <td> 千歳/千代田 航改二 </td> </tr> </tbody> </table> muziyoshiz Admiral Stats のサービス提供終了のお知らせ hatenablog://entry/26006613378541496 2019-07-27T19:10:07+09:00 2019-07-27T19:10:07+09:00 大切なお知らせ 2016年9月から約3年に渡って、https://www.admiral-stats.com/ にて提供していた Admiral Stats のサービス提供を終了します。 今後の予定としては、8月末を目標に、プレイデータの一部に限定したエクスポート機能を実装するつもりです。その後、1ヶ月の猶予をもって、9月末にサービス提供を終了します。 いままで Admiral Stats をご愛顧いただきありがとうございました。 ユーザーの方にしていただく必要があること 特にありません。9月末までは従来どおりに Admiral Stats 上でプレイデータを閲覧できます。最新のデータ形式への… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20170128/20170128164643.png" alt="f:id:muziyoshiz:20170128164643p:plain" title="f:id:muziyoshiz:20170128164643p:plain" class="hatena-fotolife" itemprop="image"></span></div> <h2>大切なお知らせ</h2> <p>2016年9月から約3年に渡って、<a href="https://www.admiral-stats.com/">https://www.admiral-stats.com/</a> にて提供していた Admiral Stats のサービス提供を終了します。</p> <p>今後の予定としては、8月末を目標に、プレイデータの一部に限定したエクスポート機能を実装するつもりです。その後、1ヶ月の猶予をもって、9月末にサービス提供を終了します。</p> <p>いままで Admiral Stats をご愛顧いただきありがとうございました。</p> <h2>ユーザーの方にしていただく必要があること</h2> <p>特にありません。9月末までは従来どおりに Admiral Stats 上でプレイデータを閲覧できます。最新のデータ形式への対応はしない予定です。</p> <p>退会手続きなどは必要ありません。個人を特定可能なデータは、9月末のサービス終了後にすべて破棄します。</p> <p>サービス提供後も admiral-stats.com のドメインは保持し、<a href="https://www.admiral-stats.com/">https://www.admiral-stats.com/</a> へのアクセスは GitHub の Admiral Stats ページにリダイレクトする予定です。</p> <h2>エクスポート機能について</h2> <p>元々、プライバシーポリシーのページには「エクスポート機能の提供予定はありません」と記載していました。</p> <p>しかし、3年近くプレイデータを溜めていただいている方もいますので、最低限のプレイデータは CSV 形式でエクスポートできるようにしたいと考えています(夏休みにできる範囲でがんばって実装します)。</p> <p>いま検討中なのは以下の範囲です。</p> <ul> <li>提督情報 <ul> <li>艦隊司令部レベル・経験値、資源、資源以外の消耗品、戦果、暫定順位</li> </ul> </li> <li>イベントの進捗、輸送イベントの進捗 <ul> <li>周回数のみ</li> </ul> </li> <li>艦娘情報 <ul> <li>レベル・経験値(艦娘別)のみ</li> </ul> </li> </ul> <p>その他の情報は、ほとんどは SEGA 公式のサイトで確認できるため、対象外とさせてください。</p> <h2>その他</h2> <p>Admiral Stats のソースコードは GitHub で公開したままにします。削除の予定はありません。MIT License に従って手元で利用いただいたり、ソースコードをフォークしていただくのは自由です。</p> <h2>最後に:サービス提供終了に関する事情とかいろいろ</h2> <p>以下、個人的な話なので読まなくても OK です。</p> <p>2016年4月に艦これアーケードのサービスが開始し、このゲームにハマったのが Admiral Stats 開発のきっかけでした。しかし、個人的な心境の変化であったり、使える時間の変化があって、去年11月のAL/MI作戦を最後に、艦これアーケードを全くプレイしていない状態でした。</p> <p>艦これアーケード自体はいまでも面白いゲームだと思うし、ゲームが嫌になる何かがあったとかでは無いです。ただ、最近何度か公式サイトで大きなプレイデータ形式の変更があり、ゲームをプレイしていない状態で、変更に追従するモチベーションが無くなってしまっていました。</p> <p>そのため、まともに動かない(このままだといずれそうなる)サービスを放置するよりは、きちんと期限を決めてサービス提供を終了しようと思った次第です。</p> <p>最後に改めて、いままで Admiral Stats をご愛顧いただきありがとうございました。また、周辺ツールの提供、Web サイトでの紹介など、ご協力頂いた皆様も誠にありがとうございました。</p> muziyoshiz nginx.conf の location の優先順位を正しく理解する hatenablog://entry/17680117127211205045 2019-06-30T20:39:03+09:00 2019-06-30T20:42:25+09:00 最近、Nginx の location 設定の優先順位を誤解していて軽くつまづきました。このへん時々よくわからなくなるので、自分のためにまとめておきます。 情報源 公式の説明は、マニュアルの Module ngx_http_core_module ページ内の "location" の項にあります。 nginx.org location の修飾子(modifier) location を定義する際に使える修飾子は、以下の5種類です。 修飾子 判定方法 = 完全一致 なし 前方一致 ^~ 前方一致 ~* 正規表現(case-insensitive) ~ 正規表現(case-sensitive) 前… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20171026/20171026000347.png" alt="f:id:muziyoshiz:20171026000347p:plain" title="f:id:muziyoshiz:20171026000347p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>最近、Nginx の location 設定の優先順位を誤解していて軽くつまづきました。このへん時々よくわからなくなるので、自分のためにまとめておきます。</p> <h2>情報源</h2> <p>公式の説明は、マニュアルの Module ngx_http_core_module ページ内の "location" の項にあります。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fnginx.org%2Fen%2Fdocs%2Fhttp%2Fngx_http_core_module.html%23location" title="Module ngx_http_core_module" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#location">nginx.org</a></cite></p> <h2>location の修飾子(modifier)</h2> <p>location を定義する際に使える修飾子は、以下の5種類です。</p> <table> <thead> <tr> <th> 修飾子 </th> <th> 判定方法 </th> </tr> </thead> <tbody> <tr> <td> <code>=</code> </td> <td> 完全一致 </td> </tr> <tr> <td> なし </td> <td> 前方一致 </td> </tr> <tr> <td> <code>^~</code> </td> <td> 前方一致 </td> </tr> <tr> <td> <code>~*</code> </td> <td> 正規表現(case-insensitive) </td> </tr> <tr> <td> <code>~</code> </td> <td> 正規表現(case-sensitive)</td> </tr> </tbody> </table> <p>前方一致が2種類ありますが、これは「<code>^~</code> は省略可能」という意味<strong>ではありません</strong>。</p> <h2>location の優先順位</h2> <p>location の優先順位を考える上でややこしい点は、<strong>書かれた順に評価される設定と、最長一致で評価される設定が混在している</strong>ことです。特に、優先順位をややこしくしているのが <code>^~</code> の存在です。</p> <p>Nginx は、あるリクエスト URI に対する configuration を決めるために、以下の手順で location を選択します。</p> <ol> <li>完全一致の location を判定し、マッチしたらその location を選んで終了</li> <li>前方一致の location を判定し、最も長い文字列がマッチしたものを記録する(<strong>最も長い文字列がマッチした location が <code>^~</code> 修飾子を使っていた場合に限り</strong>、その location を選んで終了)</li> <li>正規表現の location を、設定ファイルに書かれた順で判定し、最初にマッチしたものが見つかった時点で終了</li> <li>3 でマッチするものが見つからなかった場合は、2 で見つかった location を選んで終了</li> </ol> <p>ポイントは、<code>^~</code> にマッチしたらその場で判定が終わるわけではない、ということです。<code>^~</code> なしの前方一致のほうが最も長い文字列(longest matching prefix)の場合は、手順3の正規表現の判定に進んでしまう、という点に注意が必要です。</p> <p>もしも <code>^~</code> 修飾子を全く使わなければ、以下のように簡単に優先順位を説明できます。</p> <ol> <li>完全一致</li> <li><code>~*</code> または <code>~</code> 修飾子で定義された正規表現のうち、設定ファイルに書かれた順で最も最初にマッチしたもの</li> <li>修飾子なしで定義された前方一致のうち、最も長い文字列がマッチしたもの</li> </ol> <h2>結局 location はどういう順に書いたらいいか?</h2> <p>個人的には読みやすさを考えて、評価される順(自分が評価してほしいと期待する順)に書いておくのがよいと思います。また、<code>^~</code> ありの前方一致は混乱を招くため、<code>^/</code> から始まる正規表現として書いてしまったほうがよいのではないか、と思います。</p> <ol> <li>完全一致の location を書く</li> <li>優先したい前方一致の location を、<code>^/</code> から始まる正規表現の location として書く(<code>^~</code> は使わない)</li> <li>正規表現の location を、優先したいものから順に書く</li> <li>修飾子なしの前方一致の location を、長いものから順に書く</li> </ol> <p>Nginx のマニュアルに書かれた location の例を微修正して、上のルールに従って書き直したものがこちらです。</p> <pre class="code" data-lang="" data-unlink># ルートへの完全一致 location = / { [ configuration A ] } # /images/ 以下の画像 location ~ ^/images/ { [ configuration D ] } # /images/ 以外に置かれた画像 location ~* \.(gif|jpg|jpeg)$ { [ configuration E ] } # /documents/ 以下のページ location /documents/ { [ configuration C ] } # その他すべてのページ location / { [ configuration B ] }</pre> <h2>まとめ</h2> <p>おそらくですが、適当な順序で location を書いてしまってもなんとなくそれなりに動くように、こういう仕様になっているのではないか、と思います。とはいえ、このへんを正確に理解しておかないと、他の人が書いた nginx.conf をいじるときにつまづきやすいので気をつけましょう。</p> <h2>参考ページ</h2> <p>location に関する説明を色々探してみて、このブログの記載が一番わかりやすくて参考になりました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fpaulownia.hatenablog.com%2Fentry%2F2018%2F07%2F21%2F140906" title="nginxのlocationの優先順位を誤解していた - NullPointer&#39;s" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://paulownia.hatenablog.com/entry/2018/07/21/140906">paulownia.hatenablog.com</a></cite></p> <h2>おまけ:location の説明の日本語訳</h2> <p>以下、マニュアルの該当箇所の日本語訳です。古いバージョンの Nginx について書かれた記載や、特殊なケース(macOS など)について書かれたケースは割愛しました。</p> <blockquote><p>Sets configuration depending on a request URI.</p></blockquote> <p>location はリクエスト URI に応じて configuration を設定する。</p> <blockquote><p>The matching is performed against a normalized URI, after decoding the text encoded in the “%XX” form, resolving references to relative path components “.” and “..”, and possible compression of two or more adjacent slashes into a single slash.</p></blockquote> <p>マッチングは正規化された URI に対して実施される。正規化とは、"%XX" 形式でエンコードされたテキストのデコード、相対パスを表すコンポーネント "." および ".." への参照の解決、そして2つ以上の隣接したスラッシュの1個のスラッシュへの圧縮である。</p> <blockquote><p>A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.</p></blockquote> <p>location は prefix string または正規表現で定義できる。 正規表現は "~*" 修飾子(case-insensitive なマッチング)、または "~" 修飾子(case-sensitive なマッチング)で指定される。 与えられたマッチする location を探すために、nginx は最初に prex strings (prefix locations) を使って定義された location をチェックする。 そのチェックの間に、最も長い prefix とマッチした location が選ばれて記録される。 その次に正規表現が、設定ファイルの中で登場した位置の順にチェックされる。 正規表現の検索は、最初にマッチした段階で終了して、その location に書かれた configuration が使われる。 もし、そのリクエスト URL にマッチする正規表現が見つからなかった場合は、その前の段階で記録された prefix location の configuration が使われる。</p> <blockquote><p>location blocks can be nested, with some exceptions mentioned below.</p></blockquote> <p>location ブロックはネスト可能である。ただし、以下に示すいくつかの例外がある。</p> <blockquote><p>Regular expressions can contain captures (0.7.40) that can later be used in other directives.</p></blockquote> <p>正規表現は captures を含むことができる(0.7.40)。これは後の directives で使うことができる。</p> <blockquote><p>If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.</p></blockquote> <p>もし、longest matching prefix location が "^~" 修飾子を持っていたら、正規表現はチェックされない。</p> <blockquote><p>Also, using the “=” modifier it is possible to define an exact match of URI and location. If an exact match is found, the search terminates. For example, if a “/” request happens frequently, defining “location = /” will speed up the processing of these requests, as search terminates right after the first comparison. Such a location cannot obviously contain nested locations.</p></blockquote> <p>また、"=" 修飾子 を使うと、URI と location の完全一致を定義できる。 もし、完全一致が見つかったら、location の検索は終了する。例えば、もし "/" へのリクエストが頻繁に起こるなら、<code>location = /</code> を定義することでそれらのリクエストの処理を高速化できる。検索は最初の比較で完了するからである。そのような location が、ネストされた location を持つことは明らかにできない。</p> <blockquote><p>Let’s illustrate the above by an example:</p></blockquote> <p>上記のことを、例を使って説明しよう。</p> <pre class="code" data-lang="" data-unlink>location = / { [ configuration A ] } location / { [ configuration B ] } location /documents/ { [ configuration C ] } location ^~ /images/ { [ configuration D ] } location ~* \.(gif|jpg|jpeg)$ { [ configuration E ] }</pre> <blockquote><p>The “/” request will match configuration A, the “/index.html” request will match configuration B, the “/documents/document.html” request will match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E.</p></blockquote> <p>/ へのリクエストは configuration A にマッチする。"/index.html" へのリクエストは B にマッチし、"/documents/document.html" は C にマッチする。"images/1.gif" は D にマッチし、"/documents/1.jpg" は E にマッチする。</p> <blockquote><p>The “@” prefix defines a named location. Such a location is not used for a regular request processing, but instead used for request redirection. They cannot be nested, and cannot contain nested locations.</p></blockquote> <p>"@" 前置詞は名前付きの location を定義する。そのような location は正規表現の処理には使われないが、リクエストのリダイレクトのために使われる。"@" 付きの location はネストできないし、ネストされた location を含むこともできない。</p> <blockquote><p>If a location is defined by a prefix string that ends with the slash character, and requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then the special processing is performed. In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended. If this is not desired, an exact match of the URI and location could be defined like this:</p></blockquote> <p>もし、location が、/ で終了する prefix string によって定義された場合、リクエストは proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, または grpc_pass のうちの1つによって処理されて、その特別な処理が実行される。 この文字列に一致する URI を持つリクエスト、しかし末尾に / が付かない URI の場合は、その URI に対する恒久的なリダイレクトが、/ 付きの URI に対して返される。 もし、その動作が望ましくない場合、URI と location の完全一致を以下のように定義すればよい。</p> <pre class="code" data-lang="" data-unlink>location /user/ { proxy_pass http://user.example.com; } location = /user { proxy_pass http://login.example.com; }</pre> muziyoshiz Mercari Meetup for Microservices Platform #2 参加レポート hatenablog://entry/17680117127170368615 2019-05-27T23:11:06+09:00 2019-05-31T12:39:42+09:00 メルカリの Microservices Platform Team のメンバによる技術イベント Mercari Meetup for Microservices Platform #2 に参加してきました。 connpass.com どの講演も非常に面白くて、参考になりました。特に @spesnova さんによるマイクロサービスとその監視の事例は、このレベルを目指して頑張りたいと思える内容でした。 今回は、個人的に興味深かった部分中心のメモです。プレゼン資料が公開されていない部分などは、多少ミスもあると思います。そこはご了承ください(訂正情報いただいたら直します)。 Introduction … <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20190527/20190527230059.png" alt="f:id:muziyoshiz:20190527230059p:plain" title="f:id:muziyoshiz:20190527230059p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>メルカリの Microservices Platform Team のメンバによる技術イベント Mercari Meetup for Microservices Platform #2 に参加してきました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fconnpass.com%2Fevent%2F128017%2F" title="Mercari Meetup for Microservices Platform #2 (2019/05/22 19:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://connpass.com/event/128017/">connpass.com</a></cite></p> <p>どの講演も非常に面白くて、参考になりました。特に @spesnova さんによるマイクロサービスとその監視の事例は、このレベルを目指して頑張りたいと思える内容でした。</p> <p>今回は、個人的に興味深かった部分中心のメモです。プレゼン資料が公開されていない部分などは、多少ミスもあると思います。そこはご了承ください(訂正情報いただいたら直します)。</p> <h2>Introduction &amp; Attention</h2> <p>(スライドは未公開。タイトルは Connpass ページに掲載のもの)</p> <p>Microservices Platform Team の Engineering Manager <a href="https://twitter.com/masartz">@masartz</a> さんによる導入。</p> <ul> <li>Mercari Microservices Platform Team の紹介 <ul> <li>マネージャ1名とエンジニア8名の計9名</li> <li>Mercari と Merpay 両方のサービスが乗るプラットフォームを作っている</li> <li>新しい分野に対してチャレンジングな仕事をしている</li> <li>Observatoryといった数値を大事にして、いろいろな取り組みをしようとしている</li> <li>自分たちで仕組みを改善していっている</li> </ul> </li> <li>Merpay SRE の紹介 <ul> <li>マネージャ1名と SRE 3名の計4名</li> <li>Merpay の安定性と信頼性を支える</li> <li>Mercari はモノリスからマイクロサービスに置き換えるというチャレンジをしているが、Merpay は最初からマイクロサービスで作る、というまた別のチャレンジをしている</li> </ul> </li> </ul> <h2>Kubernetes Cluster Monitoring</h2> <script async class="speakerdeck-embed" data-id="e7b3f9af28ab49bf9e0cf091fcbb47dc" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>Microservices Platform Team の <a href="https://twitter.com/spesnova">@spesnova</a> さんによる、Kubernetes クラスタの監視についての講演。</p> <p>Kubernetes クラスタの監視について非常に細かく解説されており、勉強になりました。</p> <ul> <li>Monitoring kubernetes cluster <ul> <li>Microservices Platform Team はクラスタ自体の監視をする(その上のアプリ監視の話ではなくて)</li> <li>何を持ってクラスタが正常かどうかを確認しているか?</li> </ul> </li> <li>マイクロサービスの規模 <ul> <li>Kubernetes クラスタ上に、 <ul> <li>マイクロサービス 100+</li> <li>Pod 2K+</li> <li>コンテナ 2K+</li> <li>マイクロサービスを開発するエンジニア 200+</li> </ul> </li> <li>会社全体で Kubernetes クラスタは1個ではない</li> <li>Microservices Platform Team が見てないクラスタはまだたくさんある</li> <li>メルカリ全体ではコンテナ 13k くらい?</li> </ul> </li> <li>Platform チームと developerの責任分界点(boundary) <ul> <li>Pods より上は developer</li> <li>Pods より下は Platform チーム <ul> <li>Kubernetes master は GKE の管理下</li> <li>Kubernetes nodes は GKE の管理下ではない。これはどこのクラウドでもそのはず</li> </ul> </li> </ul> </li> <li>メトリクスの設計 <ul> <li>RED and USE method</li> <li>これの別表現で Work and Resource という言い方があり、両方の言い方を使っている</li> </ul> </li> <li>The Work (RED) metrics <ul> <li>システムが動いているか壊れているかを教えてくれるメトリクス</li> <li>Throughput, Success, Error, Performance</li> <li>Work のほうの Error は、レスポンスのエラーレートとか</li> </ul> </li> <li>The Resource (USE) metrics <ul> <li>内部のメトリクス。low-level healthを教えてくれる</li> <li>Utilization, Saturation, Errors, Availability</li> <li>例:swapを使ってる=どれくらい足りてないか=Saturation</li> <li>Resource のほうの Errors は、バックエンドのサービスのエラーレートとか</li> </ul> </li> <li>Kubernetes クラスタの生死をどうやって監視する? <ul> <li>クラスタにとっての Work メトリクス=orchestrating できてるかどうか <ul> <li>Ready な Pod の数</li> <li>Unavailable な Pod の数</li> <li>Deployment ごとの Pods など、もっと細かい切り口でのメトリクス</li> </ul> </li> <li>Unavailable な pod がない=クラスタが orchestration の仕事をしている</li> <li>ただ、unavailable な pod があっても、クラスタのせいとは限らない(開発者の設定ミス、GKEの障害など) <ul> <li>そのため、パーセンテージでアラートを出している。しきい値は緩めにしている</li> <li>オオカミ少年にならないように</li> </ul> </li> <li>Master Components, Node Components, Addons の分類</li> </ul> </li> <li>使っているツール <ul> <li>Cluster-level monitoring = prometheus</li> <li>Cluster-level logging = fluentd とか</li> <li>Stackdriver と Datadog</li> </ul> </li> <li>Work metrics の実例 <ul> <li>メトリクスは Datadog で可視化している。Datadog のスクリーンショットを使いながら解説</li> <li>GKE の障害は、僕らではどうしようもないので、神経質に見ない(というようなことをなにか別の表現をしていたけど忘れた)</li> <li>kubelet runtime error rate を見ている。しきい値は緩めに設定</li> <li>kube-proxy work metrics は可視化しているが、prometheusとの連携がうまくなくて?あまり使い物にならない。今後の課題</li> </ul> </li> <li>Resource metrics の実例 <ul> <li>CPU, disk, memory, network など</li> <li>クラスタ単位、ノード単位のダッシュボードもある</li> </ul> </li> <li>ダッシュボード <ul> <li>SRE と application engineer の間で、監視の boundary を決める</li> <li>Work metrics と Resource metrics を意識してダッシュボードを作る(Work と Resource のダッシュボードは別)</li> <li>Kubernetes のクラスタは分散システムなので、1箇所だけ見れば良いということはなく、Work と Resource を区別していろいろなダッシュボードを作って監視する必要がある</li> </ul> </li> </ul> <h2>Securing Microservices Continuous Delivery using Grafeas and Kritis</h2> <iframe src="//www.slideshare.net/slideshow/embed_code/key/kmxeSbj6X1PMjg" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <p> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/VishalBanthia1/securing-microservices-continuous-delivery-using-grafeas-and-kritis" title="Securing microservices continuous delivery using grafeas and kritis" target="_blank">Securing microservices continuous delivery using grafeas and kritis</a> </strong> from <strong><a href="https://www.slideshare.net/VishalBanthia1" target="_blank">Vishal Banthia</a></strong> </div></p> <p>Microservices Platform Team の <a href="https://twitter.com/vbanthia_">@vbanthia_</a> さんによる、CI/CD へのポリシーの強制方法についての講演。</p> <ul> <li>code > build > test > deploy といったワークフローの各段階で、ガバナンスを保ちたい <ul> <li>この機能をデプロイしてよいか</li> <li>脆弱性対応が済んでいるか(例:<a href="https://cpu.fail">cpu.fail</a>)</li> </ul> </li> <li>ガバナンスを保つためには、従来はいろいろな CI/CD ツールを組み合わせてワークフローを実装する必要があった <ul> <li>いろいろなツールを組み合わせると、各フェーズをまたぐときにメタデータが失われてしまう</li> </ul> </li> <li>Grafeas(グラフィアス)は、中央集中型の汎用的なメタデータ管理サーバ <ul> <li>オープンな artifact metadata API を通して、任意のツールからメタデータを登録できる</li> </ul> </li> <li>Kritis はポリシーを強制するためのツール <ul> <li>Platform チームでは GCP と Spinnaker を使っている</li> <li>公式の Kritis はまだ early stage で、メルカリで必要な機能が未実装</li> <li>そのため、Kritis を fork して機能拡張したものを使っている</li> <li>QA → PM の順に承認を得て、承認を得た docker image だけが production cluster にデプロイされる</li> </ul> </li> </ul> <h2>How We Structure Our Work At Mercari Microservices Platform Team</h2> <script async class="speakerdeck-embed" data-id="e0a66b8c53d34c20966b52df83bf933b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>Microservices Platform Team の <a href="https://twitter.com/deeeet">@deeeet</a> さんによる講演。</p> <p>Platform チームができてから2年位経つそうなのですが、そのなかでのプロジェクト管理方法の変遷についてのお話でした。</p> <ul> <li>Platform チームにおけるプロジェクトマネジメント <ul> <li>特殊なことをしているわけではない。一般的なWeb開発と変わらない</li> <li>チームとしてのアウトプットを最大化する=開発者の生産性を最大化する=よりよいプロダクトをMercariの顧客により早く提供する</li> <li>プロジェクトマネジメントのやり方を、チーム自身で継続的に改善している</li> </ul> </li> <li>歴史 <ul> <li>最初は deeeet さん1人だった</li> <li>5名までは "No project management"</li> <li>8名までは (lightweight) Agile</li> <li>9名になった現在は 6 Week Release Cycle を採用している。今日は主にこれを紹介する</li> </ul> </li> <li>No project management <ul> <li>単純な四半期のマイルストーンしかなかった</li> <li>各人が課題を見つけて取り組んでいた</li> <li>基本的に個人プレイで、チームではなかった。個人でやりたいことやっていた</li> <li>マイルストーンにはやりたいことが詰まっていて、手元のタスクが進まなかった</li> <li>ドキュメント整備、自動化が進まなかった。開発者に対するサポート業務に時間が取られていた</li> <li>この経験からの学び:個人でできることには限界がある。チームとして動く必要がある</li> </ul> </li> <li>(lightweight) Agile <ul> <li>2週間のスプリント、カンバン、スクラムマスター</li> <li>採用したのは、業界のデファクトだから。プロジェクト管理を始めなきゃ、という課題意識から始めた</li> <li>50%はプロアクティブなタスク、50%はリアクティブなタスクを取る、という取り組みを始めた(割合はGoogleを参考に)</li> <li>良くなかった点 <ul> <li>ベロシティに集中してしまい、開発者に shipping しているという意識が遠のいた</li> <li>Platform チームの仕事には2週間で区切れない仕事が多かった</li> <li>誰一人見積もりがうまくできなかった。見積もりが目的化する部分があった</li> </ul> </li> <li>根本的に問題があるのでは? <ul> <li>アジャイルは仕様が決まることが前提で、ベロシティから作業量を予測する点が重要だと思う</li> <li>実際は、最初は不確定なことから始まる。基盤系は特にそうではないか?</li> </ul> </li> <li>アジャイルを極めるという選択肢もあったと思うが、自分たちは別の方向を模索し始めた</li> </ul> </li> </ul> <p><figure class="figure-image figure-image-fotolife" title="スライド中で出てきて面白かった図。不確定なうちは規模感がわからない"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20190527/20190527230529.png" alt="f:id:muziyoshiz:20190527230529p:plain" title="f:id:muziyoshiz:20190527230529p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>スライド中で出てきて面白かった図。不確定なうちは規模感がわからない</figcaption></figure></p> <ul> <li>6 Week Release Cycle <ul> <li>すでに2クォーター実施して、うまくいっている</li> <li>Basecamp 社が長い間実践している手法で、"REWORK" という本でも紹介されている <ul> <li><a href="https://m.signalvnoise.com/how-we-structure-our-work-and-teams-at-basecamp/">How we structure our work and teams at Basecamp - Signal v. Noise</a></li> </ul> </li> <li>これをメルカリ流にカスタマイズして使っている</li> </ul> </li> </ul> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/0091929784/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/41ju6JBCJmL._SL160_.jpg" class="hatena-asin-detail-image" alt="ReWork: Change the Way You Work Forever" title="ReWork: Change the Way You Work Forever"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/0091929784/muziyoshiz-22/">ReWork: Change the Way You Work Forever</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> David Heinemeier Hansson,Jason Fried</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> Vermilion</li><li><span class="hatena-asin-detail-label">発売日:</span> 2010/03/18</li><li><span class="hatena-asin-detail-label">メディア:</span> ペーパーバック</li><li><span class="hatena-asin-detail-label">購入</span>: 1人 <span class="hatena-asin-detail-label">クリック</span>: 4回</li><li><a href="http://d.hatena.ne.jp/asin/0091929784/muziyoshiz-22" target="_blank">この商品を含むブログ (2件) を見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <ul> <li>6 Week Release Cycle の概要 <ul> <li>1回のリリースを6週間で区切る <ul> <li>この期間の長さは、だいたいどんな機能でも6週間あればリリースできる、というBasecampの経験則から</li> </ul> </li> <li>この期間にリリースする 1個の bic epic と、2〜3個程度の small epic を決める</li> <li>6週間すべて使うのが big epic</li> <li>1日〜2週間使うものが small epic</li> <li>Big epic に 1 release team、small epic に 1 release team をアサインする</li> <li>1チームは2〜3名</li> <li>2つの原則 <ul> <li>Dedicated resource allocation <ul> <li>Release team には与えられたエピックだけに集中してもらう</li> </ul> </li> <li>Fixed budget and flexible scope <ul> <li>6 week + 2-3 membersというのは変えない</li> <li>スコープは変えていい</li> </ul> </li> </ul> </li> </ul> </li> </ul> <p><figure class="figure-image figure-image-fotolife" title="6 Week Release Cycle"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20190527/20190527231011.png" alt="f:id:muziyoshiz:20190527231011p:plain" title="f:id:muziyoshiz:20190527231011p:plain" class="hatena-fotolife" itemprop="image"></span><figcaption>6 Week Release Cycle</figcaption></figure></p> <ul> <li>メルカリで追加した3番目の原則 <ul> <li>Dedicated On Support Team <ul> <li>開発者からのリクエストと、緊急の要件に対応するための、3番目の release team を作る</li> <li>時間があるときは技術的負債に対応する</li> </ul> </li> </ul> </li> <li>ローテーション方法 <ul> <li>試行錯誤した結果、9名を3チームに分けて、release team (big epic)、release team (small epic)、support team をローテーションする方法に落ち着いた</li> <li>daily や weekly のローテーションでは、release team にとっては開発期間として短く、support team にとっても開発者からのリクエストが完了しきらなかった</li> </ul> </li> </ul> <h2>Merpay Microservices On Microservice Platform</h2> <script async class="speakerdeck-embed" data-id="c1820ebea3634fac9a466e46b4893811" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>メルペイ社にて Engineering Manager も担当している <a href="https://twitter.com/tjun">@tjun</a> さんによる講演。メルペイ社のマイクロサービスの特徴と、その運用に関するお話でした。</p> <p>メルペイ社のシステムは、メルカリのマイクロサービスとは傾向が違う部分が多少あるものの、共通の基盤に乗っているそうです。そのため、microservices-starter-kit や Datadog などの話は、メルカリにも共通する話、とのことでした。</p> <ul> <li>メルペイのマイクロサービス <ul> <li>メルペイだけで40個以上のマイクロサービス</li> <li>メルペイのマイクロサービスの特徴(世間一般、および Mercari との違い) <ul> <li>バッチ処理が多い(k8s上でバッチ処理をしている)</li> <li>外部パートナー(銀行など)との接続が多い</li> <li>開発者に対する権限を絞っている(セキュリティ、コンプラの関係上)</li> </ul> </li> </ul> </li> <li>microservices-starter-kit <ul> <li>新しくマイクロサービスを作るときは、Platform チームが作っている microserivces-starter-kit というものを使ってスタートする</li> <li>サービス名やオーナー、開発者を定義して実行すると、GCP から Kubernetes まで、必要なリソースとその権限設定が自動的に作られる</li> <li>Datadog のダッシュボードや PagerDuty のローテーションの設定まで、デフォルトのものが自動的に作られる(懇親会で聞いた話)</li> </ul> </li> <li>SLO and Alerts <ul> <li>各開発チームに SLO を定義してもらっている</li> <li>SLO は PM も参加して決めてもらう、などのルールを決めている</li> <li>それぞれの SLO について Datadog monitor を設定している - RED metrics</li> <li>Datadog で、各チームに SLOboard というものを作ってもらおうとしている</li> </ul> </li> <li>Datadog APM and Distributed Tracing with Go middlewares <ul> <li>新しい開発者でもどこが遅くなっているか、などを見やすくしている</li> </ul> </li> <li>Incident handling <ul> <li>Datadog と Sentry でのアラートを、Slack や PagerDuty に送っている</li> <li>開発者が一次受けをしたあとで、アプリだけの問題ではない場合は SRE も一緒に問題を見る</li> <li>再発防止のため、インシデントのたびにインシデントレポートを作成する</li> </ul> </li> <li>メルペイの SRE の責任範囲 <ul> <li>アプリケーションをまたがるインフラリソース <ul> <li>Ingress, CDN, キャパシティプランニング、セキュリティ</li> </ul> </li> <li>Production releases and operations <ul> <li>マイクロサービスの知見がないエンジニアも多いので、そこのサポート</li> </ul> </li> </ul> </li> </ul> <h2>感想</h2> <p>プレゼンのあとで、1時間近く懇親会の時間があり、細かい話を直接伺うことができたのはとても良かったです。</p> <p>講演と、懇親会での話を合わせて、僕自身は Platform チームについて次のように理解しました。</p> <ul> <li>Platform チームが見ている Kubernetes クラスタに関しては、かなりの部分がセルフサービス化されている(開発者だけでできるようになっている)</li> <li>セルフサービス化のために、今回の講演で出てきた話(microservices-starter-kit のような自動化、Grafias/Kritis を使ったポリシー管理、開発者自身による監視の一次受け)を組み合わせている上に、ドキュメントの整備なども進めている</li> <li>セルフサービス化が進んだことで、SRE がインフラ関係のコアな業務に集中できる状態になり、結果として Platform チームは9名という少人数で回っている</li> </ul> <p>もちろん、現場ではいろいろ泥臭くて大変なことも多いとは思いますが、マイクロサービス化を推し進めた先の目指すべき理想形のイメージをつかめたような気がします。また同様のイベントがあったら是非参加してみたいです。</p> <h2>追記(2019-05-31)</h2> <p>Mercari Engineer Blog のなかで spesnova さんの資料も公開されていたので、リンク追加しました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Ftech.mercari.com%2Fentry%2F2019%2F05%2F31%2F120602" title="Mercari Meetup for Microservices Platform #2 を開催しました - Mercari Engineering Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://tech.mercari.com/entry/2019/05/31/120602">tech.mercari.com</a></cite></p> muziyoshiz SRE Lounge のスピンオフで、議論中心の新しい勉強会 "SRE Session" への誘い hatenablog://entry/17680117127092829747 2019-04-29T23:07:54+09:00 2019-04-29T23:07:54+09:00 SRE Session とは? イベントレポート SRE Session のスタイル 事前アンケート グループ分け テーマごとのサイクル Welcome talk Discussion Sharing 懇親会 感想 時間の長さ グループ分け 議論のまとめ方 参加者の総数 SRE Lounge の Slack ワークスペースへのお誘い SRE Session とは? SRE Lounge のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。 sre-lounge.connpass.com SRE Session は少人数かつ全員参加型で議論するタイプの勉強会… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20180927/20180927232609.png" alt="f:id:muziyoshiz:20180927232609p:plain" title="f:id:muziyoshiz:20180927232609p:plain" class="hatena-fotolife" itemprop="image"></span></div> <ul class="table-of-contents"> <li><a href="#SRE-Session-とは">SRE Session とは?</a></li> <li><a href="#イベントレポート">イベントレポート</a></li> <li><a href="#SRE-Session-のスタイル">SRE Session のスタイル</a><ul> <li><a href="#事前アンケート">事前アンケート</a></li> <li><a href="#グループ分け">グループ分け</a></li> <li><a href="#テーマごとのサイクル">テーマごとのサイクル</a></li> <li><a href="#Welcome-talk">Welcome talk</a></li> <li><a href="#Discussion">Discussion</a></li> <li><a href="#Sharing">Sharing</a></li> <li><a href="#懇親会">懇親会</a></li> </ul> </li> <li><a href="#感想">感想</a><ul> <li><a href="#時間の長さ">時間の長さ</a></li> <li><a href="#グループ分け-1">グループ分け</a></li> <li><a href="#議論のまとめ方">議論のまとめ方</a></li> <li><a href="#参加者の総数">参加者の総数</a></li> </ul> </li> <li><a href="#SRE-Lounge-の-Slack-ワークスペースへのお誘い">SRE Lounge の Slack ワークスペースへのお誘い</a></li> </ul> <h2 id="SRE-Session-とは">SRE Session とは?</h2> <p><a href="https://sre-lounge.connpass.com/">SRE Lounge</a> のスピンオフで、SRE Session という勉強会の第1回が4月10日に開催されました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-lounge.connpass.com%2Fevent%2F123701%2F" title="SRE Session #1 (2019/04/10 19:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-lounge.connpass.com/event/123701/">sre-lounge.connpass.com</a></cite></p> <p>SRE Session は少人数かつ全員参加型で議論するタイプの勉強会です。当日は議論が盛り上がり、参加者の反応も良かったので、おそらく SRE Session #2 が6月頃に開催されそうです。そこで、だいぶ遅れましたけど(3週間近く経ってる……)軽く感想をメモしておきます。</p> <p>SRE Lounge には何度か参加していて、SRE Session にもちょっと興味あるけど参加しようかどうしようか……という方の参考になればと思います。</p> <h2 id="イベントレポート">イベントレポート</h2> <p>SRE Session #1 の内容については、すでに充実したレポートが書かれているので、こちらを読んでもらえると大体の雰囲気がわかると思います。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.chaspy.me%2Fentry%2F2019%2F04%2F15%2F120000" title="ディスカッション中心のイベントSRE Sessionを開催しました - ツナワタリマイライフ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://blog.chaspy.me/entry/2019/04/15/120000">blog.chaspy.me</a></cite></p> <p>SRE Session の発起人 <a href="https://twitter.com/chaspy_">@chaspy_</a> さんのレポート。Session #1 の会場は Quipper Ltd. さまに提供いただいたのですが、こちらも chaspy さんにお世話いただきました。感謝しかない……。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqrunch.net%2F%40ktykogm%2Fentries%2FFLv0w8Olg9GaZfWF" title="SRE Session #1というイベントを開催。MonitoringとSLOについて発表や議論が行われました。" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qrunch.net/@ktykogm/entries/FLv0w8Olg9GaZfWF">qrunch.net</a></cite></p> <p>いつも SRE Lounge でお世話になっているスタッフの <a href="https://twitter.com/ktykogm">ktykogm (k-oguma)</a> さんのレポート。Welcome talk の内容から、oguma さんが参加されたグループでの議論内容まで詳しくまとめてくださっています。</p> <h2 id="SRE-Session-のスタイル">SRE Session のスタイル</h2> <p>ここから先は、主に SRE Session という勉強会のスタイルの紹介と、それに対する僕の感想です。一応、今回スタッフとして参加したのですが、椅子運びくらいしかしていないので、一参加者の感想として読んでもらえれば。</p> <p>第1回はこういうスタイルでした(第2回以降で改善されて変わる可能性はあります)。</p> <h3 id="事前アンケート">事前アンケート</h3> <p>connpass での申込時に、今回のテーマ(SLO と Monitoring)に関するアンケートを取りました。</p> <ul> <li>SLOについて共有したい事例を記入してください</li> <li>SLOについてディスカッションしてみたいテーマを記入してください</li> <li>Monitoringについて共有したい事例を記入してください</li> <li>Monitoringについてディスカッションしてみたいテーマを記入してください</li> <li>その他この会に期待することを何でも教えてください</li> </ul> <p>このアンケート結果は、スタッフが匿名化したうえで、事前に参加者全員に共有していました。今回、本編ではほとんど使わなかったですが、懇親会での話題のネタになっていました。</p> <p>アンケートの記入は任意だったので、記入していたのは参加者の半分以下でした。ただ勉強会の性質上、議論のネタを持っている同士でないとつらいので、今後は記入必須になるかもです。</p> <h3 id="グループ分け">グループ分け</h3> <p>受付終了後に、いくつかのテーブルに散らばって座ってもらいました。</p> <p>人数が少ないと議論が盛り上がりづらいため、3名のグループになってしまったところは他のグループに合流してもらい、最終的に4〜5名のグループを作りました。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20190429/20190429230359.jpg" alt="f:id:muziyoshiz:20190429230359j:plain:w800" title="f:id:muziyoshiz:20190429230359j:plain:w800" class="hatena-fotolife" style="width:800px" itemprop="image"></span></div> <h3 id="テーマごとのサイクル">テーマごとのサイクル</h3> <p>SRE Session #1 は "SLO" と "Monitoring" の2テーマでした。このテーマごとに、以下の35分のサイクルを繰り返しました。</p> <ul> <li>Welcome talk 10分 <ul> <li>そのテーマに関する導入として、有識者の方のプレゼンを聞く</li> </ul> </li> <li>Discussion 20分 <ul> <li>軽く自己紹介をしてから、テーマについて思うことを話し合う</li> </ul> </li> <li>Sharing 5分 <ul> <li>各グループにマイクを回して、代表者1名が1〜2分で議論内容を紹介</li> </ul> </li> </ul> <h3 id="Welcome-talk">Welcome talk</h3> <p>今回の Welcome talk は、Yahoo の tsuka さんと、メルカリの <a href="https://twitter.com/spesnova">spesnova</a> さんが担当してくれました。いずれも、このテーマだけで30分くらい話を聞きたいくらいの濃い内容でした。</p> <iframe src="//www.slideshare.net/slideshow/embed_code/key/IIEru2wFQjO17A" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <p> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/TsukaMinoru/sre-session-1" title="SRE Session #1" target="_blank">SRE Session #1</a> </strong> from <strong><a href="https://www.slideshare.net/TsukaMinoru" target="_blank">Minoru Tsuka</a></strong> </div></p> <script async class="speakerdeck-embed" data-id="4e821394e0944266b07129dbde0bf09a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>こちらの welcome talk の詳しい内容について興味の湧いた方は、ぜひ上述のイベントレポートをご覧ください。</p> <h3 id="Discussion">Discussion</h3> <p>Welcome talk のあとは議論の時間。</p> <p>グループによって進め方はいろいろ違ったと思うのですが、僕たちのグループでは最初に自己紹介をしてから、welcome talk で出たキーワードを拾って、それぞれが興味あることを話した感じでした。</p> <p>ちなみに、参加者全員が SRE だったわけではなく、例えば僕たちのグループの内訳はこんな感じ。</p> <ul> <li>SRE 3名(自分含む) <ul> <li>ゲーム、アドテク、プロジェクト管理</li> </ul> </li> <li>バックエンド寄りの開発者 2名 <ul> <li>うち1名の会社は、これから SRE を作ろうとしている段階</li> </ul> </li> </ul> <p>一言で SRE と言っても、サービスの種類や規模や、その人の組織内での SRE の立ち位置など、いろいろ違うところがあるので自己紹介は重要そう。</p> <h3 id="Sharing">Sharing</h3> <p>最後に、司会が各グループにマイクを持って回って、グループの代表者が1〜2分で議論の内容を紹介しました。</p> <p>内容のまとめ方は今回特に指定されなかったので、ホワイトボードを使うグループ、SRE Lounge の Slack に書いていくグループ、各人が手元にメモしていくグループ(僕のグループはこれでした)などいろいろでした。</p> <h3 id="懇親会">懇親会</h3> <p>最後に、1時間ほど懇親会の時間がありました。</p> <p>議論中心のイベントだけあって懇親会で帰る人はほとんどおらず、テーマに沿って話が盛り上がったあとだったので、普段の勉強会以上に議論が盛り上がったのではないかと思います(※個人の感想です)。</p> <h2 id="感想">感想</h2> <p>普段、他社の SRE と深い議論をする機会ってあまり無いので、特定のテーマに沿ってじっくりと議論するのは楽しかったです。良い会だったと思います。</p> <p>なお、chaspy さんが <a href="https://blog.chaspy.me/entry/2019/04/15/120000">SRE Session のまとめ記事</a> に書いていますが、この会は Cloud Native Deep Dive というイベントのやり方にインスパイアされたものらしいです。今回の勉強会が楽しかったので、そちらにもいずれ参加してみたいです。</p> <p>以下、次回以降どうするともっと盛り上がるかな……と考えたことのメモです。</p> <h3 id="時間の長さ">時間の長さ</h3> <p>開催前は、2テーマは多すぎるのでは? 1テーマあたりの時間が短すぎないか?という議論もありました。</p> <p>ただ、結果としては20分で少し足りないかちょうどよいくらいで、むしろこの倍の40分だったら場が保たずに辛かったかな、と思いました。</p> <p>もう少し細かいテーマを設定すれば、もっと議論の時間が長くてもいいかもしれません。例えば、SLO のテーマであれば「組織内で SLO を決めるときに苦労していること」、「組織内で SLO をどのように、どれくらいの頻度で振り返るべきか」といったサブテーマをいくつか用意しておくとか……。</p> <h3 id="グループ分け-1">グループ分け</h3> <p>人数はこれくらいでよかったと思います。今回は5名上限でしたが、それ以上になると、1人あたりの話す時間が短くなりそうです。少なすぎても話に広がりがなくなるので、5〜6名がベスト?</p> <p>あとは、参加者全員が SRE というわけではなかった(事前アンケートでそこまで聞いていなかったので当日気づいた)ので、グループ内に SRE の数が少ないと、その人の話を聞くだけになりそうです。</p> <p>参加者が全員 SRE である必要はないと思いますけどね。個人的には、いずれ「SRE と開発者の関係」のようなテーマの回があってもいいんじゃないかと思っています。</p> <p>とはいえ SRE の比率はある程度必要だと思うので、申込時に、SRE only 枠と自由枠で、募集枠を分けるとかしたほうがいいんでしょうか? そのうえで、各グループで SRE の比率が偏らないようにするとか?</p> <h3 id="議論のまとめ方">議論のまとめ方</h3> <p>今回は特に指定がなかった部分ですが、これは事前に決めておいたほうがよかったかもしれません。</p> <p>全グループの分だけホワイトボードを用意できる会場は多くないと思うので、ポストイットのイーゼルパッドを用意しておくとか。</p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B00DE2V08W/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/41QxrwH4mFL._SL160_.jpg" class="hatena-asin-detail-image" alt="ポストイット イーゼルパッド 方眼入り 762×634mm 30枚x2冊セット EASEL 560" title="ポストイット イーゼルパッド 方眼入り 762×634mm 30枚x2冊セット EASEL 560"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/B00DE2V08W/muziyoshiz-22/">ポストイット イーゼルパッド 方眼入り 762×634mm 30枚x2冊セット EASEL 560</a></p><ul><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> スリーエム(3M)</li><li><span class="hatena-asin-detail-label">メディア:</span> オフィス用品</li><li><a href="http://d.hatena.ne.jp/asin/B00DE2V08W/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p>あるいは <a href="https://hackmd.io/">HackMD</a> や <a href="https://cacoo.com/">Cacoo</a> のような(手前味噌ですみません)、リアルタイムに共同編集ができるサービスを使うようにお願いしておくとか決めておくと良いかも。議論の内容が電子的にまとまっていると、イベントレポートで共有したり、振り返るのも楽になりますしね。</p> <h3 id="参加者の総数">参加者の総数</h3> <p>Sharing の時間は、元々5分の予定でしたが、実際は1グループあたり1分以上かかっていました。グループの数が多くなりすぎると、Sharing の時間が長くなってつらそうです。</p> <p>そう考えると、参加者の総数としては6名×6グループ=36名くらいがちょうどいいあたりでしょうか?</p> <p>参加者の総数をこれくらいに少なめに抑えておいたほうが、会場提供のハードルが下がっていいんじゃないか?と個人的には思っています。</p> <p>SRE Lounge のほうはすっかり人気イベントになって参加希望者が多くなり、この規模の会場を提供できる会社さんは少なくなってきています。ちなみに、次回5月29日の SRE Lounge #9 は、募集開始から1日で150名の枠が埋まってしまいました(すごい!!)。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-lounge.connpass.com%2Fevent%2F129214%2F" title="【増枠】SRE Lounge #9 (2019/05/29 19:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-lounge.connpass.com/event/129214/">sre-lounge.connpass.com</a></cite></p> <p>SRE Session のほうは、それよりもっと小さい会場を転々とできるといいなあと。30名程度なら、議論に使える小さめの会議室いくつかと、Sharing の時間だけ集まるセミナールーム1室くらいでギリギリ開催できそうですし。具体的には、うちの会社の東京事務所でもギリギリ開催できそうですし。</p> <h2 id="SRE-Lounge-の-Slack-ワークスペースへのお誘い">SRE Lounge の Slack ワークスペースへのお誘い</h2> <p>SRE Lounge は特定のスポンサーとか特に付いていない、コミュニティベースの勉強会です。</p> <p>イベント開催情報なども早めに展開されますので、もし SRE Session にご興味のある方はぜひ <a href="https://srelounge.slack.com/">srelounge.slack.com</a> にご参加ください! 特定のテーマで開催してほしい!もっとこういうスタイルで議論したい!という熱烈な希望があれば #sresession チャンネルでアピールしてもらえると採用されるかも?</p> muziyoshiz SRE Lounge #8 の感想(取り入れたいと思った活動の話を中心に) hatenablog://entry/17680117126994024915 2019-03-15T22:07:35+09:00 2019-03-15T22:07:35+09:00 今週の水曜に、クックパッド社にて SRE Lounge #8 が開催されました。今回も参考になるお話が多かったです。 ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド!という感じでした。 SRE Lounge会場、さすがクックパッドという感じ。キッチンがある! #srelounge pic.twitter.com/iut4EdeIJp— Masahiro Yoshizawa (@muziyoshiz) 2019年3月13日 ソラコムAPIの裏側で運用チームは何をやってきたのか SRE Lounge #8 | ソラコムAPIの裏側で運用チームは何をやってきたのか from SO… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20180927/20180927232609.png" alt="f:id:muziyoshiz:20180927232609p:plain" title="f:id:muziyoshiz:20180927232609p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>今週の水曜に、クックパッド社にて <a href="https://sre-lounge.connpass.com/event/122651/">SRE Lounge #8</a> が開催されました。今回も参考になるお話が多かったです。</p> <p>ちなみに、会場はキッチン付きの勉強会スペースで、さすがクックパッド!という感じでした。</p> <p><blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">SRE Lounge会場、さすがクックパッドという感じ。キッチンがある! <a href="https://twitter.com/hashtag/srelounge?src=hash&amp;ref_src=twsrc%5Etfw">#srelounge</a> <a href="https://t.co/iut4EdeIJp">pic.twitter.com/iut4EdeIJp</a></p>&mdash; Masahiro Yoshizawa (@muziyoshiz) <a href="https://twitter.com/muziyoshiz/status/1105777132448309249?ref_src=twsrc%5Etfw">2019年3月13日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> <h2>ソラコムAPIの裏側で運用チームは何をやってきたのか</h2> <iframe src="//www.slideshare.net/slideshow/embed_code/key/czAh1yORahhb4L" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <p> <div style="margin-bottom:5px"> <strong> <a href="//www.slideshare.net/SORACOM/sre-lounge-8-api" title="SRE Lounge #8 | ソラコムAPIの裏側で運用チームは何をやってきたのか" target="_blank">SRE Lounge #8 | ソラコムAPIの裏側で運用チームは何をやってきたのか</a> </strong> from <strong><a href="https://www.slideshare.net/SORACOM" target="_blank">SORACOM,INC</a></strong> </div></p> <p>SORACOM の OpsDev Manager 五十嵐さん(<a href="https://blog.soracom.jp/blog/2018/10/04/employee-report-opsdev-engineer/">インタビュー記事</a>)による発表。</p> <p>OpsDev というのは DevOps の書き間違いではありません。SORACOM では開発チームがメンテナンスと運用の両方に関わり、OpsDev チームは運用作業省力化のための開発をするチームとのことです。</p> <p>OpsDev チームが開発したロングセラーツールとして、以下のものが紹介されていました。</p> <ul> <li>緊急時のみ SSH 接続を許可するための設定自動化 <ul> <li>Slack に接続してきた開発者の IP アドレスを、Security Group に自動反映</li> <li>CodeCommit に登録された公開鍵の、EC2 インスタンスへの自動配布</li> <li>ログ取得(詳細は秘密でした)</li> </ul> </li> <li>PagerDuty に似た、電話での通知の仕組み <ul> <li>Slack で <code>/tel ニックネーム</code> とすると強制的に電話を鳴らす</li> </ul> </li> <li>実際の移動体通信を監視するためのラズパイのタワー(ソラコム・サグラダ・ファミリア)</li> </ul> <p>質疑応答の中で面白いと思ったのは、SORACOM の他の社員の方が「SORACOM ではエンジニアが開発、運用、サポートまで見るので、サポートが一人負けするようなシステムにはならない」と言っていたこと。開発と運用が一体なのは当たり前、という感じで、素直にうらやましいと思いました(個人的にはいつも悩んでいるところなので……)。ただ、基本的に開発者向けのサービスだからできる話かもしれません。</p> <p>「開発チームの中に開発担当と運用担当ができてしまうのでは?」という鋭い質問もありましたが、「まだ、両者を分けられるほどエンジニアの人数がいない。開発した人が一番早く直せるというポリシーでやっている」とのことでした。</p> <h2>Cookpad Microservice Architecture Overview</h2> <script async class="speakerdeck-embed" data-id="d97c147e7f924252ace887e0e768c777" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>クックパッドの技術部 SRE グループの吉川さん(<a href="https://twitter.com/rrreeeyyy">@rrreeeyyy</a>)による発表。</p> <p>2013年頃からマイクロサービス化に取り組んできて、一進一退しつつ進んできたという話でした。開発者との恊働の話がいくつか出てきました。</p> <p>例えば、今までは大統一 Terraform を作っていたが、これだと開発者にとってはプルリクを投げづらい。今後はチームごとにディレクトリを分けて、そのディレクトリ内の変更はチームの責任で実施できるようにしたいと思っている、など。</p> <p>各サービスのチームを巻き込んだ SLI/SLO の導入はまだこれからで、今後の課題とのことでした。</p> <p>最近、既存サービスのマイクロサービス化について悩んでいたので、懇親会でマイクロサービス化の良い進め方について相談しました。以下はそのときのメモです。</p> <ul> <li>モノリシックなサービスの一部をマイクロサービスとして切り出したいとしても、最初は新しいサービスでマイクロサービスの作り方を確立して、開発者自身が自信を付けてからにするのがいい</li> <li>データの切れ目でサービスを分割するといい。例えばクックパッドなら、レシピのデータとユーザのデータは別のもの(レシピの作成者としてユーザ ID が入る程度)なので、そこで分割するとか</li> <li>作業が SRE だけでほぼ完結するから、データベースの分割からやるのがやりやすいかもしれない。データベースをレプリケーションして、あるタイミングで writer をバタンと切り替える</li> </ul> <p>ちなみに、マイクロサービス化は開発者のほうがモチベーションが高く、運用側から説き伏せて、みたいなことは全然なかったそうです。</p> <h2>割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話</h2> <script async class="speakerdeck-embed" data-id="5520f90f0a534a15a5c8bdb535b56ce8" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>はてなの <a href="http://blog.hatena.ne.jp/hokkai7go/">id:hokkai7go</a> さんによる発表。プレゼン資料に加えて、以下のブログ記事で詳細が補足されていました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fblog.hokkai7go.jp%2Fentry%2Fsre-lounge8" title="割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話というタイトルでSRE Lounge #8に登壇します - 実はhokkai7go" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://blog.hokkai7go.jp/entry/sre-lounge8">blog.hokkai7go.jp</a></cite></p> <p>10名程度のはてな SREs(共通基盤)チームで実施中の活動で、以下のようにやっているそうです。</p> <ul> <li>割れ窓(技術的負債)を見つけたら issue を作成して記録</li> <li>取り組みやすそうな issue を「週刊割れ窓マガジン」という記事にリストアップ</li> <li>週に一度、1時間の作業時間を取る(2時間だとダレた。現在は1.5時間に伸ばす試みをしてる)</li> <li>振り返りやすいよう、終わった issue はスプレッドシートで一覧にしておく</li> </ul> <p>僕は勝手に、開発者も入ってる活動なのかな……と思いながら聞いてたのですが、SRE だけでやっている活動とのこと。最低でもチームの半分くらいは集まって実施するそうです。</p> <p>SRE の活動のなかで、SLO には現れないけど重要な、運用の品質とでも言うべきものはあると思っていて、最近こういうブログ記事を書いたりしてました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F02%2F25%2F235403" title="SRE はサービス品質に影響しない程度の異常をどう扱うべきか? - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/02/25/235403">muziyoshiz.hatenablog.com</a></cite></p> <p>はてなの他の取り組みで、PWG(Performance Working Group)という活動も以前聞いたことがあって、自社でも少し実施し始めています。この PWG と併せて、割れ窓タイムも導入してみたいと思いました。</p> <script async class="speakerdeck-embed" data-id="ab023b38fe274b19a566e4a9c0c6b7b3" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script> <h2>次回の SRE Lounge</h2> <p>次回は5月に、サイバーエージェントで開催予定とのことです。</p> <p>また、SRE Lounge とは違う、特定のテーマに沿ったディスカッションの場として「SRE Session」というイベントが新たに企画されています。初回は 4/10 で、テーマは SLO と Monitoring です。テーマに興味のある方はこちらも是非どうぞ。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-lounge.connpass.com%2Fevent%2F123701%2F" title="SRE Session #1 (2019/04/10 19:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-lounge.connpass.com/event/123701/">sre-lounge.connpass.com</a></cite></p> muziyoshiz SRE はサービス品質に影響しない程度の異常をどう扱うべきか? hatenablog://entry/17680117126980310009 2019-02-25T23:54:03+09:00 2019-02-26T07:01:52+09:00 今回の記事は、最近考えていたことのメモです。 ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。 障害と異常の定義 話の前に、障害(failure)および異常(anomaly)という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。 障害:サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント 異常:サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント この定義をもう少し詳しく説明するために、例として、ロードバラ… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20180927/20180927232609.png" alt="f:id:muziyoshiz:20180927232609p:plain" title="f:id:muziyoshiz:20180927232609p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>今回の記事は、最近考えていたことのメモです。</p> <p>ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。</p> <h2>障害と異常の定義</h2> <p>話の前に、<b>障害(failure)</b>および<b>異常(anomaly)</b>という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。</p> <ul> <li>障害:サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント</li> <li>異常:サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント</li> </ul> <p>この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。</p> <p>これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった(例えば10秒以上になった)場合は障害です。</p> <p>一方、サーバが1台だけダウンしたものの、ロードバランサのヘルスチェック機能によって、ダウンしたサーバは自動的に切り離されたとします。その結果、ユーザにはほとんどサーバダウンが気づかれなかったとしたら、それは異常です。</p> <h2>障害は計測しやすく、対応しやすい</h2> <p>障害は、その定義からして、明確なユーザ影響が出るため、測定しやすいです。</p> <p>SRE は、障害の発生度合いを表す<b>サービスレベル指標(SLI)</b>を定義します。例えば、サービスのダウンタイムであったり、リクエストの成功率、応答時間の95パーセンタイルなど。</p> <p>また、SLI を定義したら、最低限満たすべき SLI の目標値も設定します。例えば、サービスのダウンタイムは1ヶ月あたり3.6時間、など。その目標値は<b>サービスレベル目標(SLO)</b>と呼ばれます。</p> <p>SLO に限らず、目標値というものは「ここまで頑張らないといけない」高い目標を示すものですが、逆に言うと「ここまでは手を抜いてもいい」下限と考えることもできます。</p> <p>SLO を「開発・リリースの速度を上げるために、ここまでは手を抜いていいという下限」と捉えたものが、SRE 本で紹介されて有名になった<b>「エラーバジェット」</b>という考え方です。</p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873117917/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51Ybz%2B6kIsL._SL160_.jpg" class="hatena-asin-detail-image" alt="SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム" title="SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873117917/muziyoshiz-22/">SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> オライリージャパン</li><li><span class="hatena-asin-detail-label">発売日:</span> 2017/08/12</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/4873117917/muziyoshiz-22" target="_blank">この商品を含むブログ (1件) を見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p>障害は、もちろん良くないものですが、それだけに計測しやすいものです。また、エラーバジェットという考え方を導入することで、チームとしての対応を議論することができます。</p> <h2>異常は計測しにくい、対応しにくい</h2> <p>その一方で、異常はその種類が無数にあり、サービスへの影響度合いも分かりづらく、測定しにくいものです。</p> <p>上で挙げたアプリケーションサーバの例でいうと、例えばこういうものが異常です。</p> <ul> <li>OSやミドルウェアのメトリクスの異常な動き <ul> <li>例:サーバの CPU 利用率が、よくわからないタイミングで 100% まで急上昇する。ロードバランサからすぐ切り離されるから、エラーになるリクエスト数は少ない。</li> </ul> </li> <li>普段は出ないエラーログ、あるいは普段とは違うログ件数 <ul> <li>例:通常時は出ないログが、時々頻繁に出る。特定のユーザが入力を間違えたときに出るログのはずだが、なにかそれを引き起こす原因があるのかもしれない。</li> </ul> </li> <li>普段とは違うサービスの利用状況 <ul> <li>例:アクセス数が普段よりも急激に増えている。ユーザの繁忙期で一時的に増えているだけかもしれないが、今後もこのまま増え続けることを想定したシステム増強が必要かもしれない。</li> </ul> </li> </ul> <p>もちろんこれらを SLO に含めることもできます。</p> <p>とはいえ、SLO の数を増やしすぎると SRE にとってチェックしきれるものではなくなります。サービス影響に直結しないので、チームの方針を決めるためのエラーバジェットとしても説得力は得にくいでしょう。</p> <h2>異常の数が増えていくと、いずれ深刻な障害につながる(かも)</h2> <p>異常の原因調査に割く時間がないので、とりあえずサーバリソースを増やして時間稼ぎをする、という経験は自分にも何度かあります。</p> <p>あるいは、エラーバジェットを導入している現場なら「障害にまで発展してから、エラーバジェットの範囲内で対応したら?」と考える人もいるかもしれません。</p> <p>しかし、それぞれの異常がバラバラのタイミングで起きているときは良くても、それらの異常がいくつか同時に発生したタイミングで大きな障害につながる、という可能性を自分はどうしても心配してしまいます。例えば、サーバ1台が突然ダウンする問題があるなら、サーバ3台が同時にダウンすることもあり得るだろう、という心配です。</p> <p>そういう、サービス品質に影響しない程度の異常については、どう扱うべきなのでしょうか?</p> <p>あるいは、それが実態の伴わない不安だとして、なにか「エラーバジェット」のような仕組みでうまく解消できるものなのでしょうか?</p> <h2>もやもやと考えていること</h2> <p>最初に書いた通り、この疑問に対する結論はまだありません。ただ、現時点でなんとなく考えていることだけメモしておきます。</p> <p>メトリクスやログを見て回って、人手で異常を探すのは難しい……というか費用対効果が悪すぎて時間を割けません。なので、原因調査をすべき異常があったときだけ、何らかのアラートが欲しい。</p> <p>アラートを設定するにしても、</p> <ul> <li>何を監視すべきなのか</li> <li>閾値をどう設定すべきなのか</li> </ul> <p>という問題があります。これは異常検出(anomaly detection)や傾向分析(performance prediction)と呼ばれる技術の領域です。機械学習で、完全に設定ゼロで導入できたりしたら素晴らしいですが、そこまで実現できている現場ってあるんでしょうか……?</p> <p>ちなみに、「未知のログが一定数以上発生した場合だけ、日次でレポートを送信する」といった単純な異常検出であれば、ツールを自作すればできるのでいまの現場にも導入しています。実際に使ってみると、その程度でも意外と役に立つものです。ただ、やはり障害のアラートほど重要ではないので、忙しいときは無視されがちではあります。</p> <p>あるいは、異常が多いと感じるなら、それは異常の数よりも、ソフトウェアメトリクスやテストの量など、コードの品質の方を見たらいいんでしょうか。そういう、遠回りに感じるものの、障害・異常とは別の観点で見るべき話なんでしょうか?</p> <p>なにかもうちょっとまとまった話が書けそうになったら、そのうちまた書きます。</p> muziyoshiz 「入門 監視」を読みました hatenablog://entry/98012380852090848 2019-01-31T14:56:55+09:00 2019-01-31T14:56:55+09:00 入門 監視 ―モダンなモニタリングのためのデザインパターン作者: Mike Julian,松浦隼人出版社/メーカー: オライリージャパン発売日: 2019/01/17メディア: 単行本(ソフトカバー)この商品を含むブログを見る あまりにシンプルなタイトルで話題になっていた「入門 監視」を読みました。 プログラミング本で言うと「リーダブルコード」くらいの判型と厚さでサッと読めて、自分たちがやっている監視を見直すきっかけになる良書でした。 内容の簡単な紹介と、個人的な感想(というか読みながら考えたこと)をメモしておきます。 内容の簡単な紹介 本書は二部構成です。 前半(第I部「監視の原則」)では、… <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873118646/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/41Jlj3e0CDL._SL160_.jpg" class="hatena-asin-detail-image" alt="入門 監視 ―モダンなモニタリングのためのデザインパターン" title="入門 監視 ―モダンなモニタリングのためのデザインパターン"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873118646/muziyoshiz-22/">入門 監視 ―モダンなモニタリングのためのデザインパターン</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> Mike Julian,松浦隼人</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> オライリージャパン</li><li><span class="hatena-asin-detail-label">発売日:</span> 2019/01/17</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/4873118646/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p>あまりにシンプルなタイトルで話題になっていた「入門 監視」を読みました。</p> <p>プログラミング本で言うと<a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873115655/muziyoshiz-22/">「リーダブルコード」</a>くらいの判型と厚さでサッと読めて、自分たちがやっている監視を見直すきっかけになる良書でした。</p> <p>内容の簡単な紹介と、個人的な感想(というか読みながら考えたこと)をメモしておきます。</p> <h2>内容の簡単な紹介</h2> <p>本書は二部構成です。</p> <p>前半(第I部「監視の原則」)では、「監視」を考えるときに出てくる基本的な用語の解説と、監視でやりがちなアンチパターンとその逆(デザインパターン)が手短にまとめられています。メトリクス、ログ、インシデント管理といった基本的な用語から、中央値やパーセンタイルといった監視ツールでよく出てくる統計用語まで触れているので、いままで監視に関わっていないようなエンジニアでも読みやすいと思います。</p> <p>後半(第II部「監視戦略」)では、いくつかの章に分けて、具体的な監視項目と、そのために使える手段を解説しています。本書の良いところは「ユーザ視点での監視」の重要性が強調されているところで、章の並び順もそうなっています。</p> <ul> <li>ビジネスを監視する(5章) <ul> <li>ビジネス KPI(月次経常利益など)や、コア機能が利用される頻度など</li> </ul> </li> <li>フロントエンド監視(6章) <ul> <li>実際のユーザが見ているページのロード時間など</li> </ul> </li> <li>アプリケーション監視(7章) <ul> <li>アプリケーションのメトリクス・ログ、ヘルスチェック、分散トレーシング</li> </ul> </li> <li>サーバ監視(8章) <ul> <li>OS のメトリクス、SSL 証明書、Web、データベースなどなど</li> </ul> </li> <li>ネットワーク監視(9章) <ul> <li>SNMP の基本的な解説など</li> </ul> </li> <li>セキュリティ監視(10章) <ul> <li>コンプライアンス規制を満たしていることを監視で確認する例</li> </ul> </li> </ul> <p>本書では全体を通して、監視の SaaS サービスを活用することを推奨しています。本書の付録には <a href="https://mackerel.io/ja/">Mackerel</a> プロダクトマネージャの <a href="https://twitter.com/songmu">@songmu</a> さんによる「実践 監視 SaaS」がついていて、監視 SaaS を使ったことがない人向けのよい入門になっています。</p> <h2>感想</h2> <h3>ビジネスに関する監視をもっと増やしてみたくなる</h3> <p>ユーザ視点での監視が重要、というのは常識として理解しているつもりでしたが、本書でビジネス KPI の話が最初に来たのはちょっと驚きました。</p> <p>また、コア機能の利用頻度については、Yelpの例では「検索実行」「レビュー投稿」などの回数が監視対象に挙げられてました。ビジネス KPI はキャパシティプランニングにも直結するところなので、継続的に追うのは重要ですよね。</p> <p>いまの現場でも運用コストについてはある程度可視化されているのですが(参考:<a href="https://nulab-inc.com/ja/blog/backlog/analyze-aws-cost-by-redash/">re:dashでAWSのコストを分析してみた</a>)、ビジネスに関する監視をもっと増やしてみたくなりました。</p> <h3>クラウドサービス前提の話はほとんどない</h3> <p>本書全体を通して、AWS や GCP に関する話はほとんどありませんでした。監視の基本は変わらないから、あえて触れていないのだろうと思います。</p> <p>AWS などのクラウドサービスを使う場合、CloudWatch のようなビルトインの監視サービスが使えることと、ネットワークが抽象化されているので本書の「ネットワーク監視」の範囲はあまり関係ない、というくらいでしょうか。</p> <h3>分散トレーシングの監視は難しい</h3> <p>マイクロサービスと分散トレーシングについては、7章「アプリケーション監視」のなかに含まれていました。本書の著者は、分散トレーシングは非常に時間と労力がかかるので、他の手段で監視できるならそちらを用いるべき、というスタンスでした。</p> <blockquote><p>分散トレーシングは、正しく実装するのは非常に難しく時間がかかる監視の仕組みであり、業界内の一部でだけ役に立つものです。分散トレーシングは根気がない人や、スタッフ不足だったり過労気味のエンジニアリングチームには向いていません。必要なメトリクスやログはすべて取得していて、それでも分散システムにおけるサービス間のパフォーマンスを把握したりトラブルシューティングをするのに困るようなら、分散トレーシングを使うべきかもしれません。(p.106)</p></blockquote> <p>確かに、Zipkin を導入するためのコスト(監視システム側の構築・運用の複雑化に加えて、アプリケーション開発者での配慮も必要になる)が、そこから得られるメリットに見合うかどうかは、場合によるだろうなあと思います……。</p> <h3>監視システムの開発・維持は本書の対象外</h3> <p>本書を読んでいると監視を改善するアイディアはいろいろ浮かびますが、一度監視項目を設定しても、サービスを開発・運用していると状況は色々変わって、実態に合わなくなるものです。この監視の仕組み、システムをどう開発・維持するかは本書の対象外で、そこから先に興味を持ったら DevOps や SRE の本に移るのが良さそうです。</p> <p>ともあれ、いろいろ考え直すきっかけになる良書でした。</p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873118646/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/41Jlj3e0CDL._SL160_.jpg" class="hatena-asin-detail-image" alt="入門 監視 ―モダンなモニタリングのためのデザインパターン" title="入門 監視 ―モダンなモニタリングのためのデザインパターン"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4873118646/muziyoshiz-22/">入門 監視 ―モダンなモニタリングのためのデザインパターン</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> Mike Julian,松浦隼人</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> オライリージャパン</li><li><span class="hatena-asin-detail-label">発売日:</span> 2019/01/17</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/4873118646/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> muziyoshiz SRE Advent Calendar 2018 の個人的おすすめ記事(おまけ:Mackerel Drink Up の話) hatenablog://entry/10257846132691939440 2018-12-29T16:24:20+09:00 2018-12-29T22:26:45+09:00 12月は色々ありました。今回はそのへんを雑多に振り返る記事です。 SRE Advent Calendar 2018 の個人的おすすめ記事 SRE Advent Calendar 2018 は、スタディストのかつひささんが企画したアドベントカレンダーです。1個目のカレンダーがすぐ埋まってしまったので、2個目(SRE 2 Advent Calendar 2018)も作られてました。僕も11日目に投稿しました。 qiita.com qiita.com 1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。 冬休みに入ったので、この機会に SRE A… <p>12月は色々ありました。今回はそのへんを雑多に振り返る記事です。</p> <h2>SRE Advent Calendar 2018 の個人的おすすめ記事</h2> <p>SRE Advent Calendar 2018 は、スタディストの<a href="https://twitter.com/katsuhisa__">かつひささん</a>が企画したアドベントカレンダーです。1個目のカレンダーがすぐ埋まってしまったので、2個目(SRE 2 Advent Calendar 2018)も作られてました。僕も11日目に投稿しました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2018%2Fsre" title="SRE Advent Calendar 2018 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2018/sre">qiita.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2018%2Fsre2" title="SRE 2 Advent Calendar 2018 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2018/sre2">qiita.com</a></cite></p> <p>1個目の方はみんなきっちり執筆して25日埋まってましたし、どちらも内容の濃い記事が多くてすごかったですね。</p> <p>冬休みに入ったので、この機会に SRE Advent Calendar の記事を全部読み返して、個人的おすすめ記事をピックアップしてみました。どれも面白かったのですが、個人的にはいま SRE の組織体制に興味があるので、主にそのへんの記事に偏ってます。ご了承ください。</p> <h3>Day 10: DevOps文化の組織にSRE活動を導入した話</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fkusuwada.hatenablog.com%2Fentry%2F2018%2F12%2F10%2F012055" title="DevOps文化の組織にSRE活動を導入した話 - 好奇心の足跡" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://kusuwada.hatenablog.com/entry/2018/12/10/012055">kusuwada.hatenablog.com</a></cite></p> <p>(記事を読み限りおそらく)過去5年かそれ以上の間に、</p> <ul> <li>開発チームとインフラチームが分離していた体制</li> <li>各開発チームにインフラメンバーを送り込む体制(DevOps 体制)</li> <li>インフラメンバーを組織横断で繋ぐSREを導入した体制(SRE 体制)</li> </ul> <p>と組織体制を見直してきた現場での、それぞれの体制のメリット・デメリットをまとめた記事です。</p> <p>最新の体制は、SRE チームと開発チームを兼務する SRE と、SRE チーム兼任の SRE(Core メンバー)を組み合わせたもののようです。これは是非参考にしたいと思いました。</p> <h3>Day 14: プロダクト横断のSREチームを組成したい話</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fmshibuya%2Fitems%2F479af3acadf8f6590068" title="プロダクト横断のSREチームを組成したい話 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/mshibuya/items/479af3acadf8f6590068">qiita.com</a></cite></p> <p>オプトの<a href="https://twitter.com/m4buya">渋谷さん</a>による記事。</p> <p>渋谷さんは SRE Lounge #5 で SRE チーム立ち上げについての話をされてました。この記事は、その今後の展開についての話で、SRE が複数のプロダクトチームを横断して活動するように変えていきたいという構想についてのものです。</p> <p>記事の最後の方にある「乗り越えるべき壁」のところは、僕もよくわかる悩みで……特に、プロダクトをまたぐことで「一人のSREが知るべき内容はすごく多岐に渡ってしまいそう」という点は、実際やってみた結果を是非お聞きしたいです。</p> <p>ちなみに、</p> <blockquote><p>SREのマトリックス的な配置については<a href="https://speakerdeck.com/nulabinc/sre-lounge-number-5?slide=31">ヌーラボさんの取り組み</a>を参考にしています</p></blockquote> <p>とのことで、参考にしてもらえて嬉しい!</p> <h3>Day 16: SLO設定/超過監視にまつわる活動の振り返り</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.m3tech.blog%2Fentry%2F2018%2F12%2F16%2F120000" title="SLO設定/超過監視にまつわる活動の振り返り - エムスリーテックブログ" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.m3tech.blog/entry/2018/12/16/120000">www.m3tech.blog</a></cite></p> <p>エムスリーテックブログの記事。SLI の測定方法から、SLO 超過時のプロセスまで、具体的なユースケースが詳細にまとめられた良記事です。</p> <p>SLO を超過したかどうかの検知から、超過した場合のチケット作成まで自動化されており、これから SLO を導入しようという人は必読かと思います。あと、<a href="https://github.com/Yelp/elastalert">elastalert</a>(Elasticsearch にクエリ投げて結果によって通知するツール)については僕も知らなかったので、今度使ってみます……。</p> <h3>Day 4 (SRE 2): データ基盤をHadoopからBigQueryに移管するときのアンチパターン</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fyuzutas0.hatenablog.com%2Fentry%2F2018%2F12%2F04%2F190000" title="データ基盤をHadoopからBigQueryに移管するときのアンチパターン - 下町柚子黄昏記 by @yuzutas0" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://yuzutas0.hatenablog.com/entry/2018/12/04/190000">yuzutas0.hatenablog.com</a></cite></p> <p>Hadoop のようなデータ基盤を持つサービスで、SRE が果たすべき役割に関する記事です。</p> <p>この記事では、データを処理するフローの途中で組織が分かれていたために、データの欠損や不整合が発生してしまった自社事例を紹介しています。</p> <p>各組織が「自分の見える範囲で手っ取り早く済ませよう」とした結果、そうなってしまったようです。ソフトウェア開発じゃなくて、データ基盤の開発でも「コンウェイの法則」が出てくることあるんですね……。</p> <p>最終的に、このような問題を解決するには「プロダクト」と「分析」の間を取り持つ DataOps ロールが必要で、そのロールはシステム全体を最適化する部隊(つまり SRE)が担うべきと結論づけています。</p> <h3>Day 24: SRE風のインフラエンジニアにならないために</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fkenjiszk.hatenablog.com%2Fentry%2F2018%2F12%2F24%2F175116" title="SRE風のインフラエンジニアにならないために - Work Records" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://kenjiszk.hatenablog.com/entry/2018/12/24/175116">kenjiszk.hatenablog.com</a></cite></p> <p>はてブでバズってた記事。<strong>SREがどういうものかを知ってほしいときには、まずこのページを読んでもらおう!</strong>と思ったくらい、説明が必要十分で読みやすい記事でした。</p> <p>ちなみに、この記事の分類に従うと、僕の今年の仕事は「インフラエンジニアではなくSREとしてどう高速リリースを実現するか」のところにずっと注力してました。CI の改善、リリースプロセスやリリース自動化ツールの改善、開発チームが監視に使えるツールの充実などなど……。</p> <h3>Day 25: [SRE Advent Calendar] SRE Advent Calendar 2018 を終えて</h3> <p><iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fkths.hatenablog.com%2Fentry%2F2018%2F12%2F25%2F212609" title=" [SRE Advent Calendar] SRE Advent Calendar 2018 を終えて - かつひささんの日記" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://kths.hatenablog.com/entry/2018/12/25/212609">kths.hatenablog.com</a></cite></p> <p>企画者のかつひささんによるまとめ記事です。SRE Advent Calendar の全記事に一言コメントが付けられています。興味のある記事だけ読みたい人は、まずはここをざーっと読むのがいいかも。</p> <p>ちなみに、この記事の最後に「@katsuhisa__的ベスト3」のコーナーがあって、そこで僕の書いた記事を1位に選んでくれていました。まったく予想してなかったのでびっくりしましたが、頑張って書いた甲斐がありました。ありがとうございます。</p> <blockquote><p>ヌーラボSREの吉澤さんのこちらの記事が、SRE Advent Calendar 2018 の@katsuhisa__ 的1位でした。</p> <p>SREの文脈では、一般的に、SLI といえば、レイテンシやエラーレートを指すことが多いですが、この記事では、自社のチームの課題に焦点を当て、社内向けSLI を整備した話が書かれています。</p> <p>私が登壇する資料では、度々「ウェブオペレーションは、技芸であり、科学ではない」( by 『ウェブオペレーション ―サイト運用管理の実践テクニック』 )という言葉を引用しますが、まさにこの記事の事例には、一種の技芸を感じました。</p> <p>また、それ以外にもSREと組織構造にも詳しく触れられていて、今後も何回も読み返したくなるような内容でした。</p></blockquote> <h2>SRE Advent Calendar 2018 に投稿した記事</h2> <p>で、この流れで僕が投稿した記事も紹介。SRE Advent Calendar 11日目の記事として、Backlog プロジェクトにて SRE メンバを中心に試してきたサービスレベル指標と、それぞれについて感じたメリット・デメリットをまとめました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab-inc.com%2Fja%2Fblog%2Fbacklog%2Fbacklog-sre-service-level-management%2F" title="サービス品質向上のためにBacklogのSREが行ってきたサービスレベル管理の取り組み | ヌーラボ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://nulab-inc.com/ja/blog/backlog/backlog-sre-service-level-management/">nulab-inc.com</a></cite></p> <p>9月の <a href="https://sre-lounge.connpass.com/event/99389/">SRE Lounge #5</a> の講演では時間の都合で話せなかったネタがあって、年内にアウトプットするならこれがラストチャンスだ!と思って飛びついて、なんとか書き上げられました。結果的には、発表時間が1時間あっても足りなそうなくらいに分量が膨らみましたね……。</p> <p>あまりにも泥臭すぎる内容だし、人によっては「この会社はレベルが低い」と思うのではないか……と思って、公開前には色々悩んで書いたり消したりしました。それでも最終的に公開したのは、<strong>SRE について考えるときには組織の話は外せないし、その具体的なケーススタディの価値は高い</strong>、と思うからでした。</p> <p>SRE の組織体制は、この記事に書いたものが最終形ではなくて、来年以降も徐々に改善していくことになりそうです。半年〜1年後には、また新たな話ができると思います。</p> <h2>おまけ:Mackerel Drink Up の LT 発表</h2> <p>あと、この記事の公開日にちょうど <a href="https://mackerelio.connpass.com/event/106805/">Mackerel Drink Up #8 Tokyo</a> というイベントがあり、Backlog での Mackerel 利用事例について発表しました。Advent Calendar の記事中にちらっと出てくる監視システムについて、もう少し詳しく話しています。</p> <script async class="speakerdeck-embed" data-id="1f95815eb02948afacd64af6355db33b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>ゆううきさんが東京に来るということで講演を聞いて、色々お話もできてよかったんですが、その数日後に<a href="https://blog.yuuk.io/entry/2018/leaving-hatena">退職ブログ</a>が出てびっくりしました。</p> <p>ゆううきさんが話していたことで、印象的だったのはこのあたりでした。</p> <ul> <li>書籍「Webオペレーション」には、運用は技芸で科学ではない、という趣旨の文がある。しかし、個人的にはむしろ、技芸から科学へ進んでいると思ってる。一例として、reliability engineeringという分野が生まれてきている。</li> <li>チーム内に SRE がいると、Dev と Ops のトレードオフを取りやすい。チームが分かれているとそこがやりにくくなる(=変更速度が下がる)のでは。同じチームに SRE がいることで、開発者と SRE の間で、お互いに業務を融通できるようになった。</li> <li>メルカリのアドベントカレンダーの記事にも、1つのチーム内で開発と運用に責任を持つという話があった(<a href="https://tech.mercari.com/entry/2018/12/01/200159">マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog</a>)。いまのトレンドはその方向なのかも。</li> </ul> <p>個人的に考えている SRE のあるべき姿と、ゆううきさんの話が近かったので、その点は勇気づけられました。運用が科学に進んでいる、という点は、僕はあまりそうは思わないのですが、そうであったら面白い、とも思うので、ゆううきさんの今後の活躍に注目したいと思います。</p> muziyoshiz 艦これアーケードイベント全5回分の攻略率・周回数の時系列データ(CSV)を公開しました hatenablog://entry/10257846132677133913 2018-11-29T21:29:22+09:00 2018-11-29T21:29:22+09:00 Admiral Stats とは? 僕は2016年9月から2年以上、艦これアーケードのプレイデータ管理ツール Admiral Stats を開発・運用しています。Twitter アカウントと、艦これアーケードをプレイ済みの SEGA ID を持っている人なら、誰でも使えるサービスです。 www.admiral-stats.com このサービスを作った経緯などに興味のある方は、Admiral Stats カテゴリー から過去のブログ記事をどうぞ。 艦これアーケードの期間限定海域とその攻略率 この2年以上の間に、期間限定海域(約1〜2ヶ月だけプレイできる特別なステージ)が5回リリースされており、そ… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20170128/20170128164643.png" alt="f:id:muziyoshiz:20170128164643p:plain" title="f:id:muziyoshiz:20170128164643p:plain" class="hatena-fotolife" itemprop="image"></span></div> <h3>Admiral Stats とは?</h3> <p>僕は2016年9月から2年以上、艦これアーケードのプレイデータ管理ツール Admiral Stats を開発・運用しています。Twitter アカウントと、艦これアーケードをプレイ済みの SEGA ID を持っている人なら、誰でも使えるサービスです。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.admiral-stats.com%2F" title="艦これアーケードのプレイデータ管理ツール" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.admiral-stats.com/">www.admiral-stats.com</a></cite></p> <p>このサービスを作った経緯などに興味のある方は、<a href="https://muziyoshiz.hatenablog.com/archive/category/Admiral%20Stats">Admiral Stats カテゴリー</a> から過去のブログ記事をどうぞ。</p> <h3>艦これアーケードの期間限定海域とその攻略率</h3> <p>この2年以上の間に、期間限定海域(約1〜2ヶ月だけプレイできる特別なステージ)が5回リリースされており、その5回すべてのプレイデータも溜まっています。各難易度の最終的な攻略率は、Admiral Stats 上で誰でも見られるようにしています。</p> <p>例えば、これは最新の第5回イベントの攻略率です。最高難易度(甲)をクリアしたプレイヤー(提督)は、全体のうち49.6%いるというのがわかります。</p> <p><a href="https://www.admiral-stats.com/global/event/5/2">イベント攻略率(AL作戦/MI作戦 Extra Operation)</a></p> <p>過去5回のイベントすべての、「甲」難易度の攻略率だけ並べるとこんな感じ。</p> <table> <thead> <tr> <th> イベント名 </th> <th> 前段作戦 </th> <th> 後段作戦 </th> <th> Extra Operation </th> <th> 備考 </th> </tr> </thead> <tbody> <tr> <td> 第1回「敵艦隊前線泊地殴り込み」 </td> <td> 56.3 % </td> <td> - </td> <td> - </td> <td> これは乙の攻略率(第1回は丙・乙のみ、作戦の区分なし) </td> </tr> <tr> <td> 第2回「南方海域強襲偵察!」</td> <td> 57.9 % </td> <td> 57.5 % </td> <td> - </td> <td> 第2回は前段・後段のみ </td> </tr> <tr> <td> 第3回「索敵機、発艦始め!」</td> <td> 72.4 % </td> <td> 72.1 % </td> <td> - </td> <td> 第3回は前段・後段のみ </td> </tr> <tr> <td> 第4回「決戦!鉄底海峡を抜けて!」 </td> <td> 71.8 % </td> <td> 62.0 % </td> <td> 56.1 % </td> <td> </td> </tr> <tr> <td> 第5回「AL作戦/MI作戦」 </td> <td> 66.9 % </td> <td> 65.7 % </td> <td> 49.6 % </td> <td> </td> </tr> </tbody> </table> <p>ここから難易度の傾向がある程度わかります。例えば、第4回イベントは後半になればなるほど難しくなっている、第2〜3回と第5回イベントは前段と後段の難易度がほぼ同じらしい、等々。</p> <p>SEGA 公式はこういうデータを公開していないので、(Admiral Stats という特殊なツールを使ってくれるヘビーユーザーに偏っている可能性が高いとはいえ)貴重なデータです。</p> <h3>イベント期間中の攻略率・周回数の時系列データを公開しました</h3> <p>こんな感じで、イベント終了時の最終的な攻略率は、<a href="https://www.admiral-stats.com/global/event">Admiral Stats のイベント攻略率ページ</a> 上で誰でも見られる状態にしていました。</p> <p>ただ、この攻略率が、時間経過とともにどういう感じで上がってるかは公開してませんでした。例えば、最終的な攻略率が同じ60%でも、</p> <ul> <li>最初の1週間で攻略率が60%になって、イベント終了までそのまま横ばい</li> <li>最初の1週間で攻略率40%、そこからじわじわと攻略率が上がって終了時に60%</li> </ul> <p>では、後者のほうが難易度が高かったと言えそうですよね。</p> <p>Admiral Stats 上でそういうグラフを見られるようにしようかと思ったんですが、そこまで実装する時間がなかなか取れなかったのと、どういう切り口でグラフを書いたら面白いか思いつきませんでした。</p> <p>なので、今回、イベント攻略率・周回数に関する統計情報を CSV ファイルとして公開しました。ぜひ自由にいろいろ集計して、面白い結果が出たら Twitter やブログで紹介してください!</p> <p><script src="https://gist.github.com/muziyoshiz/2c3efbc88518d5ba4a2a3e3beb1caa23.js"> </script><cite class="hatena-citation"><a href="https://gist.github.com/muziyoshiz/2c3efbc88518d5ba4a2a3e3beb1caa23">gist.github.com</a></cite></p> <p>なお、イベント開始から、Admiral Stats での対応までに時間がかかったために、最初の数日間のデータが欠けているイベントもあります。そのへんは非公式ツールの限界ということでご容赦ください。</p> <p>この CSV ファイル内の統計値の詳しい計算方法が気になる方は、こちらのコード(↓)をどうぞ。</p> <p><a href="https://github.com/muziyoshiz/admiral_stats/blob/master/app/batches/event_stats_export_batch.rb">CSV ファイル作成バッチのソースコード</a></p> <h3>具体例:この CSV ファイルからこういうグラフを描けます</h3> <p>Admiral Stats にプレイデータを登録した人の数は、イベント開始時から終了時に向けて徐々に増えていきます。このプレイデータ登録者数と、攻略率の推移を比べてみましょう。</p> <p>第1回イベントで、プレイデータ登録者数と、乙難易度(第1回での最高難易度)の攻略率を比べるとこうなります。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181129/20181129211937.png" alt="f:id:muziyoshiz:20181129211937p:plain" title="f:id:muziyoshiz:20181129211937p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>一方、最新の第5回イベントで、プレイデータ登録者数と、甲難易度の攻略率を比べたものはこちら。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181129/20181129211959.png" alt="f:id:muziyoshiz:20181129211959p:plain" title="f:id:muziyoshiz:20181129211959p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>この棒グラフの傾きが緩やかだと、クリアまでに時間がかかった提督が多い、つまり難易度が高いと言えそうです。そう考えると、</p> <ul> <li>第1回イベントは開始1週間程度で最終的な攻略率まで上がったので、難易度が低かったかも?</li> <li>第5回イベントはEOが一番簡単で前段が一番難しかったのかも?</li> </ul> <p>といったことがわかります。そこから掘り下げて、でも第5回イベントでEOの最終的な攻略率が49.6 %と低かったのはなぜ…?とか考察していくと面白そうです。</p> <p>この CSV ファイルには、1回クリアした提督が、同じ難易度を周回した回数のデータも入っています。攻略率に加えて、周回数でもグラフを描いてみると面白い結果が出ると思います。ぜひお試しください!</p> muziyoshiz ボルダリングジム Rocky がリリースした新アプリ「サテライトロッキー」がすごい! hatenablog://entry/10257846132660354470 2018-10-27T22:17:53+09:00 2019-10-27T10:22:44+09:00 去年の8月に同僚から誘われてボルダリングを始めて、いまは週2でジムに行くくらいハマっています。具体的に言うと、無意識にこんなこと言い出してしまうくらいハマってます。 最近、ボルダリングをすると筋肉痛になり、筋肉痛が治るまで暇だからその間に仕事してる感がある— Masahiro Yoshizawa (@muziyoshiz) September 12, 2018 一応IT業界の人間なので、ボルダリングをもっと楽しむのに使えるサービスやアプリって無いのかな……と色々探してるんですが、意外といいのがありません。 そんな中、今月の10日に「Rocky」というボルダリングジムが、「サテライトロッキー」と… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027214926.png" alt="f:id:muziyoshiz:20181027214926p:plain" title="f:id:muziyoshiz:20181027214926p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>去年の8月に同僚から誘われてボルダリングを始めて、いまは週2でジムに行くくらいハマっています。具体的に言うと、無意識にこんなこと言い出してしまうくらいハマってます。</p> <p><blockquote class="twitter-tweet" data-lang="HASH(0x55e4a1505d00)"><p lang="ja" dir="ltr">最近、ボルダリングをすると筋肉痛になり、筋肉痛が治るまで暇だからその間に仕事してる感がある</p>&mdash; Masahiro Yoshizawa (@muziyoshiz) <a href="https://twitter.com/muziyoshiz/status/1039877021562621952?ref_src=twsrc%5Etfw">September 12, 2018</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> <p>一応IT業界の人間なので、ボルダリングをもっと楽しむのに使えるサービスやアプリって無いのかな……と色々探してるんですが、意外といいのがありません。</p> <p>そんな中、今月の10日に<a href="https://www.rockyclimbing.com/">「Rocky」</a>というボルダリングジムが、<a href="https://www.rockyclimbing.com/2018/09/20/satelliterocky-news/">「サテライトロッキー」</a>というアプリをリリースしました。このアプリはとても良くできていて、今後ボルダリングジムがこぞって提供し始めるような、デファクトになる可能性を秘めていると思います。</p> <p>そこで今回は、ボルダリングにハマるとどういうサービスやアプリが欲しくなるかと、その観点から見て「サテライトロッキー」がどれくらいイケてるアプリなのか、をご紹介します。</p> <h2>ボルダリングとは?</h2> <p>ボルダリングを知らない人向けに、話の前提として簡単に説明します。</p> <p>ボルダリングは、高さ5m前後の壁(屋内)や岩(屋外)を、予め決められたスタート地点からゴール地点まで登って、達成感を味わうスポーツです。細かいルールは色々ありますが、基本はそれだけのシンプルなスポーツです。</p> <p>実際に体験してもらわないと面白さを伝えるのは難しいので、とりあえず1回、経験者と一緒にジムに行ってやってみてください。僕の知り合いの人なら、呼んでもらえればホイホイついていくのでぜひ行きましょう。</p> <h2>ボルダリングにハマると欲しくなるもの</h2> <p>ボルダリングにハマると、「もっと難易度の高い課題(※ボルダリング用語でコースのこと)を登りたい」と思う一方で、「最近あまりうまくなってない気がする」という壁にもぶつかるものです。</p> <p>そうなると、だいたい以下の2つのニーズが出てきます。</p> <ul> <li>うまい人がどうやってるのか知りたい</li> <li>自分の成長を記録したい</li> </ul> <p>「サテライトロッキー」が出る以前に、いままで僕がどういうことを試してきたかを、一例として書いていきます。</p> <h3>うまい人がどうやってるのか知りたい</h3> <p>まずはちゃんと知識を得たい、ということで本を読み漁りました。自分で買ったり、会社の同僚(ボル部の部長)から借りたりして読んだなかで、特に参考になったのはこのあたり。</p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635160157/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/515yCnNueEL._SL160_.jpg" class="hatena-asin-detail-image" alt="インドア・ボルダリング練習帖 (RS Books)" title="インドア・ボルダリング練習帖 (RS Books)"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635160157/muziyoshiz-22/">インドア・ボルダリング練習帖 (RS Books)</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> 『ROCK&SNOW』編集部</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> 山と渓谷社</li><li><span class="hatena-asin-detail-label">発売日:</span> 2014/02/22</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/4635160157/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635160203/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51z4MitqrzL._SL160_.jpg" class="hatena-asin-detail-image" alt="完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版" title="完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635160203/muziyoshiz-22/">完全図解 スポーツクライミング教本 すべてのクライマー必読の教科書決定版</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> 東秀磯</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> 山と渓谷社</li><li><span class="hatena-asin-detail-label">発売日:</span> 2017/05/26</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/4635160203/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635168077/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51EZWJGJAQL._SL160_.jpg" class="hatena-asin-detail-image" alt="パフォーマンス・ロック・クライミング" title="パフォーマンス・ロック・クライミング"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4635168077/muziyoshiz-22/">パフォーマンス・ロック・クライミング</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> デイルゴダード,ウドノイマン,Dale Goddard,Udo Neumann,森尾直康</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> 山と溪谷社</li><li><span class="hatena-asin-detail-label">発売日:</span> 1999/04/01</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本</li><li><span class="hatena-asin-detail-label">購入</span>: 2人 <span class="hatena-asin-detail-label">クリック</span>: 8回</li><li><a href="http://d.hatena.ne.jp/asin/4635168077/muziyoshiz-22" target="_blank">この商品を含むブログ (4件) を見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p><div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/463516022X/muziyoshiz-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51cJpOlRcmL._SL160_.jpg" class="hatena-asin-detail-image" alt="Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!" title="Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!"></a><div class="hatena-asin-detail-info"><p class="hatena-asin-detail-title"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/463516022X/muziyoshiz-22/">Jack中根のクライミング道場 目からウロコが50枚 もっとうまくなるための50のTIPS!</a></p><ul><li><span class="hatena-asin-detail-label">作者:</span> 中根穂高(ジャック中根),江崎善晴</li><li><span class="hatena-asin-detail-label">出版社/メーカー:</span> 山と渓谷社</li><li><span class="hatena-asin-detail-label">発売日:</span> 2018/01/11</li><li><span class="hatena-asin-detail-label">メディア:</span> 単行本(ソフトカバー)</li><li><a href="http://d.hatena.ne.jp/asin/463516022X/muziyoshiz-22" target="_blank">この商品を含むブログを見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div></p> <p>しかし、関連書籍はあまり多くないですし、一通り読み終わると「用語は覚えたけど、どういうときにどのムーブを使えばいいのかよくわからない」という状態になりました。</p> <p>ブログやウェブサイトも探したのですが、初心者の役に立つようなものは山と溪谷社の <a href="https://www.climbing-net.com/">CLIMBING-net</a> くらい。じゃあ動画を、と思って YouTube で「ボルダリング 解説」などで検索しても、意外とあまり動画がありません。</p> <p>ボルダリング関係のちょっと変わった動画サイトとして、<a href="https://onlineobservation.com/">OnlineObservation</a> というサイトがあります。このサイトは、課題を3Dモデルで確認した上で、クリア動画も見られるのですが、作るのが手間だからか、動画数が少ないのが難点です。</p> <p>最終的に「これは良い」と思ったのは、<strong>自分が行ったジムの名前で YouTube や Instagram を検索して、自分が登れなかった課題を登ってる動画を探す</strong> という方法でした。これなら、自分が一度トライしているのでどういう課題かわかるし、自分が登れなかった部分に絞って何回も再生したりできて、勉強になります。</p> <p>自分がよく行くジムに行っているユーザーの YouTube チャンネルをチャンネル登録したり、Instagram でフォローするのも良いと思います。おかげで、最近は YouTube と Instagram がすっかりクライミング動画アプリになってしまいました……。</p> <h3>自分の成長を記録したい</h3> <p>うちの会社と1つ上の階の会社のメンバで「ボル部」を作って、毎週水曜に3〜5名でボルダリングジムに行ってます。お互いに動画を撮って Google Photo のアルバムで共有しているので、それが成長記録みたいな感じになっています。</p> <p>ただ、そんなに常にお互いの動画を撮ってられないし(そんなことより登りたいし)、細かい成長度合いはよくわかりません。</p> <p>そこで、最近になって自分のトレーニング内容を日誌に記録し始めました。これは書籍(「パフォーマンスロッククライミング」や「Jack中根のクライミング道場」)で推奨されていた方法です。主に以下のようなことを書いています。</p> <ul> <li>挑戦した課題の難易度や、その数</li> <li>完登した課題数</li> <li>フラッシュした(1回で完登した)課題数</li> <li>その日の体の調子</li> </ul> <p>こういうのを記録する良いアプリがあればよかったんですが、結局普通の手帳に書いてます。</p> <h2>アプリ「サテライトロッキー」の機能とイケてるところ</h2> <p>そこで、今回の「サテライトロッキー」です。</p> <p><blockquote class="twitter-tweet" data-lang="HASH(0x55e4a1505d00)"><p lang="ja" dir="ltr">【SatelliteRocky】<br>ジムアプリ「サテライトロッキー」を2018/10/10にiOS版、アンドロイド版同時リリースします。<br><br>構想から開発、完成まで2年。<br>ロッキーのすべてがこのアプリにあり、ジムの楽しさを倍増させていきます!!<br><br>主要機能をホームページにアップしました↓↓↓<a href="https://t.co/GVG1g55TIE">https://t.co/GVG1g55TIE</a> <a href="https://t.co/fcEVZGz4jT">pic.twitter.com/fcEVZGz4jT</a></p>&mdash; Rockyボルダリングジム (@rockyclimbing) <a href="https://twitter.com/rockyclimbing/status/1042644376768339968?ref_src=twsrc%5Etfw">September 20, 2018</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> <p>「構想から開発、完成まで2年」と宣言するだけのことはある、よくできたアプリになっています。正直に言うと、アプリとしての使い勝手にはまだ改善の余地が多いのですが、Rocky というボルダリングジムのシステムと非常によく噛み合ってます。</p> <p>公式サイトにも説明はあるのですが、僕の注目するポイントからも機能紹介します。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.rockyclimbing.com%2F2018%2F09%2F20%2Fsatelliterocky-news%2F" title="アプリ「サテライトロッキー」10/10リリース" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.rockyclimbing.com/2018/09/20/satelliterocky-news/">www.rockyclimbing.com</a></cite></p> <h3>機能1. 完登した課題を記録して、あとから写真込みで確認できる</h3> <p>ロッキーの店舗でサテライトロッキーを起動すると、自分が完登した課題を登録できる「チャレンジモード」に入れます。店舗にいるかは GPS で判定されます。このチャレンジモードで登録した結果は、あとからいつでもアプリで確認できます。</p> <p>会員証代わりにアプリを提供しているボルダリングジムはたまにありますが、まずこんな記録機能自体がいままでに無いものです。ロッキーは、サテライトロッキーの提供以前から、すべての課題に対して、難易度順に一意な番号を振っています。そのシステムが元からあるからこそできる。これは結構すごいことです。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027215553.jpg" alt="f:id:muziyoshiz:20181027215553j:plain:w640" title="f:id:muziyoshiz:20181027215553j:plain:w640" class="hatena-fotolife" style="width:640px" itemprop="image"></span></div> <p>それに加えて、完登した際に、それがフラッシュかどうかも記録できます(フラッシュの場合はカミナリのアイコンが表示されます)。フラッシュかどうかをクライマーは重視するので、そのあたりわかってる人がアプリ開発してるの良いですね。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027220030.jpg" alt="f:id:muziyoshiz:20181027220030j:plain:w320" title="f:id:muziyoshiz:20181027220030j:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <p>さらに、ここから課題番号を選ぶと、なんとその課題の写真も見られます。いままでは気になる課題を自分で撮影したりしてましたけど、その手間もなくなるなんて……。この画像の用意はさぞかし大変だろうと思いますが、ここまで徹底すると他のジムには簡単に真似できない価値になってます。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027220059.jpg" alt="f:id:muziyoshiz:20181027220059j:plain:w320" title="f:id:muziyoshiz:20181027220059j:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <h3>機能2. 全来店者でのランキングを確認できる</h3> <p>先ほど書いた通り、ロッキーではすべての課題に対して、難易度順に一意な番号を振っています。自分が完登した課題の上位10個の合計値でランキングを競う「集大成」というシステムがあり、ランキングの集計結果が約2ヶ月に1回公開されています。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.rockyclimbing.com%2Fsyutaiseiresult%2F" title="集大成リザルト一覧" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.rockyclimbing.com/syutaiseiresult/">www.rockyclimbing.com</a></cite></p> <p>これと同じシステムがサテライトロッキーにも実装されています。違うのは、ランキングの集計が1日1回に変わったこと。</p> <p>いままでは2ヶ月に1回の更新だったので、他のクライマーとのポイント差を意識するようなことはあまりありませんでした。しかし、頻度が上がったことで、自分と近いレベルの人(例えばよく一緒にジムに行ってる友達)との接戦を楽しんだりできそうです。</p> <p>これは、アプリで新たに実装した機能というよりは、もともとロッキーというジムに存在していたシステムをアプリに導入したものです。この機能も、他のジムが真似しようとしたら、ジムのシステムから見直す必要があり、容易ではなさそうです。</p> <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027220748.jpg" alt="f:id:muziyoshiz:20181027220748j:plain:w320" title="f:id:muziyoshiz:20181027220748j:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <h3>機能3. 他のクライマーをフレンド登録して、フレンドのチャレンジ結果も確認できる</h3> <p>最後に、このサテライトロッキーには SNS のようなフレンド機能があります。現状では、フレンド(フォローした相手)の完登記録を確認したり、次の来店予定日を共有できたりするようです。</p> <p>サテライトロッキーの開発側は、グレードの高いクライマーをみんながフォローするようになり、グレードが上がるほどフォロワーが増えてモチベーションが上がる、といったことを考えているのかもしれません。</p> <p>僕のような普通のクライマーにとっては現状ではフォロワーとフォロイーを一覧できる程度ですが、この機能も、発展させていけばかなり面白くなるんじゃないかと思っています。</p> <div class="images-row mceNonEditable"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027221254.jpg" alt="f:id:muziyoshiz:20181027221254j:plain:w320" title="f:id:muziyoshiz:20181027221254j:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027221305.jpg" alt="f:id:muziyoshiz:20181027221305j:plain:w320" title="f:id:muziyoshiz:20181027221305j:plain:w320" class="hatena-fotolife" style="width:320px" itemprop="image"></span></div> <h2>サテライトロッキーへの要望いろいろ</h2> <p>そんな感じで非常に良いサテライトロッキーなんですが、もっとこうだったら、という点もいくつかあります。</p> <h3>要望1. 挑戦したけど完登できなかった、という記録も残せるようにしてほしい</h3> <p>サテライトロッキーは「自分の成長を記録したい」というニーズをかなり満たしてくれているのですが、現時点では「挑戦したけど駄目だった」記録は残すことはできません。</p> <p>ロッキーには半年以上通っていますが、3回目かの来店でやっと完登できた課題や、2ヶ月以内に完登できずに壁を張り替えられてしまった課題なんかもありました。そのときの課題も、記録に残しておいてあとから見返せるとちょっと嬉しいです。</p> <h3>要望2. 課題から Youtube, Instagram 動画へのリンクを張れるようにしてほしい</h3> <p>上記のように記録機能は充実している一方で、「うまい人がどうやってるのか知りたい」というニーズはまだあまり満たしてくれません。</p> <p>せっかく他のクライマーの完登記録を見る機能があるので、そこから一歩進んで「この課題の完登動画」へのリンクを登録できるようにしてほしいです。例えば、自分が完登した課題を選択したら、そこから Instagram に完登動画を登録できる、とか。</p> <p>課題と動画を紐付けられれば、課題のページにその課題の完登動画をリストアップできるようになります。そうしたら、クリアできない課題があったらサテライトロッキーを開いて完登動画を見て再チャレンジ……ってことがその場ですぐできるはず。</p> <p>あと、現在でもプロフィールに Instagram アカウントへのリンクを設定できるようになってますが、YouTube チャンネルへのリンクも設定できるといいんじゃないでしょうか。</p> <h3>要望3. フォロー関係を使って各種 SNS に投稿された動画を通知してほしい</h3> <p>要望2の延長で、もしフレンドが完登動画を登録したら、それを通知してもらえると嬉しいです。</p> <p>今でも Instagram アカウントでフレンドを直接フォローしてしまえば、もちろん動画は見られます。ただ、Instagram にはクライミング関係以外にもいろいろ投稿するのが普通なので、クライミング動画を見たいときはサテライトロッキーを見る、という感じで使い分けられるといいんじゃないでしょうか。</p> <h2>まとめ</h2> <p>サテライトロッキーは、「自分の成長を記録したい」というクライマーのニーズを満たしてくれるアプリです。また、フレンド機能が今後発展していくと、「うまい人がどうやってるのか知りたい」というニーズまで満たしてくれる可能性も持っています。</p> <p>この記事を読んでちょっとでも興味をもってくれたら、ぜひ以下の公式サイトからサテライトロッキーをインストールしてみてください。そして一緒にボルダリングしましょう!(ダイレクトな勧誘)</p> <div class="center"><a href="https://www.rockyclimbing.com/2018/09/20/satelliterocky-news/"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20181027/20181027222256.png"></a></div> <h2>2019-10-27追記</h2> <p>サテライトロッキーのアップデート版「Satellite v2.0」に関する記事はこちら。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2019%2F10%2F27%2F100521" title="「サテライトロッキー」の新バージョン「Satellite V2.0」が B-PUMP などのジムにも多数対応し、ムービーの共有機能も追加! - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2019/10/27/100521">muziyoshiz.hatenablog.com</a></cite></p> muziyoshiz SRE Lounge #5 にて Backlog における SRE の事例について講演しました hatenablog://entry/10257846132640626149 2018-09-27T23:41:49+09:00 2018-12-13T09:35:35+09:00 僕は去年の8月にヌーラボに入社して、そこから Backlog の SRE として働いています。 SRE としての経験は約1年なのですが、ちょうどサービスが成長し、会社もエンジニアを積極的に採用して拡大している時期だったこともあり、色々な経験ができました。そのなかで、SRE の難しさ、SRE の組織の問題にも直面してきました。 このあたりの経緯を整理して話すだけでも SRE にとって面白い話になるのではないか、と思い、今回の SRE Lounge #5 では「Backlog における SRE の事例 〜プロダクトの成長のために SRE はなにをすべきか〜」というタイトルで発表させていただきました… <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20180927/20180927232609.png" alt="f:id:muziyoshiz:20180927232609p:plain" title="f:id:muziyoshiz:20180927232609p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>僕は去年の8月にヌーラボに入社して、そこから Backlog の SRE として働いています。</p> <p>SRE としての経験は約1年なのですが、ちょうどサービスが成長し、会社もエンジニアを積極的に採用して拡大している時期だったこともあり、色々な経験ができました。そのなかで、SRE の難しさ、SRE の組織の問題にも直面してきました。</p> <p>このあたりの経緯を整理して話すだけでも SRE にとって面白い話になるのではないか、と思い、今回の SRE Lounge #5 では「Backlog における SRE の事例 〜プロダクトの成長のために SRE はなにをすべきか〜」というタイトルで発表させていただきました。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fsre-lounge.connpass.com%2Fevent%2F99389%2F" title="SRE Lounge #5 (2018/09/26 19:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://sre-lounge.connpass.com/event/99389/">sre-lounge.connpass.com</a></cite></p> <p>発表スライドはこちらです。</p> <script async class="speakerdeck-embed" data-id="029f41f30c92426c97c0461e10351568" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>発表のときは冒頭で説明したのですが、<strong>これがベストプラクティスと言うつもりは全然ありません</strong>。僕らもまだ悩んでいる最中の問題を、その背景も含めて(話せる範囲で)丁寧にまとめて説明することで、他社の SRE の方々からご意見をいただきたい……という趣旨の発表でした。</p> <p>その後の質疑応答や、Twitter での反響を見た限り、とても好評だったようでホッとしています。「SREの業務範囲は放っておくと再現なく広がっていく」、「SRE を組織の中でどう配置すべきかはすごく難しい」といった問題意識は多くの方に同意してもらえたようです。</p> <p>詳しくはスライドの方を見てもらうとして、以下に当日の質疑応答や、懇親会で話したこと、今回のプレゼンの関連資料などをまとめておきます。</p> <h3>質疑応答</h3> <p>覚えている範囲でまとめておきます。発表直後でかなりテンパっていたので、質問者の質問や、僕の回答の表現は、実際に話されたものとは多少ズレているかもしれません。</p> <ul> <li>Q) 開発チームはスクラムなどに従って開発していると思うが、SRE の仕事はその開発スパンには合わないのではないか。そこはどうしているか <ul> <li>A) 開発者と SRE で同じカンバンは共有しているが、SRE は独立して動いている。障害対応があるときはそれを優先し、それ以外のときは改善のタスクを取るとか</li> </ul> </li> <li>Q) SRE が開発チームに入ることで良くなる面があったのはわかった。逆に、SRE が入ることで悪くなった面はあるか? <ul> <li>A) 開発者の側としては割り込みが増えたと感じているかもしれない。エスカレーションが早くなる分、「調べたけど問題なかった」というハズレも増える</li> </ul> </li> <li>Q) チームは拠点ごとに分かれているか? このチームは福岡に全員いる、など <ul> <li>A) ヌーラボはリモートでのコラボレーションを促進するサービスを提供していることもあり、複数拠点に分かれたチームはたくさんある。自分もそう。ただ、1拠点にまとまったチームもある</li> </ul> </li> <li>Q) Backlog の開発者の規模はどれくらいで、そのうち SRE は何名いるか <ul> <li>A) 開発者は30名前後と考えてもらえれば。SRE は講演でも話したとおり、現時点では4名</li> </ul> </li> <li>Q) SRE を採用するときに重視している点はあるか <ul> <li>A) 個人的には、技術力が高いこと、自分から問題を定義して仕事を作れること、チームをまたいで仕事をする必要があるのでそういうコミュニケーションを嫌がらないこと、の3点を重視している</li> </ul> </li> </ul> <h3>懇親会で話したこと、質問を受けたこと</h3> <p>お話できたのは一部の方だけでしたが、SRE やインフラエンジニアが多い印象を受けました。ターゲットに沿った人がうまく集まっていて、<strong>SRE Lounge は SRE にとって良い議論・発表の場</strong>だと思いました。</p> <p>オプトの渋谷さんの発表に対する質疑応答でも出ていた質問ですが、SRE は何人いたらいいのか? 開発者に対する割合としてどれくらい必要なのか? という質問は何度か受けました。北野さんがツイートしてましたけど、答えはまさにこれ(↓)ですね。何人必要かは、自分たちもまだ模索中です。</p> <p><blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">SRE 何人いたらいいの問題…w<br>職責をどう定義するかでも全然異なってきそう。<br> <a href="https://twitter.com/hashtag/srelounge?src=hash&amp;ref_src=twsrc%5Etfw">#srelounge</a></p>&mdash; かつひささん (@katsuhisa__) <a href="https://twitter.com/katsuhisa__/status/1044909168509865985?ref_src=twsrc%5Etfw">2018年9月26日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p> <p>あとは、これから新しく SRE チームを作るとしたら何に注意すべきか、という相談も受けました。SRE という用語を生み出した Google 自身もそうですが、自社でサービスを開発・運用している組織でないと、SRE に適切なインセンティブをもたせることは難しいのではないか……というくらいしかわからないですね。僕も答えは持ってませんが、SRE チームをうまく構築するスキルをもったコンサルのニーズは高そうだなあと思いました。スクラムマスターとか技術顧問みたいな感じで。</p> <h3>関連資料</h3> <p>スライドの中で触れた、Backlog SRE による過去の発表資料、ブログ記事はこちらです。</p> <p><iframe id="talk_frame_414383" src="//speakerdeck.com/player/3dadb5a270044ad4b2db64d870d81aee" width="710" height="501" style="border:0; padding:0; margin:0; background:transparent;" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe><cite class="hatena-citation"><a href="https://speakerdeck.com/nulabinc/operational-monitoring-of-backlog">speakerdeck.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab-inc.com%2Fja%2Fblog%2Fbacklog%2Fanalyze-aws-cost-by-redash%2F" title="re:dashでAWSのコストを分析してみた | ヌーラボ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://nulab-inc.com/ja/blog/backlog/analyze-aws-cost-by-redash/">nulab-inc.com</a></cite></p> <h3>この発表内容がまとまるまでの経緯</h3> <p>スタディスト(ヌーラボ東京事務所の1つ上のフロア)の北野さんから講演のお誘いを受けて、SRE について考え直すいい機会かな、と思ってとりあえずOKしたところから始まりました。</p> <p>そこから、まずは入社時に聞いた SRE チームの歴史のメモからたたき台を作り、週一の SRE チーム定例で毎回レビューをお願いして、発表内容をブラッシュアップしていきました。そのおかげで発表内容がよくなっただけでなく、SRE チーム内で過去の経緯を共有したり、今後のあるべき姿を考えるいい機会にもなりました。</p> <p>他の会社の SRE チームでも、同じように過去の経緯をまとめてみる(そして SRE Lounge で発表する)のはいいんじゃないかなーと思います。オススメです。</p> <p>最後に、SRE Lounge 運営の皆さん、今回の会場をご提供くださったウォンテッドリー株式会社の皆さんに感謝します。僕も今後できるだけ SRE Lounge をお手伝いしたいと思います。また会場でお会いしましょう。</p> <h3>あわせて読みたい(2018-12-13追記)</h3> <p>この講演のときに時間不足で省いたサービスレベル管理の話を、ヌーラボブログに大ボリュームでまとめました。よかったらこちらもどうぞ。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnulab-inc.com%2Fja%2Fblog%2Fbacklog%2Fbacklog-sre-service-level-management%2F" title="サービス品質向上のためにBacklogのSREが行ってきたサービスレベル管理の取り組み | ヌーラボ" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://nulab-inc.com/ja/blog/backlog/backlog-sre-service-level-management/">nulab-inc.com</a></cite></p> muziyoshiz kintone devcamp 2018 にて AWS Lambda を使ったサービス間連携についてのハンズオンセッションを行いました hatenablog://entry/10257846132616941902 2018-08-30T21:54:15+09:00 2018-08-30T21:58:08+09:00 8/2(木) に開催された kintone devCamp 2018 にて、kintone と Backlog を API 連携させる方法についてのハンズオンセッションを実施しました。サイボウズの方から企画の提案があって、(資料を作りながら自分でも)手を動かしてみる良い機会と思い、引き受けさせていただきました。 kintone & Backlogハンズオン 〜利用シーンに応じたタスク管理ツールの使い分けをAPIで実現〜 目次はこんな感じ。90分のハンズオンセッションでした。 Backlogとは? Backlogとkintoneの連携 Backlog APIによるサービス間連携 ハンズオン1. … <div class="center"><span itemscope itemtype="http://schema.org/Photograph"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/muziyoshiz/20180630/20180630010936.png" alt="f:id:muziyoshiz:20180630010936p:plain" title="f:id:muziyoshiz:20180630010936p:plain" class="hatena-fotolife" itemprop="image"></span></div> <p>8/2(木) に開催された <a href="https://developer.cybozu.io/hc/ja/articles/360001062323-kintone-devCamp-2018">kintone devCamp 2018</a> にて、kintone と Backlog を API 連携させる方法についてのハンズオンセッションを実施しました。サイボウズの方から企画の提案があって、(資料を作りながら自分でも)手を動かしてみる良い機会と思い、引き受けさせていただきました。</p> <p><a href="https://speakerdeck.com/nulabinc/kintone-devcamp-2018-handson">kintone &amp; Backlogハンズオン 〜利用シーンに応じたタスク管理ツールの使い分けをAPIで実現〜</a></p> <script async class="speakerdeck-embed" data-id="4697db202d974338b637e07267901c2a" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script> <p>目次はこんな感じ。90分のハンズオンセッションでした。</p> <ul> <li>Backlogとは?</li> <li>Backlogとkintoneの連携</li> <li>Backlog APIによるサービス間連携</li> <li>ハンズオン1. ノンプログラミングでの連携</li> <li>AWS LambdaとFunction as a Service</li> <li>ハンズオン2. AWSのサービスを用いた高度な連携</li> </ul> <p>このハンズオンセッションは2部構成で、前半は kintone プラグインを使ったノンプログラミングでの連携。後半は AWS Lambda と Amazon API Gateway を使った連携でした。後半はスライドの p.94 からです。AWS Lambda だけ興味のある方は、そこから見てもらえれば。</p> <p>スライドにはかなり細かく手順を書きましたし、ソースコードも GitHub で公開しているので、AWS Lambda を一度使ってみたい!という方は是非お試しください。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fnulab%2Fbacklog-kintone-handson" title="nulab/backlog-kintone-handson" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/nulab/backlog-kintone-handson">github.com</a></cite></p> <p>ちなみに、ハンズオン当日は、前半のハンズオンは7〜8割の参加者が設定完了して動かすことができたのですが、前半で時間を使いすぎて、後半はかなり駆け足で解説だけして終わってしまいました。それでも、後ほど頂いたアンケート結果で、8割近くが満足度「普通」以上の回答で一安心しました。</p> <p>資料を作り始める前は、90分あれば余裕と思ってたんですが、実際に手を動かしてもらうハンズオンは時間調整が難しいですね……。次の機会があったらもう少し工夫します。</p> <h2>あわせて読みたい</h2> <p>最近書いた以下の記事は、このハンズオンの準備中に調べたことのまとめです。ハンズオンを触ってみる際は、こちらもあわせてご覧ください。</p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F06%2F30%2F083957" title="Webhook の受信を契機として複数の API を叩く Lambda 関数を Node.js で書きたいときのためのメモ - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/06/30/083957">muziyoshiz.hatenablog.com</a></cite></p> <p><iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmuziyoshiz.hatenablog.com%2Fentry%2F2018%2F07%2F29%2F113028" title="Amazon API Gateway で API (Webhook) の呼び出し元 IP アドレスを制限する - 無印吉澤" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://muziyoshiz.hatenablog.com/entry/2018/07/29/113028">muziyoshiz.hatenablog.com</a></cite></p> muziyoshiz