PowerShellでマルチスレッド処理(仮)
夏が終わりそうで切ない。
切ないので、何の気の迷いか、PowerShellの激軽なメモを書いてみる。
やりたいこと
3秒待ってprocessの連番を出力するだけの処理。これを5回繰り返す際に、並列でやらせたい。
function Do-Process() { param([int] $process_num) $tid = [threading.thread]::CurrentThread.ManagedThreadId Start-Sleep -Seconds 3 Write-Host "theadId:$tid, process:$process_num" }
まず、直列のほうを実行する。
function Test-Sync() { foreach ($i in 1..5) { Do-Process ${i} } } $time = Measure-Command { Test-Sync }
実行結果はいかのとおり。
PS C:\temp> .\parallel_test.ps1 theadId:14, process:1 theadId:14, process:2 theadId:14, process:3 theadId:14, process:4 theadId:14, process:5
1から5まで順番に、単一のスレッドで実行されている。これをマルチスレッド化したい。
Workflowを使ってやる
Workflowってなんぞ？って人は、Windows PowerShell ワークフローについてをどうぞ。
workflow Test-Parallel() { foreach -parallel ($i in 1..5) { Do-Process ${i} } } $time = Measure-Command { Test-Parallel }
実行結果は以下のとおり。
PS C:\temp> .\parallel_test.ps1 theadId:9, process:5 theadId:4, process:3 theadId:11, process:1 theadId:12, process:2 theadId:6, process:4
処理の順番はバラバラで、スレッドも異なっている。 マルチスレッドで処理されている。ようにみえる。
PowerShell 3.0の時点では、-parallel はシングルスレッドで処理されていたらしい。
MSのひとも以下のように言っている。
As an Activity author you can’t make any assumptions about what thread your activity will be invoked on or how that thread will relate to any other thread used by any other activity.
Windows Workflow Foundation (WF4) Activities and Threads – Ron Jacobs
謎。かしこい人、教えてください。
Background jobsでやる
PowerShell 2.0以降では、jobをbackgroundで起動できる。
Invoke-Asyncでやる
パフォーマンス的にはBackground jobsを使う方法に劣るが、スレッドの管理がラップされていてシンプルに書けるらしい。
補足
今回使ったWindows PowerShellは、長年Windowsにくっついていた歴史とぬくもりのあるPowerShellであり、.NET Frameworkでできている。WIndows PowerShellのWorkflowは.NET Framework 3.0で導入されたWindows Workflow Foundationという技術を基盤にしている。
一方で、.NET Coreを基盤としたPowerShell Coreもある。ただ、こちらにはWorkflowが移植されてない。
そのため、お手軽にはマルチスレッドの処理ができない。以下のようにがんばることになる。
環境
Windows 10。
PS C:\temp> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.15063.1209
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.1209
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
参考
お笑いライブのすゝめ
お笑いライブはいい。
一般に、「お笑いが好き」という人はけっこう多い。テレビでは日夜バラエティ番組やネタ番組を始め、あらゆる場面でお笑い芸人をみる。また都内では、毎日どこかしらでお笑いライブが開催されている。こういった状況にも関わらず、お笑いライブに行ったことがある人は、少なくとも自分の観測範囲内にはほとんどいない。
ただでさえ人間との会話に難がある私が、唯一の趣味といってもいいお笑いの話を封じられると、何も喋れなくなって厳しい。
そこで本記事では、私がお笑いライブを推す理由と、都内近郊で気軽に行けるお笑いライブ、その中でも自分が行ったことがあるものを中心に、分類して紹介する。
すすめる理由
趣味は仕事と違い、他者に価値をもたらす義務がない。従って、その価値を他者に言語化して説明するのは野暮である。良いから良いということでしかないが、それを言っていても人々はお笑いライブに行かない。そこで、あえて書いてみる。
心身の健康にいい
自律神経系に良い影響があるとまことしやかに噂されている(要出典)。そもそも自律神経とはなにか。なにもわからない。エンドルフィンによる多幸感や、セロトニンによる抗うつ効果など、眉唾な研究結果()もある。
これらを置いておいても、嘲笑や愛想笑いなど特別な場合を除いて、一般に「笑う」ということ自体が良い行為であることは議論の余地がなさそうである。例外なくポジティブであり、笑うと楽しい。楽しいと笑う。哲学者ベルクソンは、著書『笑い』において、笑いの健康に対する作用として「緊張からの放心」と「考える疲労からの休息」を挙げている。体感的にもこれは妥当に思える。
- 作者: アンリベルクソン,林達夫
- 出版社/メーカー: 岩波書店
- 発売日: 1976/11/16
- メディア: 文庫
- 購入: 10人 クリック: 40回
- この商品を含むブログ (32件) を見る
テレビでいいと思うかもしれないが、劇場に赴き「みんなで笑う」という行為は、想像以上に気持ちのいいものである。
テレビより1億兆倍おもしろい
たまにお笑いライブを他者におすすめすると、「テレビでみれるからわざわざライブにいかなくても…」という意見を頂戴することがある。これに異を唱えたい。
演劇や音楽のライブと同じく、お笑いにおいても、その場が持つ空気感、一体感は独特なものがある。テレビでお笑い芸人をみて「なんでこんなにおもしろくない芸人が売れているんだろう…」と思うことは多々あると思うが、実際に生でみると、彼らがとんでもないレベルで仕事をしていること、そのすごさを体感できる。こればかりは本当に行ってみないとわからない。
趣味としてのコスパがいい
劇場に行くと、テレビに出ている芸人さんたちが、目の前でネタやトークをやっている。料金は無料のものから数千円のものまであるが、それでも演劇やミュージカルと比べて破格といえる。
また後述するが、これから人気が出ていくであろう若手芸人を発掘するのも楽しみの一つである。地下アイドルやインディーズバンドを応援するような感覚で楽しめる。 ネタが洗練されていく過程や賞レースでの躍進などを間近で楽しめる。
プロから笑いを買える
唐突だが、異性とのデートを企てている若者たちは、ぜひお笑いライブをその選択肢に加えてほしい。この時点で、本ブログを読んでいるような層は、「自分には一切関係がない話だ、読み飛ばそう」と思うかもしれない。そうに違いない。ただ、ちょっとまってほしい。我々のような層にこそ、お笑いライブを一手として持っておくべきなのである。
異性とのデートにおいて、「楽しませる」ということは非常に需要なKPIである。ここでの要点は、我々のような層は、会話によって人間を楽しませる能力が信じられないくらい低い、ということである。そのため、何を話したら良いかわからず、混乱し、錯乱し、支離滅裂な発言をし、やがてすべてを失う。終焉の訪れである。
そこで、お笑いライブに行くことを考える。そうすると、「楽しませる」という部分を、まるっどプロにお任せできるのである。だいたいのおいてデートなど、その中での細かい会話などは案外覚えていないものである。「楽しかったな」「めっちゃ笑ったな」という印象が残れば上出来であり、それは必ずしも自身で達成しなくてもよい。自分が楽しませなければというプレッシャーによる負のループから抜け出することができる。
また、若者の一般的なデートとして、映画鑑賞が挙げられる。映画館に行って2時間座って鑑賞し、終了後にカフェなどで感想を言い合う。ここで重要なのは、人間は他者からよく思われたいというバイアスがかかるということである。人間は汚い。面白くなかったとしても、口頭ではなんとでも言える。それに対し、お笑いは笑うか、笑わないかである。より根源的でシンプル。同時に、笑いのツボが一致しているかも確認することができる。
お笑いライブ
ここまでで読者はお笑いライブに行きたくてたまらなくなっているはずなので、いくつか紹介する。
冒頭で述べたとおり都内近郊では毎日どこかでお笑いライブが開催されているが、その趣は多様である。
今回はお笑いライブに行ったことがない人に向けて、その概要を紹介する。
事務所ライブ、独立系ライブ、単独系ライブ、賞レース予選ライブと、勝手に分類する。
事務所ライブ
お笑い芸人を要する各事務所が、定期的にライブを開催している。 吉本興業がスケール的にも別格なので、よしもととそれ以外で紹介する。
よしもと
泣く子も黙る国内最大手お笑い事務所。
都内にも、ルミネtheよしもと@新宿、ヨシモト∞ホール@渋谷をはじめとてて、複数の劇場をもつ。 テレビでも見たことあるメジャーどころの芸人さんのネタや、よしもと新喜劇を楽しみたい方はルミネ、若手芸人のライブを安価で楽しみたい方は∞ホールをおすすめする。
∞ホールでは、その中でも突発のものからレギュラーものまで、様々なライブがほぼ毎日行われている。他者事務所と比較して、養成所やノウハウがあり、若手芸人であっても安定感がある。有力若手芸人が勢揃いする『JET GIG』をおす。休日の午前中から夕方にかけての公演が多く、直前でも比較的席が空いているので、急な予定も合わせやすい。
注意点としては、良くも悪くも玉石混同、かつ2時間に渡ってネタが続くため、かなりの疲労感がある。このあたりは個人差もあるが、体力に自信のある方、メジャーどころだけでなく次世代の若手にいち早く目をつけたい方はぜひチェックされたい。
よしもと以外
表にする。順不同。
| 事務所 | 主な所属芸人 | 拠点 | 特徴 | 事務所ライブ関連のURL |
|---|---|---|---|---|
| ワタナベエンターテイメント | ネプチューン・ブルゾンちえみwithB・厚切りジェイソン・平野ノラ・四千頭身 | 表参道 | 左記のとおり、近年大ヒット芸人を続々と排出している。 | ライブ情報｜ワタナベエンターテインメント |
| 人力舎 | 東京03・アンジャッシュ・ドランクドラゴン・アンタッチャブル・バカリズム・卯月 | 新宿 | コント中心の芸人が多い。その影響で事務所ライブ「バカ爆走！」では、芸人登場時に拍手をしないことで有名。 | EVENT イベント : JINRIKISHA OFFICIAL WEBSITE プロダクション人力舎オフィシャルウェブサイト |
| 浅井企画 | キャイ～ン・ANZEN漫才・流れ星・ドドん・ジャイアントジャイアン | 新宿 | 萩本欽一氏、小堺一機氏、関根勤氏を排出し、「人間味あふれるお笑いのプロ集団」として知られる。 | ライブ・イベント | 浅井企画｜タレント・芸人・文化人 芸能プロダクション |
| ホリプロコム | バナナマン・スピードワゴン・磁石・きつね | 新宿 | 芸能事務所ホリプロのお笑い部門。渡辺正行氏主催のお笑い団体「M2カンパニー」が前身。 | ホリプロお笑いライブ | ホリプロコム オフィシャルウェブサイト | HORIPROCOM Official Site |
| ソニーミュージックアーティスツ | バイきんぐ・アキラ100%・湘南デストラーデ | 千川 | 厳密には事務所内の「SMA NEET Project」がお笑い部門に位置する。バイきんぐ小峠氏曰く、「あらゆるオーディションに落ちた芸人崩れが最後に行き着く事務所」らしい。 | SMA お笑いライブ会場“びーちぶ” |
| マセキ芸能社 | 出川哲朗・狩野英孝・ニッチェ・三四郎・ジグザグジギー・さすらいラビー | 新宿 | エクストラシルバー、ライラックブルーなど、ランク別ライブのライブ名がダサい。 | マセキ芸能社 MASEKI GEINOSHA Official Site |
| 太田プロ | アルコ＆ピース・アイデンティティ・新宿カウボーイ・ノブナガ | ？ | 老舗事務所。かつてはビートたけしや片岡鶴太郎が所属しており、テレビ一時代の長だった。 | ライブ情報 | 太田プロダクション |
| タイタン | 爆笑問題・日本エレキテル連合・ウエストランド・XXCLUB | 阿佐ヶ谷 | 私の推し事務所。事務所ライブにいくと長井秀和氏によるテレビ完全アウトなネタがみれる。 | ライブ | TITAN |
その他、松竹芸能という超大手から、ビートたけし率いるオフィス北野、サンドウィッチマン率いるグレープカンパニーなどなど、大中小含めて様々な事務所がある。
独立系ライブ
事務所以外にも、ライブ主催団体がいくつかある。お笑い好きのおじさんが趣味でやっている謎ライブもあったりして、本当に当たり外れが激しい。
K-PRO
主に都内のお笑いライブを主催する団体。
新宿、下北沢、中野などを会場に、ほぼ毎日お笑いライブを主催されている。 若手を中心に、事務所や芸歴問わず様々な芸人さんが出演する。たまにある大規模なライブでは、各事務所から豪華ゲストが出演するにもかかわらず比較的安価で、非常にコスパがいい。
様々なランクのレベルがあるが、初見だとわかりにくい。はじめていくなら、バティオスネタ祭り、V-1ネタ祭り、超ボルケーノ寄席、スペシャルブルームあたりが間違いない。次世代の若手をみたいなら、ブレナイなどもいいかもしれない。
U&Cエンタープライズ
同じく都内のお笑いライブ主催団体。
K-PROほどではないが、こちらもかなりの頻度でお笑いライブを主催されている。エントリー制のライブから上位ライブまである。比較的、女性の芸人さんの出演が多い気がする。
下北GRIP
毎週金土日に開催される無料ライブ。
ライブ前の時間になると、下北沢駅、ピーコックの前で芸人さんたちが呼び込みをしている。会場はすごく怪しい場所にあって入りづらさ満点だが、けっこう満席だったりする。メイプル超合金やゆにばーすなど、ちょっと前までここで呼び込みしていた芸人さんがスター街道をのし上がっていくのをみるのが楽しい。
無料とはいえ、ライブ運営のために最後に芸人さんたちが出口で募金を募っているので、このブログを見て行かれる方は、ぜひ心ばかりの援助をされたい。
ラスタ原宿
ワンコイン500円で昼夜公演のあるお笑いライブ。
休日になると原宿竹下通りで芸人さんたちが呼び込みをしている。場所柄客層は極めて若く、従ってコアなお笑いというよりはアイドル的な芸人だったり、軽めのネタがウケる。端的にいうとチャラい。かのブルゾンちえみ氏もラスタ原宿出演から人気が出た。
ちなみにラスタ原宿という名前は、劇場オープン時に出資してくれた小島よしお氏をリスペクトしてつけられた。現役の芸人である、ザ・ビリーバーズの延籐氏が代表を務める。
単独系ライブ
事務所ライブと異なり、特定の芸人さんが主体となるライブもある。
単独ライブ
特定の芸人さんが好きになったり、応援したいという感情が芽生え始めたら、単独ライブをおすすめする。
会場費などある程度の集客力を前提とするため、本当の駆け出しの芸人さんはあまりない。ある程度のファンがいて、賞レースで勝負をかけたい層が主になる。
会場を埋めることに苦労する芸人さんもいれば、チケット即完や、全国ツアーをやる超人気芸人もいる。気になる芸人さんがいたら、まず直近の単独ライブの情報を調べてみるといいかもしれない。
芸人主催ライブ
単独ライブと似ているが、こちらは芸人さんが自身だけでなく他の芸人さんを呼んだり、合同で主催するライブもある。
例を挙げると、バラエティ番組で活躍する若手芸人が賞レースに勝ちたい場合、単独ライブを主催してネタを試したくても、観にくる客さんは熱烈なファンが大半になってしまったりする。そこで、客観的視点でネタを試すために、複数の芸人で合同のライブを実施し、相互のファンの目を入れる、などがある。
また、相方をシャッフルしたり、ネタのテーマを縛ったり、個性的かつ挑戦的なものも多い。普通のネタライブ以外が観たくなった場合や、好きな芸人さんの新たな一面をみたい場合におすすめである。
賞レース予選ライブ
M-1をはじめとする賞レースの予選リーグは、通常のお笑いライブと同じく観覧することができる。芸人さんが本気ネタでしのぎを削るため、ライブとしての品質も極上である。決勝はテレビ番組のため、ショーと割り切って観るのがよく、むしろ予選リーグこそ若手芸人の本気が観られる。
賞レースは無数にあるが、今回はテレビ放映もせれてもっとも知名度の高いと思われる、M-1、キングオブコント、R-1を挙げる。
M-1グランプリ
日本一の漫才師を決める大会。 予選が8月から始まっており、年末にかけて2回戦、3回戦、準々決勝、準決勝と選抜されていく。決勝は年末のテレビ放映される。
プロだけでなくだれでも参加できるため、1回戦は真の玉石混同で、プロの芸人はもちろんだが、ノリで出場した大学生や、果ては夏休みの絵日記のネタにと参加した親子コンビなどもいる。 2回戦、3回戦と進むに従って選抜されていき、3回戦ごろにはほぼアマチュアは淘汰されている。
人気芸人の本気ネタが安価で鑑賞できるライブでもあるため、チケットが非常にとりづらい。準決勝などはチケット転売サイトで高値が取引されていた。発売と同時に即購入ください。
キングオブコント
日本一のコント師を決める大会。 M-1よりやや早く、7月から予選が始まって、決勝は秋頃にテレビ放映される。準決勝は9月だが、現時点で前売りチケットはすべて完売している。観覧希望の方は来年にご期待ください。
R-1ぐらんぷり
日本一のピン芸人を決める大会。 年末に予選が始まり、3月初旬の決勝にかけて選考が進んでいく。決勝はテレビ放映される。 昨年は盲目の漫談家である濱田裕太郎氏が優勝して話題となった。
M-1やキングオブコントに比べるとまだチケットが取りやすいはずなので、ご興味ある方は春頃にそのつもりで。
お笑いライブにいくデメリット
ない。
さいごに
テレビでみて気になっている若手芸人がいれば、まずその名前でググればTwitterアカウントや事務所のライブ情報が出てくるので、行ってみるとよい。気になる芸人さんがいない場合は、まずはヨシモト∞ホール、もしくはK-PROのスケジュールを確認されたい。最初なら以下の条件を満たすライブをおすすめする。
- なるべく多くの芸人が出演する
- 料金が1500円〜2000円程度
今後数ヶ月は、M-1とキングオブコントに向けた対策ライブが頻繁に行われる、いわばオンシーズンといっていい。ぜひ見に行って、各自の推しをみつけてもらいたいし、その話題をもって私の話し相手になってほしい。
本当は私の推しの芸人さんについて述べたいが、この余白はそれを書くには狭すぎる。
『SRE サイトリライアビリティエンジニアリング』を読んだ
いや、夏やん。ってなってる。この勢いで気温が上がるのだけはマジ無理。マジ溶ける。
どんな本か
著者はGoogle社のSREチームの主要メンバー。
サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。
従来のシス管やDevOpsといった概念とは異なる新たな方法論について、Googleの実サービスの例を挙げながら紹介されている。
日本語訳の本書が発売されたタイミングで話題になったが、SRE自体はかなり前から一般用語化しており、先進的なｳｪｯﾌﾞの会社では早々に取り入れ、SREという職種で採用募集されていたりする。以下をさらっとみて、もっと知りたいと思ったら本書に手を出せば良さそう。
- 「SRE サイトリライアビリティエンジニアリング」を読んだ : Query OK.
- SRE 本は二度以上読む価値がある - 誰かの役に立てばいいブログ
- インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog
- ようやくSRE本を読み終わりました - ツナワタリマイライフ
- 『第74回： SRE大全: 序章』hbstudy#74 に参加してきた - ちくわ
原文は全文がWebで公開されている。英語できるマンはこれ読んでください。解散。
なぜ読んだか
10余年にも渡って取り組んできたSREという体制について、天下のGoogle様が出し惜しみなく赤裸々に語った本ということで、ミーハーだから買った。あわよくばお仕事に活かせることがあればいいなあというかんじ。
インターネッツで英語版を読んでも良かったが、ただでさえ分量が多く英語力が皆無なので、金の力で翻訳版を得た。会社の金で。
全体の感想
情報量がすごい。ページ数もさることながら、濃い。濃密。実質3万ページくらいあるのでゎ。
全34章と細分化されつつも、各章は独立して体系的にまとまっている。ので、章のタイトルを見て、気になるところを拾い読みするのがいいかもしれない。自分もハードウェア構成とかあまり関係なさそうなところは読み飛ばしたりした。
周囲の評判どおり学びが多く、例によって消化しきれていない。ただ読んだだけでは意味がないと思いつつも、単なる技術本とは違い個人が明日すぐに使える知識というわけではない。自分が携わるサービスに対してなにかできないか、SRE的な視点をもって現状を見てみるところからはじめていきたい。
「第9章 単純さ」が好き。なぜなら、シンプルさが好きだから。複雑なのが苦手だから。本章自体シンプルでポエミーで抽象的だが、SREの本質を的確に表現していると思う。重要なのは、本質以外は切り捨てる勇気。
「第12章 効果的なトラブルシューティング」もオススメ。トラブルシューティングは偶発的に起こる作業であるために、属人的、職人的になりがちで、その手順は明文化されていない事が多い。そんな中で、トラブルシューティングの一般的なフローを明記し、汎用的な思考パターンを提示されていて、いろんな場面で判断の材料になりそう。
「第15章 ポストモーテム文化：失敗からの学び」は某社社員にオススメ。捉え方の問題でもあるし、まだまだいくらでも改善の余地があるとポジティブに捉えられた。伸びしろですね。
「第23章 クリティカルな状態の管理：信頼性のための分散合意」は、主に分散合意アルゴリズムPaxosとその亜種について解説されている。自社のサービスで分散合意を直接意識することはないが、個人的に合意アルゴリズムには興味がある。おそらく、日本語でここまでまとまったPaxosの解説はない気がするが、理解できておらず、歯がゆい。自戒を込めてここに記録し、何らかの手段を持って理解し、本書を再読したい。
「第27章 大規模なプロダクトのローンチにおける信頼性」も某社社員にオススメ。というかたまたまいま自分の中でホットトピックだった。仕組みと構造化。やっていき。
「第33章 他の業界からの教訓」はおもしろいアプローチ。過去に他業界*1で働いていた現Google社員にインタビューし、SREの文化とプラクティスがどう適用されるのか、あるいはさらに学べないかを考察している。あらゆる業界において障害対策は本質的な課題であり、ディザスタテストやポストモーテムの文化、自動化、構造化といった考え方は、Google社あるいはITサービスに限定せず、あらゆる業界で有益そう。
各章の最後に「Google SREが推奨する参考文献」が紹介されている。ほぼすべてめっちゃ面白そうだったが、きりがないので涙をのんで追うのを諦めた。実践してみようと思う章があれば、そこの参考文献は目を通すと良いかも。
著者のひとりであるBen TreynorのインタビューがWebで公開されている。本書をひととおり読んだあと、あるいは読む前にさらっとみて意識を高めるといいかもしれない。
細かい感想
気になったところを引用しつつ、感想を書いておく。いま時点での自分が感じたことをオープンな場で記録しておくことに一定の価値がある気がする。知らんけど。
第Ⅰ部 イントロダクション
従来の開発プロセスが抱える問題と、それに対する仕組み、それらを包括するSREという概念について紹介されている。後半はGoogleのプロダクション環境について紹介されているが、いろいろ次元が違って参考になりそうもないのでいったんみなかったことにする。
「好きなものを好きなときに邪魔なしにローンチしたいんだ」対「いったん動いたシステムは一切変更したくないね」(p.4)
この本、というかSREという概念が解決したい課題を端的に示している。従来の組織では、開発チームと運用チームが分断されていて、前者は早くリリースすること、後者はシステムを安定稼働させることをミッションとしており、本質的に目的が対立関係にある。
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。(p.5)
よくわからない。俺達は雰囲気でSREをやっている。
ソフトウェアエンジニアがソフトウェアを設計する際に一般に意識する拡張性·信頼性·耐障害性などを、運用チームという組織の設計にも適用した場合、ということなのかもしれない。例として、『スケーラビリティ』という概念を運用チームに適用する。サービスの成長やユーザの拡大に伴って、運用メンバー（リソース）が線形に増えていく組織は、スケーラビリティが低いといえる。サービスが成長しても最小限のリソースで運用できる仕組みを構築することが、SRE的なチームの『設計』なのかもしれない。知らんけど。
GoogleではすべてのSREに対して、チケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう、上限を設けました。(p.6)
SREが従来の運用チームと異なるのは、主業務があくまでもエンジニアリングであること。運用な前述のとおりリソースを追加することによってある意味では達成可能。それに対してSREは、運用業務を最適化するようなエンジニアリングを行う。放っておくとリソース投下に走る力学が働くので、ルールとして明文化しているのだと思う。
ここで問題になるのは、その50%をどうやって計測するのか、ということ。SREに限らず、一般にエンジニアの業務の計測は、コストと精度、その必要性のバランスの中で難しい課題で、実際にうまくいっている例をみたことがない。最も原始的には各自が、自分が何にどれだけ時間をつかったかを記録しておくことだが、個人の裁量に委ねられているが故に、精度もまちまちになってしまう。スクラムやカンバンといった開発プロセスのフレームワークはひとつの解決法になるのかもしれないが、ことSREに関しては、新規機能開発と違ってスコープの不明確性やイテレーションで単純に切れないプロジェクトが大半なため、性質上、そのようなフレームワークとは特に相性が悪いと思える。うまいことやってる方いれば教えてください。
100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている(p.8)
Google様がおっしゃっておられあそばされますのでそのとおりです。99.999%を100%にするのは労力にわりに対価が乏しいから、他のことやれよ、ってことよ。では信頼性の目標をどう決めるのかというと、それはもうプロダクトごとに特性をみて定義していきましょう、でしかない。どれくらいであればユーザは満足するか。本書においてわりと重要なキーワードである『エラーバジェット』というものがあるが、これは次部ででてくる。
第Ⅱ部 原則
SREとして仕事を進める上で、原則となる考え方や指針を示している。
私たちはリクエスト成功率という観点から可用性を定義しています。(p.29)
可用性=成功したリクエスト数/総リクエスト数 、らしい。ドシンプルすぎて感動した。サービスの可用性は、ユーザ及びサービス運営側にどれだけの不利益を与えたかで定義されるが、計画外の停止時間やシステムの稼働時間など、パラメータが多すぎて難しい。それにしてもすごい。リクエストってそれぞれ価値はことなるはずで、例えば「サービスにログインできない」と「OGP画像が表示されない」を同一のリクエストとして扱っていいのか、など。それをあえてどシンプルに振り切っている。本当にやりたいことに対して最短·最適な効果が出るように設計されている。
エラーバジェットが提供するのは、1つの四半期内でサービスの信頼性がどの程度損なわれても許容できるかを示す、明確で客観的なメトリクスです。(p.37)
第Ⅰ部にも書いてあったとおり、従来の開発／運用チームの課題は、それぞれの目標が対立していることにあった。その間を取り持つ仕組みとして、『エラーバジェット』が提案されている。その名のとおり、四半期内で『損失可能な信頼性』という『予算』を設定する。開発チームは、四半期のエラーをその予算内に収めるようにリリースを行う。これによって、開発とSREとで共通の指標を持つことができる。
これも前述と同じで、指標の単純化にかなり振り切った仕組みになっている。私が関わっている某サービスではNewRelicを使っているが、その中でApdexという指標がある。エラーバジェットとは異なるが、主にパフォーマンスという観点でサービスの可用性を担保するシンプルな指標となっている。基本的には「Apdexがある数値(デフォルトで0.95)を割らないように維持する」だが、とはいえ…みたいなケース（画面）もある。そういった例外的な場合にどう対処するのか、具体例をもっと知りたいと思った。ので、教えてください。
自分たちが計測できることではなく、ユーザが気にすることは何かを考え（あるいは知り）ましょう。(p.46)
サービスの振る舞いに関する目標を設定するとき、ついつい計測可能なものをベースに考えてしまいがち。計測が困難だったり、近似が必要だったりすることも多いが、意味のない指標を追い求めるよりははるかに有益。集計が必要なできるだけシンプルにする。設定した目標を定期的に見直し、修正を加えていく。また、過剰達成を避ける（インセンティブを与えない）。
トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例すると行った傾向を持つものです。(p.51)
toilは、直訳すると「労苦」。本書におけるtoilとは上記の定義。単に「めんどくさい作業」ではなく、自動化できるのにできてない、長期的に価値がない作業のこと。自動化できないということはすなわち『人間がやるべき仕事』ということであり、排除すべき作業とはいえない。GoogleのSREにとって、各エンジニアの作業時間にしめるトイルの割合を50%以下に抑える、という目標があるらしい。逆の見方をすると、Google様クラスのエンジニアでも、放っておけばトイルが50%を超えるということであり、こわい*2。具体的には、割り込み対応、緊急対応、リリース対応の順に多いらしく、これは普段のお仕事の体感とも合致する。自分はわりかしトイルは少ないほうだと思うが、メンバーの中には
トイルの悪い点について、「キャリアの停滞」「モラルの低下」が挙げられていて、意外な角度だと思った。「つまらない仕事からキャリアを生み出すことはできません」エモい。日々の運用作業でついつい仕事をしている気になってしまうが、思考停止にも陥りがち。人間は易きに流れる。運用という性質上、他の業務より優先度が低く設定されて長期的にみると莫大なコストになってしまう。SREという組織がそれを明に目標として持つことで、改善していこうという話。
しっかりと考慮すべきなのは、すべてのページを独立したイベントと捉えるのではなく、ページの全体的なレベルが健全で持続可能なチームと長期的な展望をもたらし、ひいては健全で適切な可用性を持つシステムへとつながることになっているかということです。(p.69)
ページというのはユーザに対する通知＝アラートと読みかえてよさそう。ある特定の機能の問題発生時にアラートメールを開発者に飛ばす場合、そのメール単体ではなく、他のアラートメールや機能に対する優先順位などの位置づけを踏まえ、サービス全体として適切なアラートを設計する必要がある。また、長期的に見ればそのアラートメールの根本原因をつぶすことが最適な場合もある。重要なのは、アラートも機能の一部としてきちんと『設計』する、という考え方。
私たちが面倒を見ているプロダクトやサービスは地球全体に及ぶ規模を持っており、他の組織では一般的なやり方でマシンやサービスの面倒を見るような時間が私たちにはないのです。(p.74)
Google様～～～～～～～！！！です。というのは置いておいて、自動化の話。Google規模になると、運営するサービスにおいて自動化による一貫性、素早さ、信頼性のメリットは非常に大きく、もはや自動化 or 手運用の議論が不要なほど。一方で、我々のような一般人の運営するサービスはそのレベルにはなく、自動化のコストを踏まえて本当に適切化を判断する必要がある。重要なのは、サービスも日々成長していく中で、ある時点で自動化が不要となっても、数日後には自動化したほうがいいという判断にもなりうるということ。都度適切かつ客観的な判断をいれること、その計画をたてておくべき。
Googleにおいて、リリースエンジニアリングは明確に一つの職能と位置づけられています。(p.91)
自分や自分の職場にはあまりない観点だと思った。リリース作業はある程度は自動化されているものの、手作業の部分は残っているし、ヒューマンエラーやいわゆるトイルも潜んでいる。ちょうどひとつ前に書いたとおり、最近のリリース頻度をみるに、がんばって自動化するに足る箇所なのかも、と思った。
私がこれまで行ったコーディングで最も満足感を抱いたのは、その時点でもう意味がなくなっていた数千行のコードを削除した時です。(p.103)
わかりすぎる。わかりすぎて泣く。稼働するサービスに追加されるコードは、その一行一行が潜在的に負債といってもいい。何かの機能を実現するためのコードは小規模かつ単純であればあるほど価値がある。拡張性や耐障害性とのトレードオフともなりうるため、どちらかに傾倒しすぎないように、設計時には単純さの観点もようよう含めるべき。
APIが小さくて単純であるということは、問題が十分に理解されているということの証明である。(p.103)
完全にわかりみ。
外部に向けたWeb APIに限定したものではもちろんなく、クラス設計におけるインターフェイスでも同様。インターフェイスに対してプログラミングをする、というオブジェクト指向の設計原則でもいえることだが、インターフェイスをみて何ができるか、どの場面で使うかがイメージできれば、プログラミングの12割は終わったようなものである。頭ではわかっていても、実際やってみるとなかなかうまくいかない。がんばりたい。
第Ⅲ部 実践
だいぶ具体的になってきたものの、実サービス・組織に直接適用できそうな考え方が詰まっている。
サービスの健全性は、Abraham Maslowが人間の欲求を分類した方法と同様に、システムがサービスとして一通り機能するための最も基本的な必要条件から、自己実現を可能とし、問題に樹頭的に対応するのではなく、サービスの方向性を能動的にコントロールするような、より高いレベルの機能に至るまでの段階に分類できます。(p.107)
かの有名なマズローの欲求段階説と同様に、サービスの健全性も段階的に高次になっていく、というおもしろい発想。一番下の層が『モニタリング』になっているのが響いた。まずはサービスの状態、現状を把握してはじめて、どうしたいかを考え始めることができる。また、最上位は『プロダクト』となっている。信頼性を満足なレベルまで高めて初めて、プロダクトは完成する。耳が痛い。
Googleはまた、DiRT（Disaster Recovery Training）と呼ばれる全社規模のディザスタリカバリのトレーニングを年に一度行っています。(p.138)
緊急対応が少ないシステムはいいことだが、運用不可が低すぎると、いざ問題が発生したときに対応できない。エンジニアは厨二病発症者が大半なので、シャカイに対して斜に構えがちで、避難訓練とかをないがしろにするイメージがある*3。そういうのはやめたほうがいい。人もサービスも死んだら取り返しがつかない。避難訓練と同じで、いかに対象者に価値を感じてもらう避難訓練を設計するかはかなり難しい課題だと思う。ここも各社の事例をもうちょっと知りたいところ。
緊急対応の体制についても、みんなどうしてるんだろう。少なくとも本書では、開発チームとSREチームが独立しており、SREチーム内で緊急対応の当番制になっているように読める。別のやり方として、緊急対応を開発チームで受け持つという形もありうる。問題が発生したときに、その機能に詳しい人が担当したほうが、解決までの速度は速いはず。もちろんコストや体制との兼ね合いでもあるので、その組織にとってベストな設計にすべきではある。
否定的な結果が出た実験は決定的なものです。そういった実験は、プロダクションや設計の領域、あるいは既存のシステムのパフォーマンスの限界について、何らかの確実なことを示します。(p.150)
少なくとも、実験したことは、本番でも同条件下で確実に起きうる。否定的な結果を出し尽くすことは、サービスの信頼性を高めるためにとても有益。また、その結果を公開することで、周囲に価値をもたらす。人間はついつい見えを張って、失敗を見せたくなかったり、よく見せようとしてしまう。本当にチームのことを考えるなら公開するべき。
新たなタイプの障害が発生するたびに、対応者たちはその障害の様子を書き記しました。(p.165)
それなりの規模でサービスを運用している組織なら、障害対応ののちに、次に同様の障害が起きないようにどうするべきか、起きたときにどうするべきかを振り返るはず。重要なのは、振り返りをして満足するのではなく、その実効性を担保すること。ヒューマンエラーなどの場合には「気をつける」などのパッション的な結論に陥りがちだが、そこで深掘りし仕組みに落とし込むこと、それを組織に周知·徹底することまでやりきらなければ意味がない。「その対応を書き記す」というのは、何が起きたかをメンバー間で合意し、対応に応らなかったメンバーにも同レベルの理解を確認できるという意味で、その第一歩といえる。記録を取るというのはどうしても優先度が下がりがちだが、大切にしていきたい。
Googleのインシデント管理のシステムは、明快でスケーラブルであることで知られるIncident Command Systemに基づいています。(p.169)
ICSは、災害や事件の現場における標準化されたマネジメントシステムらしい。知らなかった。読んでみたい。しんどい。
うまく設計されたインシデント管理のプロセスは、「責任の再帰的な分離」「明確な司令所」「ライブインシデント状況ドキュメント」「はっきりとした引き継ぎ」という特徴を持つとのこと。まとめると、「人の判断や責任において、あいまいな境界を作らない」ことに尽きる。だれがいつなにをするべきかを明確に規定し、それを共有できていること、お互いに信頼することが必要。システム設計と同じく組織の設計においても、高凝集、疎結合を意識すべき。
レスポンスに対応している間の自分の感情の状態に注意を払いましょう。(p.173)
インシデント対応の大前提として、冷静·客観的に対応を進めることが必須。感情的な判断は被害を拡大させる。インシデント対応に限らず、自分は自身の感情を把握·制御することが苦手なように感じている。感情を把握·制御するのもスキルのひとつだと思うので、別途トレーニングしていきたい。
ポストモーテム文化を育むための継続的な投資によって、Googleのサービス障害は減り、ユーザ体験を改善できています。(p.181)
ポストモーテムとは、インシデント発生時に、そのインパクトと対応、原因、再発防止策を記録するもの。障害報告書とは異なり、社内のエンジニア間で、同様のインシデントを発生させないための学びを得ることを目的としている。以下3点が重要だと感じた。
- 非難しない: 人間を変えることはできないが、仕組みを変えることはできる
- レビューする: 下書きを広く公開し、客観的情報の記述や対応内容をレビューし、積極的に共有する（参照できるようにしておく）
- 称賛する: ポストモーテムを残すことはトイルではなく組織改善に有益なことなので、適切な報酬を得るべき
この点は某社でも大いに改善の余地がありそう。ちなみにGoogleでは大量に蓄積されてきたポストモーテムを機械学習に食わせて弱点の予測などを行っているらしい。さすが。
テスト対象のコンポーネントには、障害が起こるまで負荷をかけましょう。(p.294)
自分はカスケード障害に備えた視点でのテストがあまりできていないと感じた。
カスケード障害((ポジティブフィードバックの結果として、時間と共に拡大していく障害(p.273)))においては、通常の過負荷による障害と異なり、フィードバックという複雑系の中で、(対象のコンポーネントに限らず)システム全体として何が起こるか予測困難である、という前提に立ったテストが必要となる。
そのため、単に想定される負荷をかけて耐えられることを確認するだけでは不十分。障害が起こるまで負荷をかけることにより、実際に何が起こるのかや、その状態を避けるために割くべきリソースとのトレードオフが議論できる。さらに困難なのは、本番環境になるべく近い環境でテストする必要がある。場合によってはプロダクションテストも検討すべき。
データの完全性を考えるにあたって重要なのはクラウド上のサービスがユーザーから利用可能であり続けることなのです。(p.357)
例えデータは無事でも、ユーザからアクセス不可能な状態が長時間続けば、それはデータがなくなったのと同じ。つまるところ、データの完全性は手段であり、目標とするべきはデータの完全性である、ってはなし。
データの損失は、アプリケーションのバグやヒューマンエラー、ハードウェア障害など、様々な原因がある。あらゆるケースを想定して、なるべく早くリカバリ可能なように様々な手をつくしておく。「多層防御」って言葉かっこいい。そのためには、サービスに求められる安定性の要件（SLO）を定義し、それが満たすことを検証する、という過程が必要。明確かつ合理的な目標値がないと、見えない基準に向かってあれこれ手を出し、不安で夜も眠れなくなってしまう。とにかくテスト。
どんなものもいつかはおかしくなるということを認識できれば、それはあらゆる本物の緊急事態に対して備えるための大きな一歩になります。(p.388)
まさか自分が、まさかうちのサービスに限って、と楽観的になりがちであり、障害の予防は優先度が下がりがち。バックアップとか、だれにも感謝されない。障害が起きたときの甚大な被害は、経験していないとなかなか想像しづらいのが現実かもしれない。システムの安定性要件（SLO）が定義されており、そのテストを含めて担当者を適切を評価すべきだし、経験豊富(なはず)の偉い人がそこを整備し、説いていくしかない。セキュリティとかも同じ。
ローンチが失敗するさまざまな形を予測し、ローンチに関わるさまざまなエンジニアリンググループ間の調整を行った結果、SRE内には特別なチームができあがりました。それがローンチ調整エンジニア（Launch Coorination Engineers = LCE）です。(p.390)
サービスのローンチが頻繁であればあるほど、そのプロセス設計には価値がある。LCEはローンチのプロセスの整備や教育をし、実際のリリース時には旗振り役になり、経験と客観的視点を持ってローンチ作業とその後のサービス信頼性を担保する。
Googleは2004年にLCEを設立している。最先端すぎ。そこから10数年の経験がLCEに蓄積されており、そこから見出した、良いローンチプロセスの特徴が興味深い。「軽量」「頑健」「綿密」「スケーラブル」「適応的」。これらを満たすために、Googleでは、「基本を抑えたローンチプロセスを設計しておき、個別の事情に適宜カスタマイズする」という方策をとっている。がっちがちのルールを設計して運用に乗らなければ意味がないが、クリティカルな障害だけは防ぎたい、という本質的な課題に取り組むことになる。おもしろそう。
本章後半では、LCEが解決しなかった問題も紹介しており、興味深い。基本的に変化に対して弱いっぽい。
第Ⅳ部 管理
初期の学習経験：混沌ではなく構造を提供する(p.414)
これですね。SREに限らず。崖から突き落として這い上がらせるシステムは、教育ではなく選別。対象者はその意義を理解できないまま盲目的に作業するだけになり、何も得られない。特にSREの障害対応は、本番を通じて学習する、という機会がなかなかなく、また実際に起きたときは教育している場合ではなかったりするので、単なるエンジニアよりもさらに教育が難しい。
新人をオンコール担当に導くまでの教育プラクティスが紹介されているが、中でも「ポストモーテムの読み込みと共有」は有益だと思った。障害はなかなか一般論では説明できず個別のサービスに条件が絞られる。そこで蓄積されてきた障害とその対応がまとまっている文書は、唯一の教科書となりうる。そのためにも、そのためにもポストモーテムの整備は価値がある。
また、「ディザスタロールプレイング」というミーティングが紹介されていて興味深かった。過去に起きた障害のシナリオをなぞって、どういう行動をするか、そこからどういう情報を得たかなどを会話で進めていく。Googleでは伝統的にこの演習をやっており、「不運の輪」（Wheel of Misfotune）と呼ばれているらしい。いちいちかっこいい。
生産性が継続的に失われるのを避けるには、作業のスタイルの間で時間を二極化しましょう。(p.434)
主にSREが割り込み作業にどう対処すべきかについても言及されている。二極化するというのは、自分のプロジェクト「だけ」をする時間なのか、わりこみ作業「だけ」をやるのかを自分でわかっているようにせよ、ということ。割り込みをシャットアウトし、集中的に取り組む時間も設ける。メリハリきっちりしましょうってはなし。まあこのへんは本質的かつ永遠の課題。それぞれの環境で試行錯誤しましょう。
第Ⅴ章 まとめ
私がGoogleに加わった時点では数百人だったエンジニアの集団だったSREは、今では1,000人を超えて10箇所以上のサイトに広がり、(p.493)
え、でか。もとからでかいんかい。思ってたよりめっちゃでかい。ここまで読んでて想像していたよりでかい。とはいえ、SREの目的のひとつは信頼性観点でのスケーリングであり、規模にかかわらずあらゆるサービスに必要な考え方ではある。信頼性に価値がある文化を根付かせる存在。
GoogleのインフラストラクチャやSREチームが経験してきた変化や成長にもかかわらず、その発想の誕生から10年が経過してもSREという職務は柔軟で古びることがなく、その目標も当初のままです。(p.494)
裏を返すと、Google様ともあろう存在が10年かけても解決しない課題ともいえる。ソフトウェアに限らず、サービスを提供する上で、信頼性のエンジニアリングは本質的な課題ってこと。たぶん。なので、がんばっていきましょう。
『SQLパフォーマンス詳解』を読んだ
気づけば今年になってから一度もブログを書いていないことに気づいて、あ、やばい、となった。
ゴールデンウィークを持て余しているわけではない。決して。
どんな本か
著者はMarkus Winand氏(@MarkusWinand)。 言わずと知れた"USE THE INDEX, LUKE"の人*1。 訳者は松浦隼人氏(@dblmkt)。GitHub Japanの人。
続きを読む