YAMAGUCHI::weblog

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

引っ越し備忘録(2020年2月版)

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。非常事態宣言のまま落ち着かない日々が続きますが、COVID-19が日本で感染者を大きく増やす直前に引っ越しをしまして、そちらに関してはようやく落ち着いたので記録をまとめておこうと思います。

前回の引っ越しのときは前々回の引っ越しの備忘録を見てまったく同じことをしたのでなにも代わり映えがなかったため記録しなかったんですが、今回の引っ越しは前回とは違った作業がいくつか増えたので記録することにしました。前々回の引っ越しの備忘録はこちら。

ymotongpoo.hatenablog.com

引っ越し準備

部屋探し(2019年7月〜2020年1月)

結構厳しめの条件を設定してSUUMOやHOME'Sから来た通知をもとに様々に検討していました。厳しめに設定していたので合致する条件の物件はなかなか見つかりませんでした。別に急いでいるわけでもなかったので不定期にやってくる通知を淡々と眺めるというのを半年くらい繰り返していたら、2020年の新年のある日、家賃以外は条件がかなり良い物件が見つかったため、仲介会社にダメ元で家賃の値下げ交渉をお願いしてみたところ、許容できる範囲に家賃が収まったので引っ越しを決意しました。

契約(2020年1月)

かなり忙しい時期だったので仲介業者にもろもろ丸投げして書面上の手続きは完了しました。入居日が2月1日だったため引越し先の日割り家賃交渉云々は特にありませんでした。退去は2月半ばだったので、それは日割りでの支払いということになっていたので終了。

引越し作業

引越し業者選定(2020年1月上旬〜中旬)

引っ越しを決めたのが1月頭で引っ越しが2月頭というのを決めたのはいいけれど、自分が1月に海外に行く用事が3回もあるため、圧倒的に時間が足りないということで、今回は荷造りも手伝ってもらえる引越し業者を検討しました。前々回の反省以降引越し侍は使わないと決めていたものの、相変わらず引越し業界の慣習である「無駄に電話をかけまくる」「メールやウェブでの調整はほぼ無い」という状態は変わっていなかったので、友人のおすすめからA社、中堅のB社の2社で相見積もりを取らせてもらって、安い方で決めることにしました。

2社で見積もりを取るタイミングが1週間くらいずれてしまいましたが、友人から紹介してもらったA社がB社の見積もりよりも数万円安かったのでそちらに決定しました。B社が先に見積もりに来て、B社の見積もりも交渉をしてだいぶ値引きはしてもらっていました。A社には「B社が値引きしてくれてXXX円という見積もりだったのですが、こういう条件で無理のない範囲でこれよりも低い価格は難しそうということであれば見積もりに来ていただくのはお手数だと思うので遠慮なくおっしゃってください」という連絡をしたんですが、電話口で「いけそうだ」というふうに言っていて実際に見積もりに来たら数万円安い価格になっていました。助かります。

またB者が見積もりに来たときに置いていったダンボールもA社が送り返してくれました。B社にお断りをしたあとは自分で返送しようと思っていたため、業者間での揉め事にならなければいいなと思いつつ、大変ありがたかったです。

A社は「ベスト引越しサービス」という会社です。

荷造り(2020年1月中旬〜2月上旬)

今回は荷造り込みのサービスということではあったんですが、なるべく早く引っ越し作業を進めたいというのと、値引き交渉の際の条件が半分荷造りを行うだったので、荷造りは依然として必要でした。細かな荷物の荷造りをしたあとに、棚などの解体が必要だったり、その間に海外出張・旅行が挟まっていてかなりのドタバタでしたが、引越し当日には食器以外はほぼ終わった状況になっていたので安心でした。

引っ越し当日(2020年2月上旬)

当日は午前中に荷造り担当の人が来てくれて、細かな荷物を全部丁寧に梱包してくれました。皿の梱包とかいままですごく適当で「これは割れるかな...」というような際どい梱包で引っ越しを繰り返していたんですが、今回は緩衝材の使い方などとても参考になるくらいキレイに梱包してもらいました。

午後に実際に荷物の搬出・移動・搬入だったのですが、予想以上に荷物が多かったこともあり一時は今日中に終わらないのではないかと思って追加料金を覚悟していました。結局ちょっと足は出たものの当日中に終わり一安心でした。

搬出中には「要るかも」と思っていたものも、結局次の家に来てから思い切って捨てたりしていたので、教訓として「無駄な大型家具の搬出・搬入は引っ越し時間にも影響を与えるのでさっさと処分する」ことを学びました。

粗大ごみ廃棄1回目(2020年1月下旬、2020年2月下旬)

居住地域によっては粗大ごみの回収受付にかなり時間を要するところもあるため、早めの申請が必要となります。自分の場合もそれに該当して、回収の申請をしても最短で1ヶ月程度先の予約しかできないということがよくあるので、粗大ごみ廃棄の予約をとりあえず引っ越しの諸々が決まる前に、引越し日の前後となる1月末と2月末にそれぞれ1回ずつ申請をしました。

粗大ごみの申請は後からごみの内容に関しては、捨てるものを減らす内容の修正はいつでもできるため,*1、まずは捨てる可能性があるものをすべて列挙し、後述するメルカリの販売にも回しておいて売れたら消す、という運用がうまくいきました。

粗大ごみ廃棄2回目(2020年3月中旬以降)

一度粗大ゴミで捨ててみたものの、なんかもったいないなと思ったのと、部屋が片付いてきて余裕ができたこと、COVID-19の影響で自宅勤務が増えたので気分転換ということで、大型家具をかたっぱしから梱包・発送たのメル便(旧「大型らくらくメルカリ便」)で出品し始めました。

もともと粗大ゴミでだそうと思ってた家具が数千円の利益で売れたので元は大きく取れました。ありがたい。トータルで数万円の利益になりました。

大きいものよりも細かいもののほうが意外と売れるので、宅急便コンパクトの箱をまとめ買いしとくとコンビニに行くついでに出せて便利でした。

各種契約変更

以前は引越れんらく帳を使って各種手続きを終えましたが、次のような話も見たので使うのをやめました。

水道

東京都水道局は引っ越しの手続きをオンラインで行えます。

suidonet.waterworks.metro.tokyo.jp

ガス

東京ガスも引っ越しの手続きをオンラインで行えます。

home.tokyo-gas.co.jp

電気

東京電力でも引っ越しの手続きをオンラインで行えます。

www.tepco.co.jp

引っ越しにあたり東京電力の利用をやめ、転居先では熊本電力にしようと思っていたのですが、本当に1月が忙しすぎたので引っ越して落ち着いてから連絡しようと思い東京電力に転居の連絡だけしました。結局まだ熊本電力には切り替えていません。

kumamoto-energy.co.jp

インターネット回線

引き続きフレッツ光を利用する予定なのだけれども、前回までは116に電話して引っ越しの手続きをおこなっていたのを、今回はメールで行ってみることにしました。

hikari-fiber.com

メールを送ってみると早速次のような自動返信が返ってきました。

f:id:ymotongpoo:20200119202554p:plain

結局電話でした。その後、引越し先に光回線のコネクタがすでに設置済みなので工事の必要がないと言われて安心しきっていましたが、2月1日に引越し先の鍵を渡されて中を隅々まで探してみたらコネクタが見つからず、挙げ句にコネクタがある場所が封印されていたという謎な状況でした。

管理会社に連絡し、木ネジで止められていた板を外してもらって無事に光回線のコネクタにアクセスできたんですが、こういうことは物件を見に行くときに確認しておくべきことですね。

事後処理

各種サービス住所変更(2020年2月~3月下旬)

本人確認書類が必要ではなかったもの

本人確認書類が必要だったもの

特にマイナンバーカードが残念で、引越し前に紛失してしまったので確定申告をしたタイミング(2月上旬)で住所変更と合わせて再発行の申込みをしていたのだけれども、結果受取手続きの連絡が3月下旬に来て、受取の予約をしようと思ったら緊急事態宣言が発令されて結局まだ受け取れていません。

会社

各種公的手続きのために住所変更を伝える必要があるため、住民票の写しのコピー(PDF)を送って連絡完了。あと自分で社内システムで変更できるものは変更しておしまい。

その他

ネットワーク環境改善

元々Google Nest WifiGoogle Wifiを持っていて、これでPPPoE可能だったので、引っ越しと同時にインターネットの終端装置をルーター付きのものからただのONUに変更しました。家には玄関の靴箱の上にある光回線のコネクタがある棚から各部屋にCAT5eで繋げられるようになっていたので、大元をGoogle WifiでPPPoEをして、メインの部屋にGoogle Nest Wifiを置いて、その2つでメッシュを組むような形にしていました。

しばらくはそれで特に不満はなかったのですが、緊急事態宣言のあと明らかに同じマンション内で在宅勤務する人が増え、ネットワークの速度も遅くなったので、IPoEやIPv4 over IPv6での接続ができるようにEdgeRouter Xを買い、ついでに古いイーサネットケーブルを全部CAT6aにし、スイッチングハブも安いものからNETGEARの業務用に変更したりともろもろ改善しました。

今では平日昼でも下りが最低200Mbps、平均で300Mbpsくらいは出ていて、上りのほうが速い状況なので、ストレスなく在宅勤務できるようになりました。

収納棚の整理

旧居に比べ新居は収納が非常に狭い(そのかわり生活空間は広い)ので、うまく棚などを工夫して収納する必要がありました。いらないものはメルカリで売ったり捨てたりできたのですが、やはり棚が必要だということで、アイリスオーヤマのメタルラックとディアウォールと壁美人を駆使して収納スペースを作りました。

アイリスオーヤマのメタルラックは旧居で使っていたものに追加で買い足したので、部材をあちこち移動させながら使いまわしができて、ユニット化した家具の便利さを改めて実感しました。(ルミナスでもエレクタでもいいと思いますが、買うと決めたら同じブランドのものを買い増すのが良いと思います)棚一枚や延長ポールなどをうまく買い足すことで、常に家に合ったサイズで使えますし、要らなくなった棚はメルカリなどでも売りやすいので重宝しています。

2x4家具は作るのは面倒だけど、間取りに合わせたジャストサイズな家具ができるので、DIYを始めたい人にはおすすめです。(自分もこれでDIYにはまり、必要とあればインパクトドライバーと木ネジで諸々組んでいます。)

*1:増やす内容だとトラックの予定積載量をオーバーするため別日の予約をさせられることがある

*2:宅急便転居サービスに登録すると以前の住所への宅配便も転送してくれる。ただし郵便の転居届が完了していないといけない。

*3:https://support.google.com/maps/answer/3093979

Windows 10でApple Wireless KeyboardとApple Magic Trackpadを使う

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。この自己紹介、いつまで続けたらStackdriverの名前よりもCloud Operationsのほうが浸透するんでしょうか。

Magic Keyboard - 英語(US)

Magic Keyboard - 英語(US)

  • 発売日: 2015/10/14
  • メディア: Personal Computers

Apple Magic Trackpad 2 - スペースグレイ

Apple Magic Trackpad 2 - スペースグレイ

  • 発売日: 2018/05/16
  • メディア: Personal Computers

さて、最近COVID-19の影響で強制在宅勤務が続いているので、家の開発環境の設定などをしているのですが、普段は分割キーボードのErgoDox EZを使っていて、最近DUMANG DK6 Ergoを買ってより充実した開発環境を手に入れたはずでした。 ところが、DUMANG DK6 Ergoがどうも製品品質が安定せず、購入したものと交換品の2つがともに右手側が初期不良(ショート)を起こしていて使えないという状況に陥っています。

さらに悪いタイミングは重なるもので、ErgoDox EZの左手側のTRRS端子がどうも接触不良を起こしていて、認識されないようになってしまいました。現状ではとりあえずDUMANG DK6 Ergoの左手側とErgoDox EZの右手側を使うという不格好な構成でしのいでいるのですが、これが続くのはしんどい。

さらに、どちらか片方が更に何らかの問題を起こしたら家で使えるキーボードがなくなる!(メインで使っているデスクトップマシンにはBluetoothのドングルなど挿していない)

というわけで、Bluetoothドングルを購入し、ずっと眠っていたApple Wireless KeyboardとApple Magic Trackpadを奥から引っ張り出してきてWindows 10で使えるようにしました。(上のAmazonリンクは新型だけど、自分が持ってるのは当然旧型)

Bluetoothドングルの接続

買ったBluetoothドングルは正直良くわからないメーカーのものしか在庫がなかったので、Amazonで購入するのが一瞬ためらわれましたが、もう急いでいたので1000円ちょっとだしいいかと思って買いました。

すでに起動しているWindows 10のマシンに接続してみたら普通に使えたので一安心。

Apple Wireless Keyboardのペアリングと設定

次にApple Wireless Keyboardをペアリングしてみます。久々に電池を入れて、電源ボタンを長押ししてペアリングモードに設定。その後「スタート」→「設定」→「デバイス」→「Bluetoothまたはその他のデバイスを追加する」を押したところ、あっさり接続完了。自分はUS配列を使っているので、ネット上で見かけるような変換キーが効かない、などの症状もなく、普通に文章入力できるようになりました。

しかし一点だけ、Apple Wireless Keyboardはcaps lockのキーがAの左にあって、これをcontrolキーにしなければ生産性ガタ落ちです。というわけで、往年のCtrl2capをインストールしました。Windows XPをメインで使っていた頃から思っていたのですが、このツールは行っていることから考えると「Cap2ctrl」が正しいのではないでしょうか。

docs.microsoft.com

それはさておき、こちらをダウンロードしてきて、cmd.exeよりインストールします。管理者権限で行わなければいけないのだけ注意が必要ですが、そちらのサイトにあるようにコマンドプロンプト

$ ctrl2cap /insall

を実行して再起動したら無事に設定完了。

Apple Magic Trackpadのペアリングと設定

こちらもキーボードと同様に電源ボタンを長押ししてペアリングモードに入り、デバイスの追加をするとペアリングまでは簡単に行われました。ところが、こちらはポインティングとクリックはできるものの、スクロールができません。そこで、Appleが配布しているドライバをインストールします。

正しく処理を行うにはBoot Camp用にインストールするデバイスドライバ群をすでにmacOSが動いているマシンからインストールイメージを作成したりしなければいけないのですが、面倒だったので他の方法がないか探していたらWindows 8.1までに対応したデバイスドライバーがAppleの公式サイトで配布されていました。

support.apple.com

公開日が2015年という、かなりの古さのサイトで正直ビビっていましたが、そもそも古いデバイスを使おうとしているのと、Windowsの下位互換性の高さを信頼して、そのまま上で配られている以下のデバイスドライバーをインストールしてみました。

  • AppleWirelessTrackpad64.exe

これをインストールすると、無事に2本指でスクロールを認識しました!無事解決!これでキーボードが壊れても代替で使えるキーボードが確保できたので、安心して使い続けられそうです。

Ubuntu 20.04で右クリックが認識されなくなったので直した

はじめに

こんにちは、StackdriverあらためGoogle Cloud Operations担当者です。製品ブランドが変わると外向きにいろいろお伝えしなければならず、手間が増えますね。

さて、COVID-19により緊急事態宣言が発出されまして、家で過ごす時間が長くなった結果、開発環境周りを整えたりする必要が出てきまして、サブ開発機として使っていたXPS 13'' (9350)にUbuntu 20.04 Desktop + Regolith Linuxを入れ直してi3wmの快適な開発環境として利用していました。しばらくすると突如としてタッチパッドの右クリックが右クリックとして認識されず、左クリックとして認識されるようになってしまったので、それを直したというメモです。

症状

ブラウザを始めとして、多くのPCでのGUIでは右クリックメニューという形で、マウスの右ボタンをクリックしたときにだけ表示されるメニューがあります。いまメインで使っているGoogle Chromeでもそうで、右クリックメニューでウェブページに表示されている画像を直接クリップボードにコピーしたりする便利機能があるので頻繁に使っています。これが使えなくなったわけです。

おかしいと思い、Ubuntu 20.04のデフォルトとして利用されているGNOME設定にてマウスのテストをしてみたところ、たしかに左クリック(主ボタン)として認識されていました。

f:id:ymotongpoo:20200503233751p:plain

GNOME Tweaksのインストールと設定

GNOME設定にはマウスの右クリックに関する設定は主ボタンにするかどうかしかないので、GNOME Tweaksをインストールします。

$ sudo apt install gnome-tweaks

インストールしたあと「キーボードとマウス」の設定で「マウスクリックのエミュレーション」で「エリア」を選択します。

f:id:ymotongpoo:20200503235850p:plain

これで無事に右クリック(副ボタン)が認識されました。

f:id:ymotongpoo:20200504000022p:plain

仕事で出てきた英語の頭字語

はじめに

こんにちは、Stackdriver担当です。Twitterで英語のフレーズのacronymが話題になっていたのでメールとかチャットとかドキュメントコメントとかを掘り返して、まあ大体よく使ってるなあというやつを並べてみました。

仕事でよく出てきたやつ

普通の会話にでてくるもの

  • FYI (JFYI): For Your Information (Just For Your Information)
  • IMO (IMHO): In My Opinion (In My Humble Opinion) → 控えめに主張してる風で、実際は全然控えめじゃないことを言うときの言い訳に使うことが多い
  • TIL: Today I Learned → 「はじめて知った」ふざけて使うことが多い気がする。
  • OH: Overheard → 本当は自分の意見だったりするけど他人が言ったことにするときにも使ったりする
  • AFAIK: As Far As I Know
  • BTW: By The Way
  • WRT: With Regard To
  • EOD, EOW, EOM: End Of Day, End Of Week, End Of Month
  • OOO: Out Of Office
  • WFH: Work From Home
  • EOM: End Of Message → メールのタイトルに内容だけ書いて本文がないことを示す(eg. "OOO: slow to respond. EOM.")
  • OMW: On My Way → ミーティングに遅れてるときとか、カンファレンスで待ち合わせのときとかに使う(eg. "Where are you?" "OMW")
  • ETA: Estimated Time for Arrival/Accomplishment → だいたい適当に書くのでこれよりも長くなることが多い(eg. "Hey, where are you now?" "OMW ETA 2min")
  • AFK, AFC: Away From Keyboard, Away From Computer → 離席中
  • TY: Thank You → 略さないくてもいいでしょ、と思うことがよくある
  • QQ: Quick Question → 「ちょっと聞きたいんだけど」全然Quickに回答できない質問なことがよくある
  • NVM: Nevermind → 最初「なんでNode.jsの管理ツールの話してんの?」って思った
  • TYL: Text You Later → あとでメール/チャットで送る。TTYLがTalk To You Laterなので、その派生。
  • FOMO: Fear Of Missing Out → ぼっちへの恐怖
  • FWIW: For What It's Worth → 役に立つかどうかわからないけどもそういうものとして
  • ICYMI: In Case You Missed It → 「もし見逃してたら」催促するときに緩衝材として使うこともまあまあある
  • IIRC: If I Remember Correctly
  • IOW : In Other Words
  • TBH: To Be Honest
  • IDK: I Don't Know

技術的ななにか

  • LGTM: Looks Good To Me → いいと思います(レビューしてるときのコメント)
  • SGTM: Sounds Good To Me → いいと思います(意見を聞かれたときとか)
  • SG: Sounds Good → 上のやつの更に短い表記
  • WAI: Working As Intended
  • WIP: Work In Progress → 実装中
  • PTAL: Please Take A/Another Look

ビジネス的ななにか

  • POC: Point Of Contact → 連絡先。主に担当者や担当部署を指して使われている。
  • POC: Proof Of Concept → 実現できることを証明するための実装。突然出てくると上のPOCと混ざって紛らわしい。
  • TCO: Total Cost of Ownership → 総保有コスト。購入から破棄までに必要な時間と支出の合計。

たまに忘れるやつ

  • TFTI: Thanks For The Information

SRE NEXT 2020で「サイト信頼性エンジニアリングの原則」というタイトルで登壇してきました #srenext

はじめに

こんにちは、Stackdriver担当者です。先週の土曜日に豊洲フロントで開催されたSRE NEXT 2020に登壇者として参加してきました。

sre-next.dev

どのセッションもすでにSREプラクティスを実践して試されているお話を聞けて、DevOpsの実践方法としてのSRE(Site Reliability Engineering)の広がりを感じられる素晴らしいカンファレンスだったと思います。

自分のセッションについて

sre-next.dev

自分のセッションは「サイト信頼性エンジニアリングの原則」というタイトルでの発表でした。資料は諸事情で一般公開できないのですが、主旨は概ね「SRE サイトリライアビリティエンジニアリング」(通称: SRE本)の書かれていることの抜粋とサマリーだったので、すでに実践されている方にとっては振り返りのような内容になってしまったかと思います。セッションスライド自体の公開を避けているのは、話した内容を伴わずにスライドに書かれている文言だけを切り取られると解釈によってはネガティブにも捉えられないなと思っていることによります。よって、このエントリーでお伝えしたかったことを再度簡単に触れていこうと思います。

なおSREに関するトピックをすべて触れていくとSRE本でもカバーしきれていないほどなので、これがすべてだとは決して思わないでいただきたいです。

単純性と一貫性

信頼性の担保とシステムの改善の両立のためには、変更はすばやく導入し、障害はすばやく戻すことが欠かせませんが、そのために単純性と一貫性が重要な役割を果たすという紹介をしました。

複雑性には必要な複雑性と不必要な複雑性が存在しますが、たとえば複雑性の例としてはpolyglotなマイクロサービスが挙げられるでしょう。プロジェクトにおけるプログラミング言語の選択というのは単にアプリケーションロジックだけではなく、それを実行するランタイムやそれをアプリケーションとしてバンドルするためのビルドシステム、依存するライブラリの更新など、実際にシステムにデプロイするまでに多くのツールやプロセスを必要とします。(以下エコシステムと呼ぶ)また採用やトレーニングといった人的なプロセスにも関わってきます。

プログラミング言語1つにつきそうしたエコシステムが伴うため、扱うプログラミング言語の数が増え扱うものが増えれば、管理にかかる負荷も増大します。プログラミング言語、設定管理方法や扱うOSの標準化を行うことで、SREが管理する技術範囲が限定され、かわりにより深い改善が行えるようになることでしょう。

どこまでを標準とするかは、導入する複雑さが得られるメリットほどの価値があるものかを検討する必要があると思います。すべてのユースケースではベストにならなかったとしても、1つを選ぶことで全体として管理が楽になることは間違いないでしょう。

モニタリングとアラート

モニタリングに関しては、1つの対象に対して異なる方法でのテストをおこなえるのであれば行ったほうが正確な状況を把握しやすい、という話をしました。よくある例はホワイトボックスモニタリングとブラックボックスモニタリングで、前者はシステムの内部情報の点検、後者は外形監視などが挙げられます。

モニタリングを行う理由はシステムの状態の把握と、障害の事前や事後のアクションを行うための通知(ページング、呼び出し)の設定などですが、ページングの設定を行う際の思いやりのなさにより、結果呼び出される側が疲弊することがあります。たとえば次のような場合はページングではなく、より緩い対応で済むはずです。

  • 冗長構成でクラスタ or マシンが1台だけ落ちた
  • 非常に長時間をかけてディスク使用量が95%になった
  • 仮想マシンが基盤クラスターが原因で落ちた
  • 対応しようのない障害

上で「より緩い対応」と触れましたが、たとえばアラート機構にはページングも含めて次のようなものが挙げられます。

  • ページ(呼び出し): オンコール対応
  • チケット/バグ/ダッシュボード: 当直対応、割り込み
  • ログ: 原因調査
  • メール: 後述するが極力使わない

オンコール対応というのは「担当者が寝ていても叩き起こして対応してもらう」ようなレベルのものを指します。SREで重要なのは一部の数字ではなく、ユーザー体験にどれくらい悪影響を与えているかなので、たとえば上記の冗長構成でマシンが1つ落ちたような場合は、引き続きサービスがリクエストを捌けているなら、業務時間中に落ちたマシンの復旧とそ原因を究明すれば良い話なので、この場合はチケットに登録しておけば良いでしょう。

どのレベルでの対応にするか判断のためにも外部プローブ(外部からのDNSクエリやヘッドレスブラウザなどを使ってTTFBの計測など)などのデータをあわせて計測するのが良いでしょう。

で、アラート機構としてメールを推奨しない理由ですが、運用方法によっては解決できる点もありますが、次のような理由が挙げられます。

  • 対応の様子を追跡できない
  • 障害に対するオーナーが不明
  • SN比
  • 人間の警戒に依存

cronや様々なシステムで簡単に設定できるのでメール通知を設定しがちですが、メールは傍観者効果が発生しやすかったり、なまじ簡単に設定できるためにノイズが多すぎて無視されやすくなったりします。inboxが他の業務メールと共通なことも多々あるため、注意深くフィルターしたり携帯の通知の設定も適切に行われなければいけません。こうしたものを運用で改善するよりは、適切なツールを用いたほうが効率が良いでしょう。

モニタリングとアラートに関しては当日 @larufa1 さんがVoyage Groupでの体験を共有してくださっていました。

speakerdeck.com

自動化

SREはトイルをできる限りエンジニアリングで排除するという姿勢で行うものなので自動化は常につきまといます。

たとえば複数のホストに手動でSSHを行って設定しているような処理があれば

pssh -H HOST1 -H HOST2 -H HOST3 "
  apt-get upgrade &&
  /usr/local/bin/make-new-widget.sh &&
  [ -f /etc/widget.cfg ] && echo Success || echo FAIL "

という形で自動化の第一歩が進められます。さらに推し進めていくと例えばGCPなどでは

gcloud compute instances create foo1 \
    --metadata-from-file startup-script=mysite/install-puppet.sh

このような形でスクリプト内に必要な処理を埋め込むことで抽象化のレイヤーを上げていけます。プログラムを書くときと同様に抽象化のレイヤーが上がることでより多くの処理をプログラムに任せられます。

ステートフル vs ステートレス

ステートフルなサービスは名前のとおり「状態」を持つサービスのことですが、「状態」を非常に簡単に定義すると「再生成が難しい一意なデータ」と言えると思います。障害が起きた場合はその「再生成が難しい一意なデータ」を復旧させなければならなくなり、それに備えて専用のバックアップ/リストア機構、また専用のモニタリング機構、アーキテクチャが必要となります。

たとえばMySQLクラスターにおいて

  • マスター(読み書き可): 1台
  • レプリカ(読み込み専用): 複数台

という構成があった場合、マスターノードには専用のモニタリング機構やバックアップ機構が必要になるでしょう。これらははじめのほうで触れた複雑性の議論にも関わってきますが、ステートフルなサービスがシステム内に増えれば増えるほどこうした機構が増えるので、なるべくステートレスなものに置き換えていけるような設計が肝心です。

情報の信頼先

あるシステムの特定の情報を得るために複数の情報ソースがあることは珍しくありません。その場合何を正とするかで判断が変わってきます。時計が1つなら何時か即答できますが、時計が2つだとどちらか正しい時刻か判断できません。

なのでたとえばシステムの状態を把握したいときはなるべく1つの情報源に頼るようにし、それが本当に判断するための情報源として適切か、設計時に判断したいところです。たとえばプロダクションサーバーと退役したサーバーが同居している系から返されるトラフィックのHTTP 2xx系の割合を調べたいときは、一番上流のSLBの層で得られた情報で判断するのが正しいでしょう。

SLOとエラーバジェット

SREで真っ先に出てくるのがSLOとエラーバジェットの概念です。

SLOで可用性99.5%を設定し、それを達成した場合に、これは「100%を0.5%達成できなかった」とみなすのではなく、文字通り「99.5%の可用性を達成した」と同時に「0.5%分システム改善のための余裕がある」という状態であるとみなすことが肝心です。

この0.5%を使ってたとえば

を試せます。可用性の話で言えば、0.5%であれば1ヶ月間に3.6時間が確保できます。たとえばカナリアリリースを実施している場合、これまでそれが起因のダウンタイムがなかったのであれば、すべての変更を canary → stable を経てローンチするのではなく、変更内容の大小やフラグの重要度に応じてカナリアの期間を短くする、あるいはカナリアをスキップするといった選択も取れるかもれません。

3.6時間は与えられた猶予なので、現実としてSLOよりも高い可用性を実現できてしまったとしても、無為にSLOを厳しくしてしまうのではなく、エラーバジェットをより迅速あるいはより堅牢な仕組みの導入のために利用するのが健全でしょう。

逆に厳しいSLOを設定してしまうと、アジリティが確保できなくなる可能性が高くなります。また当然ながらコストも高くなります。(一般的に 9 が一つ増えるごとに倍以上のコストがかかると言われている。)逆に言えばSLO 100%は「動かしたが最後二度と止められない」ということですから、通常のサービス運用ではまず必要のない値です。ユーザーに与える影響を加味しながら、なるべく余裕が得られる値に設定にできるよう、設定値に関して継続的な振り返りが必要です。

補足ですが、SLOの設定やその運用に関しては @chaspy さんが当日話されていました。

speakerdeck.com

テストとロールバック

SREを行う上で「システムは必ず落ちるものだ」という考え方を持つことは多くの場面で姿勢を正しくしてくれます。その一環でたとえばテストやロールバックを正しく行うことでシステム障害からの復旧を迅速に行ったり、障害範囲を限定できます。

  • 漸進的なロールアウト
  • 変更導入後の検証
  • 準備済みのロールバック

たとえばカナリアリリースは漸進的なロールアウトの例で、一部のクラスタ、各クラスタの1台だけ、など、限られた場所にだけ変更を導入して影響範囲を限定してリアルなデータで検証を行えます。問題があれば事前定義されたrunbookを実行してロールバックします。エラーバジェットは有効に使わないといけないので、SLOに影響を与えそうなエラーを発見したらすぐにロールバックして、原因究明のためにエラーバジェットを消費しないようにします。

障害耐性

エラーバジェットの消費として一番もったいないのは障害の復旧作業にそれを充てることです。したがって極力障害が起きないような対策を 打つことでより有意義にエラーバジェットを利用できるようになり(=システムの前向きな改善に使え)ます。

たとえばあるサービスをプッシュしたら空の設定ファイルを作ってしまってしまって、それが原因でサービスの再起動後にサービスが落ちてしまったという障害があった場合に、どうやって障害耐性をつけたらよいでしょうか。

いくつかの改善策が考えられますが、たとえば

  • Gracefulな退役: 新しい設定が読み込めない場合は以前の設定を使い続ける
  • 差分による予防: 設定の差分が単純に20%以上ある場合、あるいは特定のフィールドに変更があった場合には特定の検証プロセスを通るまでプロダクションにプッシュしない

などが挙げられます。

ポストモーテム

SREのおいてポストモーテムは最も重要と言える文化かもしれません。先程も書いたとおり「システムは必ず落ちるもの」と想定し、問題があった場合には人間ではなく「プロセスと技術」に注目して、「プロセスと技術」で改善を行うために振り返りを行います。決して人間を非難しないことが重要です。

たとえば次のようなポストモーテムがあったとします。

  • 事象: グローバルDNS障害
  • 原因: エンジニアが named.conf をtypoして保存してした。それをグローバルにプッシュしてBINDを再起動した。
  • アクションアイテム: エンジニアが次からはもっと注意する。エンジニアはリスクが高い変更を金曜日には行わない。

ここで問題なのは、原因をエンジニアとしていることと、アクションアイテムを人間に依存していることです。また「もっと」のような具体性を伴わない表現がされていることも問題です。原因はtypoをしたエンジニアでなく、typoがある設定ファイルがテストもなしにグローバルに展開されてしまうような仕組みです。またアクションアイテムも、それをどうプロセスやエンジニアリングで解決するかが書いてありません。これは次のように書き直せるでしょう。

  • 事象: グローバルDNS障害
  • 原因: 不正な named.conf がテストなしにすべてのBINDホストにプッシュされた。
  • アクションアイテム
    • 予防(こうした障害の再発をポジティブに防ぐにはどうしたらいいか)
      • named.conf をデータベースから読み込む
      • プッシュと再起動をスクリプト化して、スクリプトに安全確認を組み込む
    • 検出(同様の障害を正確に検出するまでの時間を減らすにはどうすべきか)
      • 監視の頻度を改善する
      • 監視対象の変更
      • ページをより速く行う
    • 緩和(次回この種の障害が起きたときの深刻度や影響度の%を減らすにはどうしたらいいか)
      • リロードして、再起動しない
      • 1つのサーバー(カナリア)だけ他のサーバーよりも速くプッシュするようにスクリプトを変える
      • DNSの機能を分割する(例: 内部 vs 外部、権威 vs 再帰
    • 修正(次回障害が検出されたときにどうすればより速く回復できるか)
      • オンコールプレイブックに起こすべきアクションを追加する
      • すばやくロールバックできるように各ホストの直前の設定を保存しておく

おわりに

こうした内容をお話しましたが、すべてを一度に導入しなければいけないというわけではなく、また何かを行うことでSREという認定が受けられるとかそういうたぐいのものでないので、システムの信頼性を高めるためにこうしたベストプラクティスを少しずつ導入していくのが良いのではないかなと思いました。しかし、とはいえ1つ、これがなければSREではないというものを挙げるとすれば、それはシステムのユーザーに対して信頼性を維持し高めることに貢献しているかどうか、ではないでしょうか。当たり前ですが、そうでなければ Site Reliability Engineering とは呼べないと思います。

SREのプラクティスであるSLOの設定というのはそういう意味では非常に妥当だと考えています。営利企業がITシステムを活用したサービスを提供している場合、会社の成功には必ずユーザーの満足度というのが存在し、経営の中では収益に紐付いた指標(KPI)とその目標値を設定しています。その会社の収益を支えるものがITシステムなのであれば、それらのKPIはSLIと紐づきますし、KPIの目標値はSLOと紐づくはずです。

今回SRE NEXTでは多くの企業がすでにSLOベースの運用をされていて、それらの事例を知ることができ大変有意義だったと感じています。ぜひ次回が開催されることを願うとともに、今後ますますSREのプラクティスが普及し、発展していくことを願っています。

参照

landing.google.com

このサイトに原文ではありますが、”Site Reliability Engineering” と "The Site Reliability Workbook" が無償で公開されていますので、気になる方はぜひ読んでみてください。特に両者ともに気になるトピックだけ拾い読みするだけでも問題ないと思います。

また書籍以外にもSLOのワークショップなどのコンテンツがありますので、こちらもぜひ見てみてください。

なおご存知の通り、"Site Reliability Engineering" は日本語訳版が出ていますし、また "The Site Reliability Workbook" に関しても現在日本語訳版が発刊に向けて最終段階だと聞いております。