YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

トップ > Book

「SREの探求」という本が出版されました #seekingsre

SRE Book

はじめに

こんにちは、Cloud Operations担当者です。このたび私が監訳者として関わった「SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

SREの探求 ―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践

Amazon

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

TL;DR

「SREの探求」はGoogle以外の企業でSREの導入がどのように行われているのかを記したエッセイ集です。スタートアップからエンタープライズまで、多くの事例を楽しみながら読める一冊だと思います。ボリュームに圧倒されるかもしれませんが、短編集なのでどの章からでも気軽に読み始められます。ぜひご一読ください。

「SREの探求」のおすすめの読み方

SRE本と同様、非常に分量がある書籍になっていますので圧倒されがちですが、本書は一つの技術に関しての入門やハンズオンを行う類の書籍ではありません。本書の執筆に参加した各社のSREが自らの経験を語ったエッセイ集です。したがって、まずは面白そうだと思う章を読んでみる、というのが良いかと思います。どの章から読んでも構わないと思いますし、読む順番も順不同で構わないと思います。一応、下記にあるように、大まかに4部構成になっていて、各部にある章は関連性が高いものになっているので、読む対象を選ぶときの参考になると思います。

本書を読むに当たって、副読本として同じくオライリーより出版されている「SRE サイトリライアビリティエンジニアリング（以下、SRE本）」が手元にあるとより読みやすいかもしれません。もちろんすでにSRE本を読まれていて内容をある程度把握されている方は必要ないと思いますが、他のSRE関連書籍を読んだことがない、という方は各章に登場するSRE関連用語がわからない可能性があります。Google SREのサイトで原著を無料で閲覧可能になっていますが、日本語の資料があったほうが読みやすいという方はぜひご用意ください。

「SREの探求」はどのような本か

本書はDavid N. Blank-Edelmanが編集し2018年9月に出版された "Seeking SRE" の日本語訳書籍です。

Seeking SRE: Conversations About Running Production Systems at Scale (English Edition)

Seeking SRE: Conversations About Running Production Systems at Scale (English Edition)

Amazon

この本は、すでに同じくオライリー・ジャパンより刊行されているSRE本、「サイトリライアビリティワークブック（以下、ワークブック）」「データベースリライアビリティエンジニアリング」に続くSRE関連日本語訳書籍の第4弾となります。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Amazon

サイトリライアビリティワークブック ―SREの実践方法

サイトリライアビリティワークブック ―SREの実践方法

Amazon

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

データベースリライアビリティエンジニアリング ―回復力のあるデータベースシステムの設計と運用

Amazon

本書は、GoogleだけでなくSREを実践している（しようとしている）多くの企業がその経験を様々な観点から語り、それらを4部に分けて編纂したエッセイ集です。私はこれまで、業務上あるいはコミュニティ関連のイベント等で多くのエンジニアや経営層の皆様と関わる中で、SRE（サイトリライアビリティエンジニアリング）の導入について質問をいただいたときに私が社内のSREの方々から学んだ知見を共有してきました。多くの方々が異口同音にその価値に共感しつつも、その実践となるとハードルがあり、難しいと感じている様子を目にしてきました。

私自身は他社へSREの導入の支援を直接行ったことはない*1ので、実際に各社がどのように導入を行ってきたかは各社の公開情報を断片的に集めてきて学んできました。そうした公開情報はブログ記事であったり、カンファレンスの録画やスライドだったりするのですが、まとまった形で参照できる書籍は本書が出るまでは存在しませんでした。私が2018年にGoogle Cloudのチームへ異動しオブザーバビリティの担当をすることになってからそうした情報を活発に調べるようになったのですが、ちょうど異動した直後に本書が発刊され、これは福音と手に取ったのでした。目次に並ぶ社名を見たあと、実際に各社がSREの導入を試行錯誤した様子を見て、共感をするとともに、苦労が偲ばれました。SREの導入には銀の弾丸は無いと改めて確認するとともに、Google以外でももちろんSREは実践できるのだと、あらためて確信できようになる、そんな一冊でした。

第1部はよく耳にする「SREの導入」についてです。たとえば第6章や第7章ではSoundCloud社がProdEngチームを組織するにいたるまでの経緯、そしてSpotifyでのOps-in-Squadsの内容が詳細に語られていますが、その経験は多くの企業、特にスタートアップ企業に当てはまるのではないかと思います。彼らは専任のSREチームなしでSREを実践してきているわけですが、この例はまさに「SREというタイトルやチームがSREを実践する」ということではなく、会社全体としてその実践を行うことが大事であるということが伺いしれます。また逆に第8章や第10章では大企業でのSREの導入について語られています。これらの章は想像通り鮮やかな解決方法などはありません。特に大企業で発生する組織の問題をどう乗り越えていくのか、という点について生々しい経験を見ることができます。

第2部は「SRE本」や「ワークブック」で触れきれなかったSRE関連の各種手法についての紹介です。カオスエンジニアリング、セキュリティ、データベースリライアビリティなど、「SRE本」「ワークブック」以降に出版された各種書籍につながる内容になっているので、まずはここで概要を抑えてから、必要に応じてそれぞれをテーマとした専門書籍を読むと読みやすいことと思います。*2

第3部はSREにおけるソフトスキルとアーキテクチャーの紹介をしています。個人的には重要なソフトスキルであるドキュメントに関する19章は技術書の中ではなかなか語られないドキュメントの重要性を知れる章です。また23章のアンチパターン集も軽快に読め、気晴らしに読むにはもってこいの章です。

第4部は見過ごしてはならない文化的な側面です。SREに寄った文章にはなっていますが、SREのみならず組織全般に言えるような文化的側面についての考察が広くカバーされています。心理的安全性やバーンアウト（燃え尽き）、はてはソーシャルアクティビズムとの関連性など、広く「人間の組織活動」における懸念事項などを深く突っ込んでいます。心理的にネガティブになるような事象はできる限り起きてほしくないのは常だと思いますし、なかなかソーシャルアクティビズムについてこの文脈で書かれた文章は少ないと思うので、そうした経験を書籍で知れることは意義があると感じます。重い話もありますが、おすすめです。

読んでいただければわかるとおり、どの章も「正解」というわけではなく、現組織が試行錯誤の末にたどり着いた最適解であるということがわかります。それと同時にどの章においてもSRE本やワークブックで何度も語られているような、ユーザーに対する信頼性を獲得するための手法や組織作りを行うことに尽力していることが読み取れると思います。こうした経験の共有が読者の皆さまのヒントになることを期待してやみません。

謝辞

監訳者まえがきでも触れさせていただきましたが、あらためて編集者のオライリー・ジャパンの高恵子さん、翻訳者の渡邉了介さんに感謝いたします。

高さんには全体の進行をしっかりと管理いただき、また私と渡邉さんのコミュニケーションが円滑になるように様々な配慮をいただきました。本書の翻訳原稿はすべて各章ごとにGoogle Docsでいただき、その上に私が「提案」の形でコメントを追加し、それを渡邉さんに再度確認してもらい、良ければ承認、認識のズレがある場合には追加でコメントをいただくという形のワークフローを用意していただきました。会社で日常的にこの形式でドキュメントのレビューを行っているため、私としては大変進めやすかったです。

翻訳者の渡邉さんにはただただ感謝するばかりです。600ページ超の本、しかもエッセイが中心でコードや図表が少なく、かつ技術要素が多い書籍の翻訳を、入念な下調べとともにすばらしい品質で行っていただきました。おかげで私が監修する際にはどこに着目すればよいかが分かりやすく、私の負担が大きく軽減されました。また英語そのもののニュアンスが読み取りづらかった文章も文化的背景から調べていただいた上でいくつかの訳の候補を提案いただいたりと、多くの配慮をいただきました。結局コロナ禍にあって、プロジェクト進行中は直接お会いすることは叶わず、またスケジュールの都合等でビデオ会議もできなかった中で、これほどまでスムーズに共同作業ができたのは、渡邉さんの柔軟性と配慮のおかげだと思います。またこうした機会がいただけるのであれば、ぜひご一緒させていただきたいです。

読者の感想など

レビューエントリー

（更新予定）私の方で確認次第随時追加していきます

blog.hiroakis.net

note.com

e34.fm #7で取り上げていただきました！1:04:00頃から @deeeet さん、@rrreeeyyy さんの注目の章の紹介があります。

e34.fm

speakerdeck.com

ツイート

その他

良い香りがするそうです。

しない場合もあります

*1:ところで、Google CloudではCREやPSOといった組織がSREの導入支援を行っていますので、ご興味あればご連絡ください。

*2:セキュリティに関してはBuilding Secure & Reliable Systemsがありますし、データベースリライアビリティについては先に上げた書籍があります。

「サクッとわかるビジネス教養 地政学」読了

Book

はじめに

こんにちは、Google Cloud Operations担当者です。最近はGoogle Cloud Profilerのワークショップを行っているので、アプリケーションのパフォーマンス改善に課題を感じている企業の方、Goのpprofをより積極的に使っていきたいという方はぜひお気軽にTwitterなどでご連絡ください。

さて、図書館に行ったらたまたま新刊で次の本が置いてあったので、軽く読めそうということで読んでみました。

サクッとわかる ビジネス教養 　地政学

サクッとわかる ビジネス教養 　地政学

  • 発売日: 2020/06/16
  • メディア: Kindle版

政治・経済の「物理装置」としての地政学

実は地政学を地政学としてきちんと情報を得たことはなく、高校までに習った地理の知識やその後の国際ニュースの情報などから、だいたいの雰囲気で断片的に知っていたという状態でした。いままで現代史を捉えるときに、その歴史的背景や周辺地域の資源ぐらいしか気にしていなかったのですが、それだけでは理解しづらい部分というのがありました。しかし、あらためて本書で触りだけでも地政学の概要を知ると、各国の地政学における特徴を理解するとともにその戦略的な観点が見えやすくなり、実際にいま現在起きているナゴルノ・カラバフ紛争やシリア内戦などへの理解がより深まりました。

本書の冒頭にも記載がありますが、現代起きている様々な事象をドラマの最新話と捉えるのであれば、地政学や地理はその舞台、そして歴史が過去回ということになります。自分は中高のときに地理が好きだったのですが、それは特定の視点からの地理でしかなく、たとえばこの国は農産が盛んであの国は鉄鋼業が盛んだとかいったものや、この国は輸出国だとか、あくまで産業や気候の状態を「覚える」だけのもので、政治的な戦略と結びつかない形での理解でした。しかしながら長年経ってから地政学と結びつくとさまざまな理解が深まり、なんでこれをいままで知らなかったのだろうと思うくらいです。

本書の構成

本書は構成として「日本」「大国」「大国に影響受ける小国の集まり」という3つの観点から構成されています。

  • ​Chapter1 基本的な6つの概念
  • Chapter2 日本の地政学
  • Chapter3 アメリカ・ロシア・中国の地政学
  • Chapter4 アジア・中東・ヨーロッパの地政学

第1章で地政学の基本となる概念を先に説明してくれるので、その後の章で各国がどういう特徴があるかを説明されてもわかりやすく、まずこの章を読むだけでも地理的な知識を多く持っている人はすでに大枠は捉えられたと言っても過言ではないと思います。

第2章はまさに自分の身の回りで起きている様々な出来事、たとえば北方領土、尖閣諸島、対馬列島などの問題における地政学の観点からの解説や嘉手納と横須賀にある米軍基地の地政学上の意味など、その文脈が深く理解できるものでした。

第3章は国際政治を大きく動かす大国であるアメリカ、ロシア、中国に関する地政学的観点からの特徴や、そこから見えてくる各種戦略の解説は多くの現代史の理解を深めてくれるものでした。

第4章はアメリカ、中国、ロシアと友好関係を築いたり、敵対関係にあるアジア、中東、ヨーロッパ諸国の地政学の観点からの立ち振舞を解説。さすがにここは単純に地政学だけでの理解は難しく、補助的に解説を補強するための歴史や文化の解説が入りますが、地政学を軸に他の観点の知識を補強することで、以前よりも整理した形で現状を把握できるようになった感触があります。

感想

本書は2020年6月に発刊されたとあって、最新時事も時折入っており、今軽く地政学について学ぶには非常に良い本だと思いました。実際、発売3ヶ月で10万部発行するなど売れ行きも好調のようです。

本書をきっかけにしてより詳細に地政学を学んでいきたいと思えたので、自分と同じく過去にまったく学んだことがない人にはおすすめできる本だと思いました。あえて本書で残念だったところを挙げるとすれば、本書はどうしても北半球だけの内容になっていたところです。今後多くの天然資源があるアフリカ、オーストラリア、南アメリカに関する地政学的な解説も読みたいなと思いました。

参照

本書の監修の奥山さんのブログ。こちらも面白いです。

geopoli.exblog.jp

外務省のサイトに多くの解説記事があるので、気になった国際政治関連ニュースはたまにここで見てます。

www.mofa.go.jp

「フラッシュ・ボーイズ 10億分の1秒の男たち」読了

Book

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。コロナ禍によって在宅勤務が増えるだけでなく外出の機会が減った結果、家での趣味が増えています。4月以降に増えた活動だけでも

  • 読書
  • 自作キーボードの調整・作成
  • 園芸・家庭菜園
  • 仕事部屋の整理・充実

などがあります。特に読書のペースは昨年と比べるとだいぶ上がり、図書館から常に本を借りている状態になりました。最近は金融・経済・西洋美術の本を読むことが多いのですが、先日読み終えた「フラッシュ・ボーイズ 10億分の1秒の男たち（原著題: Flash Boys: A Wall Street Revolt）」が金融系でありつつITが深く関連する話で面白かったので読書記録として残しておきます。技術書以外の記録を残すのは久々です。

フラッシュ・ボーイズ 10億分の1秒の男たち (文春文庫)

フラッシュ・ボーイズ 10億分の1秒の男たち (文春文庫)

以降、本書のネタバレを含みます。

高頻度取引業者がどうやって儲けるのか

高頻度取引（High Frequency Trade; HFT）が隆盛したのは自分が思っていたよりずっとあとで、2000年代後半、とくにサブプライムローン問題の後でした。金融系のニュースを見ると度々HFTの話題が出ていたためなんとなくその存在は知っていたし、雰囲気で「HFTはマーケットメイク戦略と裁定取引で儲けている」ということは知っていたのですが、本書でその細かな実態を初めて知り、これはとんでもないことだと改めて認識しました。

HFT業者が行うマーケットメイク戦略は価格差がある反対売買を繰り返すことでトレンドを作り適切なタイミングで利ざやを稼ぐ方法、裁定取引は価格の動きが異なる市場間で反対売買を行い価格差で利ざやを稼ぐ方法ですが、どちらにおいてもいち早く情報を獲得することで大きな利益を生み出すことができるため、回線速度を高める（低レイテンシ）ことが最重要となります。サブミリ秒での取引ですべてが決まっていたため、もはやこれは彼らに取っては必須の条件でした。HFT業者は取引所までのレイテンシを下げるために専用回線の契約やコロケーションなどを行います。基本的に経路が最短になればレイテンシは一番低くなるため、第1章や映画で作っていた専用回線はそれを目的としてシカゴとニューヨーク（実際はニュージャージー）をとにかく真っ直ぐつないでHFT業者に高い利用料で貸し、大儲けしたという話でした。

さらにナスダックを始めとする公開取引所や、ダークプールと呼ばれる投資銀行などが運営する私設取引所（PTS）の一種でのコロケーションも、場所を貸す代わりに高い利用料を取り、取引所ではその利用料による収入も無視できなくなっていたようです。また取引所はHFT業者が多く来てくれるように、取引に応じて報奨金を払うなどの施策も行っているということも初めて知りました。こうして取引所がHFT業者との結びつきが切り離せない状態になっていて、各投資銀行が実際に運用を行うにあたっても常にHFT業者にフロントランニングされ、本来であればHFT業者がいなければ安く買えた、あるいは高く売れた株式が期待通りの額で取引できず、結果しわ寄せは各投資家（我々一般投資家含む）に来るという、実情を知ると看過できない状況でした。

IEXが成し遂げようとしたこと

こうした事実に気付いたのがカナダロイヤル銀行（RBC）のブラッド・カツヤマで、投資銀行が株式の取引を行う際に必要な数の株式を取得するために複数の取引所に発注をかけると各取引所に発注が届く時刻に時間差が生まれ、そこをHFT業者に突かれてしまうことに気が付き、時間差がなくなるように調整するソー（Thor）と呼ばれる取引プログラムを開発しました。これによりRBCだけでなく他の投資銀行にもソーの利用を呼びかけ、その過程で多くの投資家を味方につけていきます。

ソーの利用だけでは、その利用者だけしかHFT業者による搾取を免れることはできませんが、HFT業者が利益を取得する構造（高頻度取引を支えるReguration NMSと呼ばれる法律や、ダークプールに許される取引状況の非公開など）を健全化したいと考えたブラッドは、そのためには健全な取引所が必要で、かつそれが無視できない規模にならなければいけないと考え、IEXという取引所を立ち上げるに至ります。そこではHFT業者に有利になるような取引条件やルールを可能な限り排除して、コロケーションも認めず、アクセスするにはフロントランニングが不可能な距離にある中継所を経由しなければならないなど、徹底した公平性を目指しました。

立ち上げ直後にはHFT業者がいる状況を維持したい投資銀行などから嫌がらせを受けたりもしますが、本書の最後ではHFTによる利益を享受できないと判断したゴールドマン・サックスがIEXに協力し、結果IEXを取引所として維持していくのに必要な取引数を達成するに至って、今後の市場の健全化を願いつつ物語は終わります。

ゴールドマン・サックスとHFT

ゴールドマン・サックスはIEXを助けた一方で、そこに勤めていた優秀なロシア人エンジニアのセルゲイ・アレイニコフが同社を退職する際に、ソースコードの窃盗を行ったという理由で刑事訴訟し、結果セルゲイに懲役8年の判決がなされるに至り、実際セルゲイは刑務所で過ごすことになります。本書によれば、セルゲイはゴールドマン・サックス社内でHFT関連の対応をするために、社内の巨大なコードベースを整理しつつ、OSS製品にパッチを当てた上で社内で利用していて、そのパッチ込みのコードを退職の際に外部のコードホスティングサービスに置いたということで窃盗として訴訟された、ということになっています。

外部に置いたコードの大半がupstreamにあったものである上に、パッチを当てたものを還元するすることが許されなかったために行った行為であるにも関わらず、それをゼロから構築した機密事項であるかのごとく訴訟を起こし、最終的に覆されたとはいえ、懲役8年の実刑判決に至らしめたのは、ゴールドマン・サックスのHFTで利益を出しきれない焦りもあったのでしょう。

結果、HFT関連の牽引をしていた責任者が転職したあとの後任が自社の利益と倫理の両立が可能である市場の健全化に向かってIEXに肩入れしたのは、サブプライムローン問題でCDOを顧客に売りつつ、その暴落に賭けてCDSを買い、結果巨額の利益をあげたたった数年後というのはなんとも皮肉だと感じました。*1

HFTと日本市場

日本でも東京証券取引所を始めとするJPXが2010年にシステムを刷新し、高頻度取引などを行うインフラを整え、実際にコロケーションサービスを提供したりしています。

www.jpx.co.jp

研究者の報告によれば、2017年現在においては日本におけるHFTの状況は東証が主で、米国と違いダークプールでの取引量はほとんどないとのことですが、iDeCoやNISA、401kの推進などが進められているので今後どうなっていくのかは個人的に大変気になります。本書で書かれているような状況とは違い、日本ではHFT業者は金融庁への届け出をしなければならず、また今年8月（今月！）にダークプールに対してより多くの情報を公開するような規制が入るということで、せっかくこうした話題も理解できるようになったので、動きを追っていきたいと思います。

余談ですが、金融庁やJPX関連の情報を検索すると、検索上位がPDFファイルへのリンクだらけになり、PDFを除いてしまうと1次情報が壊滅的になくなってしまうので、モチベーションが無いのは分かりますが、金融関係者のみなさまにおかれましては、ウェブサイトに直接情報を掲載してくださいますよう、お願いいたします。

映画版との違い

本書「フラッシュ・ボーイズ」は一昨年「ハミングバード・プロジェクト 0.001秒の男たち（原作題: The Hummingbird Project）」というタイトルで映画化され、昨年日本でも公開されました。


夢のプロジェクト発案は偶然? それとも運命!?／映画『ハミングバード・プロジェクト 0 001秒の男たち』本編映像

映画は観ていないのですが、トレーラー映像や観た方が紹介しているあらすじを読む限り、本書の第1章に書かれていた内容を広げたもののようで、本書の本筋とは違う内容になっているようです。映画版は超高頻度取引（HFT)業者のために高速（低レイテンシ）回線の敷設を行う話にとどまっているようですが、本書ではその話は話の入り口でしかなく、本筋は上に述べたようにHFT業者のために投資家が不利益を被っているいう事実とダークプール含め取引所がHFT業者の活動を許すことで利益を上げているために是正していないこと、それを正すために立ち上がったブラッドの奮闘という、勧善懲悪物になっています。

マイケル・ルイスの著作

マイケル・ルイスは金融系ノンフィクション作家・ジャーナリストとして有名で、本書以外にも「マネーボール（原著題: Moneyball: The Art of Winning an Unfair Game）」「世紀の空売り（The Big Short: Inside the Doomsday Machine）」といった著書がそれぞれ映画化され、映画も含めて大きな話題となりました。

マネー・ボール〔完全版〕

マネー・ボール〔完全版〕

世紀の空売り―世界経済の破綻に賭けた男たち (文春文庫)

世紀の空売り―世界経済の破綻に賭けた男たち (文春文庫)

自分はマイケル・ルイスの著作を本で読むのは初めてで、「マネー・ボール」も「世紀の空売り」も映画でしか観ていませんでしたが、これを機にこれらの原作や他の著作を含めて読んでみようと思います。

追記 (2020/08/03 12:45): セルゲイ・アレイニコフとErlang

記事を公開したら力武さんが次のように教えてくれたので調べてみました。

Wikipediaを見るとたしかにErlang製OSSに数多く貢献していた旨記載があります。

He authored a telecommunications patent and contributed to a number of open-source Erlang and C++ projects. He also published several Perl modules on CPAN.

Wikipediaにもリンクがありますが、ZeroMQのErlangバインディングを書いたのは彼で、実際ZeroMQのorganizationを見ると、彼が書いたバインディングのフォークが公式となっています。（@saleynが彼のGitHubアカウント）

github.com

他にもErlangコミュニティのメーリングリストで彼の無罪確定のニュースがスレッドになるくらい有名であったことが伺いしれます。　

erlang.org

関連書籍

本書の中でいくつか面白そうな書籍が参照されていたので、そちらも読んでみたいと思いました。

ウォール街のアルゴリズム戦争

ウォール街のアルゴリズム戦争

Broken Markets: How High Frequency Trading and Predatory Practices on Wall Street Are Destroying Investor Confidence and Your Portfolio (English Edition)

Broken Markets: How High Frequency Trading and Predatory Practices on Wall Street Are Destroying Investor Confidence and Your Portfolio (English Edition)

参照

*1:サブプライムローン問題の際にはそれだけでなく、CDSを売っていたAIGの株の空売りもして二重で儲けていたのがなんともえげつない

恵贈御礼「入門 監視」読了

Observability misc Book

はじめに

こんにちは、Stackdriver担当者です。年明けに「入門 監視」を恵贈頂いたのですが、書評を公開するのが遅くなってしまいました。すでに多くの方が書評を公開していらっしゃいますが、そちらは気にせず自分の書評をメモ代わりに書いておこうと思います。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

TL;DR

  • 本書を読んでも即座に監視に関する問題が解決するわけではないが、システム監視について何から始めれば良いかわからない人はまず手にとるべき本であると思う。
  • 本書とSRE bookを読むことで同じ内容を異なる角度から捉える事ができ、非常に有益。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

感想

全体として

  • 1章　監視のアンチパターン
  • 2章　監視のデザインパターン
  • 3章　アラート、オンコール、インシデント管理
  • 4章　統計入門
  • 5章　ビジネスを監視する
  • 6章　フロントエンド監視
  • 7章　アプリケーション監視
  • 8章　サーバ監視
  • 9章　ネットワーク監視
  • 10章　セキュリティ監視
  • 11章　監視アセスメントの実行
  • 付録A　手順書の例：Demo.App
  • 付録B　可用性表
  • 付録C　実践.監視SaaS

本書の目次を見て分かるとおり、前半で監視の設計手法や取り組み方に関してから始まり、後半でシステム内の各構成部品に対する監視の概要を見ていくという内容でした。よって、本書一冊ですべてが解決するという辞書のような使い方ではなく、本書で大まかに監視全体を把握するのに向いていると思いました。

特に今2019年現在において「監視」というのがどのような取り組み・行為なのかを解説した本として充実していました。現代での「監視」のスナップショットの確認として、さらっと一度流し読みするだけでも価値があると感じます。

システムアーキテクチャ・開発手法の変化による監視手法の変化

本書で最も特徴的であり、自分が大きく賛同した部分は、本書が「システムアーキテクチャや開発手法が変化したことにより、監視手法も変化してきている」という点を様々な角度から論じていた点です。

各章で語られていたことを簡単に抜粋してみます。

1.2 アンチパターン 2: 役割としての監視

監視とは役割ではなくスキルであり、チーム内の全員がある程度のレベルに至っておくべきです。（中略）監視の旅へ進むに当たって、皆が監視について責任を持つことを主張してください。

2.1 デザインパターン 2: ユーザ視点での監視

まず監視を追加すべきなのは、ユーザがあなたのアプリケーションとやり取りをするところです。

3.2.3 上手にオンコールローテーションを組む

ソフトウェアエンジニアもオンコールのローテーションに入れることを強くおすすめします。

5.4自分のアプリケーションにそんなメトリクスはないという時は

必要な計測データをアプリケーションが出してくれないなら、自分でアプリケーションを変更してしまいましょう。

6 フロントエンド監視

そして、時と共にパフォーマンスが悪くなってしまわないように、既存のツールにフロントエンド監視をどのように組み込んでいくのかを考え、この章の仕上げとします。

7 アプリケーション監視

アプリケーションのメトリクスはいろいろなことにとても便利に使えるので、なぜすぐ始めなかったのか不思議に思うくらいでしょう。

7.6 マイクロサービスアーキテクチャを監視する

マイクロサービスがあらゆるものを飲み込みつつあるこの世界では、優れた監視の仕組みを持つことは絶対条件になっています。

ざっくりと抜粋しているので、上記の引用だけでは読み取りづらい部分があると思いますが、私はこれらはすべてDevOps、さらにはSRE的なアプローチによって、アプリケーションとインフラを区別して捉えるのではなく、システム全体として期待されるとおりに稼働しているかを捉えることが重視されるようになったことが影響していると考えています。

またクラウド上でシステムを動作させることが増え、アプリケーションのモジュール化も進み、それに関わるインスタンスの台数も需要に応じて柔軟に増減するようになってきていることで、インスタンス自体のメトリクスよりも、アプリケーションに係るメトリクスが与える影響が大きくなっていることも関係があります。

これらによって、監視そのものが「インフラチームがアプリケーションランタイムの安定性を見る」という性質から「システム全体として期待した動作を行っているかの確認をする」という性質に大きく変化しています。当然その変化の中で、アプリケーションエンジニアが監視や運用に参加することの必要性も高まってきています。

そうした運用手法としてDevOpsを推し進めたものの一つがSite Reliablity Engineering (SRE) だと思いますし、そのような監視をどのように行うかというのを一貫して紹介したのが本書だと感じました。

また使用するランタイムの性能が向上していることもこれらを支える一助となっているでしょう。「1.1.1 監視とは複雑な問題をひとくくりにしたもの」の節のコラム「観察者効果は気にしない」には次のようにあります。

観察者効果とは（中略）技術分野では、監視ツールがシステムに負荷を加えてしまうことを指すことが多いですが、これは大した問題ではありません。今は2017年で、1999年ではありません。

Application Performance Management (APM) においては、トレース情報やプロファイル情報をサンプリングして取得する手法が主になっています。これらが許容されるようになったのはサンプリングを行ってもアプリケーションに与える影響が問題ないくらいマシンのCPUやメモリ、あるいはネットワークなどの性能が高まったからでしょう。

乱暴に言えば、クラウドではアプリケーションランタイムとしてのインスタンスは即座に上位性能のものに入れ替えられる一方でアプリケーション自体は、その開発フェーズが進めば進むほど、即座の置き換えが難しくなります。そうしたこともAPMなどといったアプリケーション側の監視の比重が高まってきている要因でしょう。

本書では「6章 フロントエンド監視」「7章 アプリケーション監視」と2章を割いて、アプリケーション側の監視の考え方を紹介していて、そういったものを導入しようとしている人向けに良い入門になっていると感じました。

SRE bookと重なる部分

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

上のような理由から、同じオライリーで発刊されている「SRE サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム」（SRE book）の内容と重なる部分や、SRE bookでより詳細に説明されている内容なども見受けられました。いくつか抜粋します。

2.1.1 監視サービスのコンポーネント

ペナルティ事項の存在しないSLAは、むしろ「目指すべき目標」と一般的には捉えられます。

この用語を区別するためにSREではSLI、SLO、SLAとサービスにおける指標、目標、契約を呼び分けています。

1.5 アンチパターン 5: 手動設定

もし手順書が単なるやることの羅列なら、さらなる自動化が必要です。

3.1.6 まずは自動復旧を試そう

アラートに対する代表的なアクションが、既知でかつ用意されたドキュメントの手順に沿って対応するだけなら、コンピュータにその手順をやらせない理由はありません。

これはまさにトイルの撲滅そのものです。

3.4 振り返り

振り返りには良くない習慣があることに私は気づきました。それは誰かを非難するという文化です。

これに関してはSRE bookにある「非難のないポストモーテム (Blameless Postmortem)」にも詳細に書かれています。

監視とは、システムを見守るという行為なので、システムの信頼性を担保する役割であるところのSREチームには大きく関係するところであり、こうした内容が重なるのは当然でしょう。

しかしとはいえSRE bookはかなりの重量級（B5版 590ページ）です。ましてこれからそうしたことに取り組もうと思っている方は、読もうと思っても、その重量に圧倒されかねません。その点入門監視はA5版 200ページとあっさり読める内容です。深堀りはしていなくても、監視の全様を大まかに把握するにはうってつけです。本書を読んでから、あらためてSRE bookを読んでみるというのも手だと感じました。

付録C 実践 監視SaaS

私が本書が翻訳版として価値があると感じたのは、もちろん「付録 C 実践 監視SaaS」です。こちらは監視SaaSであるMackerelの @Songmu さんが書き下ろしとあって、監視SaaSの利点、信頼性、選定ポイント、利用方法について、本文でぼかされていた部分を一歩踏み込んで解説し、即座に実践に活かせる内容となっています。

私も冒頭で述べているようにGoogle Cloud Platformの Stackdriver という監視SaaSの担当をしているのでうなずくことばかりです。

Stackdriverにはロギング、分散トレース、プロファイラ、モニタリングダッシュボード、エラーレポート、デバッガといった製品群があります。 本書で触れられていた内容に関しては一通りカバーしている製品群で、特に特徴としてはまさに本書のような現代的な監視手法を導入しやすくしている点（例: ログベースメトリクスの作成、OpenCensus を利用したアプリケーションメトリクスの取得、分散トレース、フレームグラフが見えるプロファイラなど）です。

これも主にGCP上でシステムを動かす開発者・運用者が、即座にSRE的な監視を行える機能を提供するという目的があって開発されているためです。（たとえばGoogle App Engine Standardでは分散トレースやログベースメトリクスなどはインストゥルメンテーション無しで即座に行えるようになっています）

クラウドプラットフォーム事業者が監視SaaSを提供する利点は、一番下のレイヤーまでできるだけ多くの情報を提供でき、他のサービスとの連携も図りやすい点にあります。（先程のGAEの例をはじめ、GKEでもアプリケーション側のインストゥルメンテーションのみでロギングや分散トレースやプロファイラとの連携可能です）

この付録Cを通じて、監視SaaSを導入する企業が増え、Stackdriverにもより多くのフィードバックが来ることを期待しています。GCPUG Slack の #stackdriver チャンネルにいますので、利用してみて疑問に感じたことがあればぜひ来てください！

gcpug.jp

参照

恵贈御礼 「Go言語にWebアプリケーション開発」読了

Book Go

はじめに

こんにちは、Go界のパルメザンチーズです。オライリー・ジャパンより次の本をいただきました。ありがとうございます。

Go言語によるWebアプリケーション開発

Go言語によるWebアプリケーション開発

感想

Go言語そのものをまったく書いたことがない人がいきなり本書を読むのはいささか厳しいと思いますので、あらかじめ A Tour of Go などを終え、FizzBuzz程度でもいいので簡単なコマンドラインアプリを手元で書いてみてから読み始めるのが良いと思いました。

この本で一番読み応えがあったのは、監訳者の鵜飼さんによる日本語訳版オリジナルの書き下ろしである「付録B：Goらしいコードの書き方」でした。本書を読むにあたって、まず最初に読むべき章だと言っても過言ではありません。本文に出てきたソースコードをより洗練するためにどのような点に注意すればよいかが書かれている貴重な日本語資料です。また本文のいたるところで補足するべき箇所にきめ細かな監訳注があるのも、日本語訳版の素晴らしいところです。この監訳注によって本書の品質が大幅に向上していることは間違いありません。

内容そのものは、構造化された解説書というよりも、実践的なチュートリアル本というのが適切でしょう。Goの文法はわかったけれどどこから手をつけていいかわからないという方は、まずは自分が取り組んでみたいと思っているテーマに近い章を開き、本文にしたがって少しずつコードを書きながらGoでプログラムを書くことに慣れるというのがおすすめです。サードパーティーライブラリの紹介なども多かったので、他言語の経験があるけれどもGoは初めて、という方にも肩慣らし的に試すのには手っ取り早い本だと思います。

1-3章がWebSocketを使った簡単なチャットシステムのフロントエンドとバックエンド、4章で簡単なコマンドラインツール、5-6章では並列処理を使ったデータ解析サービスとそのREST API化、7章ではファイルバックアップシステムと、テーマは多岐にわかっていますので、つまみ食いでも始めやすいです。

Goはシステムプログラミング言語としてよく知られていますが、実際にどういう形で実現できるのか、本書で実感いただけるのではないかと思います。

読書メモ

ページ数は書籍版のものです。

p.21 監訳注2

デフォルトのパッケージ名は package キーワードで指定されたものであり、ディレクトリ名ではないが、通常は揃えるという話。違ってくる場合としてよくあるのはパッケージをバージョンニングするとき。たとえば、Google Drive APIのクライアントライブラリはv1, v2, v3と３つのバージョンがある。これをimportするときは次のようになる。

import github.com/google/google-api-go-client/tree/master/drive/v3

p.81 監訳注1

パッケージ名に common や lib 、 util を使わないようにしようという話はgoblogに詳しく解説されている。

p.158 ノート

GorillzはGorillaのtypoだと思う。muxerも自分で書いてみるような問題もあれば良いのにと思った。

p.221 監訳注2

const では指定しないかぎり型がないという話はgoblogに詳しく解説されている。