くろもワークス

しがないWebエンジニアの日記です。

【ウォーキング】東京エクストリームウォーク50Kに参加してきた

少し遅くなりましたが、3月9日に東京エクストリームウォーク50Kというイベントに参加してきました。

都内を50km歩くというイベントで、エクストリームウォークも50kmという距離も自分にとっては初めてでしたがなんとか完走できました!いまは大丈夫ですが2~3日間くらいは足が痛かったです… www.asahi.com

当日

風はかなり強かったですが、とにかく晴れてよかったです!自分はBブロックだったので、8:18〜からスタートでした。ただ実際は準備できた人からスタートしてよい?みたいな感じでした。

スタート地点

10kmくらい歩いて、隅田川沿いの遊歩道に。

この辺はまだまだ余裕ですが、風が強く帽子はすく飛ばされてるので被るのを諦めました。あと日陰がほとんどないので日差しの照り返しが強く、一応持っていったサングラスが役に立ちました。

永代橋

スカイツリー

隅田川を外れてからは西向きに方向を変えて、25km中間地点の明治神宮のチェックポイントまで。少し疲れてきたけどまだ余裕はありました。

上野駅

東京ドーム

明治神宮のチェックポイント

チェックポイントでは、コーラーやおにぎりお菓子などもらってエネルギー補給しました。ウォーキングでも意外とカロリー消費しているので、チートデイ的な感じでなんでも食べるようにしてます。

チェックポイントから、表参道や代官山を通って目黒川まで。この辺は同じ参加者も近くにいますがカップルや家族連れも多く、「休日にお金払って何やってるんだろ」感を一番感じました。

国立競技場

目黒川

目黒川を抜けて、43kmの朝日新聞のチェックポイントまで。足もかなり痛くなってきて、思い返すとこの辺が一番きつかったです。さすがにチェックポイントだけの補給ではしんどくなってきたので、コンビニでもチョコを買ったりしてエネルギー補給しました。

東京タワー

朝日新聞のチェックポイント

朝日新聞のチェックポイントは室内だったので暖房が効いててよかったです。カップラーメンやチョコなどとりあえずエネルギーになるものをいろいろ頂いて、ラストスパートに向けて10-15分ほど休憩しました。

最後は湾岸エリアをずっと歩いてお台場に戻るまで。チェックポイントで体力も少し回復し。なんとかゴールできました!

レインボーブリッジ

お台場に帰還

記録

ウォーキングのイベントとしては珍しいと思うのですが、リストバンドでの記録計測がありました。最後に記録の証明書を貰えたのですが10時間01分44秒でした。目標は10時間だったのでギリギリ超えてしまったのは悔しかったです😇

ガーミン上の記録では休憩部分も含まれていますが、51.31km歩いて9時間59分19秒でした。途中何度かボタンをミスって押してしまい計測がストップしていないか心配でした。

感想

  • 早い人が多い
    何度かウォーキングイベントに参加していますが、東京エクストリームウォーク50Kは距離が長く慣れている人が多いのかみんな歩くのが早いと思いました。具体的には自分の中では1km9~10分くらいが早いペースですが、全然同じような速度の人がいる感じでした。
  • 孤独の辛さ
    参加者の方は意外と友達同士や夫婦っぽい人も多かったです。自分は一人参加のため淡々と歩くことにはなるのですが、時間も長く最後のほうはだいぶ辛かったので話し相手がいるとよいのかなと思いました。なかなかエクストリームウォークに一緒に参加してくれるような奇跡的な人(?)はいなそうですが…
  • ルートを外れそうになった
    参加者の人はゼッケンを着けているので付いていけば基本迷わないのですが、徐々にバラけてくるのでホームページで公開されているルートの確認が必要な場面が何度かありました。モバイルバッテリーはやはりあったほうがよさそうです。

いったんはウォーキングはお休みなので、しばらくはランニングを頑張ろうと思います!

【ランニング】みさとシティハーフマラソンで10km走れるまで

ここ3ヶ月くらい目標にしていた、みさとシティハーフマラソンの10kmに今日参加してきました。1kmもろくに走れない状態から10km完走できるまでの記録です。

ランニングを始めるまで

気軽なウォーキングのほうが自分は好きで、ランニングは単純に疲れるからこれまでの人生で避けていました。ただウォーキングはどうしても時間が掛かってしまうため20kmくらい歩こうと思うと平日はなかなか時間が取れず、タイパも考えてランニングも始めることにしました。

なにか目標がないとランニングへのモチベーションが上がらないので、「10kmは走れるようにする」を目標に去年の11月くらいに申し込みました。

申し込んでからランニングの練習を初めましたが、走る機会が社会人になってから滅多になかったので、最初のほうは1kmも走ると息が上がってしまう状態でした。

そんな状態でも週に1~2回くらいは走る機会をなるべく作るようにして、徐々にペースや距離を伸ばしていきました。ランニンググッズとかもいろいろ揃えてみましたが、それなりのシューズ(アシックスのGT-2000というシューズ)に変えたのが足が痛くなりづらく、一番効果があった感じがします。

練習を重ねて「1km/6分ペース」くらいならなんとか長い距離を走れるくらいにはなったので、1時間を目標にすることにしました。

記録

会場のセナリオハウスフィールド三郷

完走して、記録としてはぎりぎり目標の1時間を超えるくらいでした!

練習段階では10kmを走れた経験がなく、8.7kmくらいが最長記録で完走できるかも不安でしたが、アドレナリンが出ていたのか完走できました。

風が少し強かったですが、比較的平坦で走りやすいコースでした。ただ残り1kmくらいでの道路をくぐるアップダウンはかなりきつかったです。*1

今後の参加予定

ハーフマラソンも挑戦してみたいですが今の体力では無理なので、ウォーキングと並行してしばらくは10kmで関東近郊のマラソン大会に参戦してみる予定です。次は50分代を目標にしたいですね〜

*1:地図だとこのあたり

【ウォーキング】TOKYOウォーク2023に参加して20km歩いてきた

2023年12月2日に「TOKYOウォーク2023」というウォーキングイベントに参加してきたので、そのときの参加記録です。

www.tokyo-walk.jp

参加理由

去年の入院時期を除いて、ここ1-2年くらいは体重自体は比較的コントロールできているのですが体脂肪がなかなか落ちませんでした(特に一番気になるのがやっぱりお腹周り)。

オフィス出社なら駅の乗り換えだけでも歩数を結構稼げていい運動になるのですが、なかなか機会もないので今年の春くらいからウォーキングを始めました。

とはいうものの、今年は特に暑かったのでそれを理由に6~9月くらいはサボっていました。
寒くなってきて運動するにはいい時期になってきたので、参加費も掛かるウォーキングイベントに参加することで強制的にきっかけを作ろうと思い参加することにしました。

普段も20kmくらいまでなら自分の体力的に歩けることは確認できていたので、今回の「TOKYOウォーク2023」でも一番長い20kmのロングコースに挑戦しました。

当日の流れ

この種のイベントは初めてでマラソンのようなスタートを想像していたのですが、順位を競うイベントでもないとホームページにも書いてあり、都内の江東区木場公園にいって08:30〜09:30の間に受付して順次スタートという流れでした。

歩くことより朝に起きれるかが一番の不安でしたが、9:00ごろに受付できて間に合いました。

なんとなく都心のコースだろうというのは想像していたのですが、コースが事前案内があるわけではなく当日になって紙のマップをもらって確認する感じでした(事前案内してくれるイベントも多いみたい)。

コース自体は普段歩かないコースだったので新鮮でした。基本は歩道を歩く感じでたまに川沿いの遊歩道もあったりで、歩きやすいコースを選んでくれているのかなという印象でした。コース内で曲がったりする箇所は誘導員の方がいたので特に迷うこともありませんでした。

スタート当初はちょっと寒かったですが徐々に暖まってきて、天気も快晴だったので歩くには最高でした!

東京駅のあたり

東京タワーと虎ノ門ヒルズ(?)

佃大橋からの隅田川

記録

4:19:34で完歩しました!特にまとまった休憩は取らずに歩き続けたのですが、まあ普通に疲れました。まだまだ特訓が必要そうです…

ゴールでもらった完歩証

最近ガーミンのvivoactive 5というスマートウォッチを買ったので、今回ウォーキングでは初めて記録してみました。スマホGPSでも記録していますが結構アバウトです。その分ガーミンはめちゃくちゃ正確に記録してくれるので、見返すのが結構面白いです。

今後の参加予定

とりあえず来年の3月9日にある「東京エクストリームウォーク50K」にエントリーしてしまったので、まずは50km歩ける体力を付けようと思います😇 www.asahi.com

ただの腹痛と思っていたら腸閉塞で入院することになった話

どうも、kuromokaです。
遅くなりましたが、あけましておめでとうございます。2023年もよろしくお願いします。年末年始は幸い自宅でゆっくりできましたが、12月に2週間半ほど人生で初めて入院を経験することになってしまいました。

これまで大きな病気をしたことはなく、学生生活や社会人生活を思い出しても、体調不良で休んだことはほとんどありませんでした。ただ今回はその自信が裏目に出てしまい結果として入院、期間も長くなってしまったのだと思っています。

退院から2週間ほどたってだいぶ落ち着いてきたので、改めて振り返ってみることにしました。

入院するまで

入院する5日前くらいから腹痛が始まり、最初はただの腹痛だと思っていました。とりあえず薬を飲んで腹痛は確か治まった気がします。

ただ日が経つについて、今度は何を食べても飲んでも嘔吐するような状態になってしまいました。ついには、

  • 嘔吐する→体から水分が失われる→喉が乾く→水を飲む→嘔吐する…

の無限ループになってしまい、「あ、完全に詰んだな」と思いました。ずっと嘔吐しているような状態だったので、次第にまともに歩いたり話すのも厳しくなりさすがに限界と思い救急車を人生で初めて呼びました。深夜でした。

「なんでそんなに我慢しちゃったの?」

と救急車の中や入院中にも散々言われました。まさにその通りだと思います。当時のバカすぎる自分を殴りたい。

以下が原因かなと思っています。

  • 病院 = めちゃくちゃ体調が悪くなったときに行く場所という認識
  • 今まで体調が悪くなったときは薬で治っていたこと

今回を期にこの考え方は改めて、素直にもっと早く病院に行くようにしようと思いました(当然これから年もとって無理できなくなるので…)

入院1日目〜 腸閉塞と診断される

救急車で病院に運ばれてから、まずひどい脱水状態だったため即点滴を入れられました。
その後、鼻から管を入れられていったん溜まっているのを出そうということで、たくさん嘔吐させられました。ただこれで全部は出なかったので、鼻から再度管を入れられて腸と繋げて、しばらく安静にすることになりました。

今回診断結果としては、腸閉塞とのことでした。おそらく入れられた管は、下のページにも書いてあるイレウス管というやつだったんでしょう。

www.osakacity-hp.or.jp

鼻から管を入れられている間は、絶食で飲み物も飲めませんでした。
点滴があるので生きていることは当然可能なのですが、特に飲み物が飲めないのが辛かったです。喉が常にカラカラで、うがいだけは許可されていましたが、気休め程度でした。

入院3日目〜 透析を受けることに

もし鼻から管を入れる方法で腸閉塞が治らなければ手術するかも、とは言われていてドキドキしていたのですが、幸い腸閉塞は良くなっていきました。

ただ血液検査の結果から、どうやら腎臓も悪くなってしまっているようでした。医者ではないので腸閉塞との関係はよくわからないのですが、脱水状態で尿も出ない状態だったので、きっと関係しているのかなと思いました。

この辺の自分を思い出してみると発熱はなかったのですが、なんかずっとふわふわした感じだったのを覚えています。説明が難しいですが、意識と行動が一致しないような感じで、第2の自分が動いている感覚でした。

腎臓を良くするために、透析を受けることになりました。簡単に言えば体内の血液が汚れているのできれいな血液に交換するためです。透析と聞いて、生活していくために定期的に受けている人の話はよく聞くので、「将来もずっと透析する必要があるのかな」と思っていました。透析をするために股関節のあたりから、血液を交換するための管を入れられました。

www.adpkd.jp

また腎臓の動きをみるために、尿(ちなみに病院では「お小水」とよく言ってた)の量を見たいとのことで、尿道に管を入れられました。尿道カテーテルとか言うらしいです。

言葉のインパクトほど付けるときは痛くないのですが、付けている間の違和感が嫌でした。尿が溜まっているのは見えるけど尿が出ている感覚はずっとなかったです。トイレに行くのは必然的に大のほうだけという生活がしばらく続きました。

透析は日を分けて合計で3回受けました。透析中は特に痛いとかはないのですが、体を動かすのがダメでした。
病院によっては透析中に映画を見れたりするらしいですが、自分の病院では特にそういうのはなかったので、ひたすらぼーっとしているか寝ているかという過ごし方でした。

透析はなんか大きくてとても高そうな機械で、その機械をピッピッピッと操作して、その機械に自分の管を繋げて処置しているようでした。血液が動いているのが直に見えたので、その機械に自分が委ねられていると思うと、何だか人体改造をされている気分になりました。

入院5日目〜 鼻の管が外れて飲み物可に

腸閉塞の方は無事良くなっていったので、鼻から胃に入れられていた管が外れて飲み物が飲めるようになりました。これまでうがいオンリーだったので、喉のカラカラが限界でした。

このときは個室だったのですが、コロナ対策の関係で個室に居る間は病室から出ることができなかったので、とりあえず水や麦茶を買ってきてもらって飲みました。
喉の乾きは治まったのですが、麦茶がいつもよりかなり薄味に感じて「ああ、まだ体調戻ってないんだな」と感じました。

入院6日目〜 薬疹との戦いの始まり

入院にあたって、いろいろな薬や抗生物質を体内に入れることになったので、どれに引っ掛かったかは分かりませんが、薬疹といって身体中に発疹が出るようになりました。これまでこういう経験はありませんでした。

日を追うに連れて、自分で自分の体を見るのも気持ち悪いくらい薬疹がひどくなっていきました。また薬疹の影響で発熱が特に夜になると38.0前後になる日がしばらく続きました。

皮膚科も併設している病院だったため、今回入院したのは外科だったのですが皮膚科も一緒に診療することになりました。今はかなり発疹も消えたのですが完治はしていないため、薬疹は現在も薬で治療中です。

入院9日目〜 絶食解除から退院まで

入院9日目に絶食解除になって、1日3食の食べ物が出るようになりました。といっても最初は流動食といって、ほぼ飲み物みたいな食べ物でした。ただお腹がへる感覚はかなりあったので、何でもいいから食べられるだけでとても嬉しかったです。ただ量は最後まで少なかったです…

食事は最初から普通に全部食べられたので、確か14日目あたりで入院当初から付けていた点滴が外れました。これまで何をするにも点滴棒とお友達で邪魔で仕方なかったので、嬉しかったです。ようやく自由に動き回れるようになりました。

腎臓の方は透析を3回受けてかなり良くなっていきました。もう透析を受けなくてよいことになったため、これも点滴が外れた時期と同じくらいのタイミングで体から管が外れました。やっと普通にトイレができるようになりました。

体調も徐々に戻ってきていたのですが、特に病室ではすることもないのでとにかく暇でした。寝てしまうのが簡単なのですが、ただでさえ消灯が早いのに余計に夜に眠れなくなってしまうので、病院の起床時間から消灯時間(06:00から21:00)の間は寝ないように心掛けていました。

最初は積んでいる本をkindleで読もうとも思ったのですが狭いスマホの画面だと集中力が持ちませんでした。仕方ないのでradikoでラジオを聞いたり、YouTubeを見たり(これを期にプレミアムに入った)、スマホゲームをやって暇を潰していました。

医療費について

退院時に窓口で医療費を払うことになるのですが、結構な期間を入院したのでどのくらい掛かるか心配でした。ただ世間知らずでまったく知らなかったのですが、日本では高額療養費制度というのがあって一定の金額を超えたら後で払い戻される制度があることを知りました。

自分の会社は、関東ITソフトウェア健康保険組合という保険組合に入っていて、限度額適用認定証というのを出せばこの制度によって窓口負担額を減らせるようです。

ただ入院中の病院への書類の郵送が必要なようで面倒そうなので今回自分は申請しなかったのですが(この場合でも後で払い戻される)、結構な額を負担することになったので面倒でも入院中に申請しておいたほうがよいかもしれません。

www.its-kenpo.or.jp

退院後から現在

病院にいるときから薄々感じていたのですが、退院をして久しぶりにシャバに出て外を歩いてみたとき、体力がめちゃくちゃ落ちていることに改めて気付かされました。階段を登るのがとてもしんどく感じました。

自分は身長が180cmくらいで入院前の体重は73kgくらいでした。71kgぐらいがベスト体重と思っているので、軽いダイエットをしていたのですが入院によって強制ダイエットになりました。

家に返ってすぐに体重を測ったらなんと64.5kgでした。たぶん思春期のころくらいの体重に戻りました。そりゃ体力も落ちるよね、って感じでした。

今は体重を戻すべく、入院前は1日2000kcalくらいに食事を抑えていたのですが2700kcalくらいとるようにしています(もちろんまた病気にならない程度に)。ダイエットも経験あるのですがダイエットに比べると体重を増やす作業は食事の選択肢が増えるので、そこはある意味楽しくやってます。

仕事はいろいろ迷惑をかけることになってしまったのですが、退院の次の日から復帰しました。幸いリモートワークだったので次の日から復帰できました。普通にオフィスに出勤だったら出勤で力尽きてしまっていたと思うので、数日くらいはリハビリ期間が必要だったかもしれません。

まだまだ入院前の自分には戻れていないと思っているので、これから頑張って体力を戻そうと思います💪

退院後にすぐ食べたチョコレート
病院では甘い物をほとんど食べられないので、甘い物に飢えていた

PHPerKaigi 2020の参加メモ #phperkaigi

去年に引き続き、PHPerKaigi 2020 に2/11に参加してきました。
この後くらいから例のコロナウイルスでいろいろな勉強会が中止になっていたので、今思うとギリギリでした。

簡単なまとめ

去年もノベルティはたくさんもらったのですが、今年面白かったのは↓のようなカードをもらったことです。

カードをもらえることは自体は知っていたのですが数枚程度と思ってたので、当日少し戸惑ってましたw
だいぶ交換させて頂いたのですがまだ半分以上はあるので、他の勉強会で自己紹介代わりに撒いていきたいなーと思っています。

懇親会は相変わらず超豪華でした!
特にビールは普段ほとんど飲まないのですが、PHPerKaigiのビールはクオリティ高いので今年も何種類か頂きました。(余ったビールは持ち帰りできたので、家で開けようとしたら栓の開け方に苦戦…)

またさっきのカードのおかげで懇親会で話すきっかけを作れるという効果もあったので、その点でも良かったですね。

聞いたセッションのメモ

マスタデータの管理と運用について

https://www.slideshare.net/KentarouTakeda/ss-227566415

  • マスターデータはフロントとバックエンドで使う
  • DB管理は管理画面いる
  • エンジニアでなくても更新できたり管理画面とかがいらないとかの条件を満たした管理方法
    • Excel😂
    • まあそうなるよね、って感じだった
  • PHPだと「PhpSpreadsheet」というパッケージでExcelを扱える
  • ExcelJSONPHP化して、最後のPHP化したマスタデータをアプリケーションから使うらしい
    • JSONだとパースがいるので少し遅い
    • PHP化することでテストコードが書けるので、無効なデータは弾く
    • マスタデータのPHPをautoloadにして、どこからも使えるようにする
  • パフォーマンス
    • OPcacheによって最初は重いが、次は早くなる
    • PHP7.4のpreloadでキャッシュに乗せる

PHPerがこれから「型」とお付き合いしていくために

https://speakerdeck.com/penguin045/phpergakorekara-xing-toofu-kihe-isiteikutameni

  • 前半は型付け言語そのものみたいな話
  • PHPの型
    • 弱い型付けの動的型付け言語
    • 最近は型に関する改修多い
  • 型宣言が性能を上げる
    • PHP8のJITで型宣言の情報を使う
    • タイプヒンティングをすると性能が悪いのは過去の話
  • ケースごとの例
    • ケース1
      • 既存システムの開発者
      • 動的型付け言語として開発されていた
      • レガシーシステムかもしれない
      • 開発環境はPHPStorm
      • 既存システムに型宣言を書くのは難しいので、PHPDocを書いてIDE側の恩恵を受けれるようにしていく
    • ケース2
    • ケース3
    • 既存システム
    • 型は意識していない
    • 型宣言されたライブラリを使うことになった
    • ケースバイケース

PHPPHPを実装する 〜プログラミング言語実装入門〜

https://speakerdeck.com/tzmfreedom/phpdephpwoshi-zhuang-suru-puroguraminguyan-yu-shi-zhuang-ru-men

ぼっちからはじめるレガシーカルチャー改善ガイド 〜はじめの一歩編〜

https://speakerdeck.com/blue_goheimochi/phperkaigi2020

  • 2013/5にオウケイウェイヴに入社。PHP4とPHP5が共存していた
    • こういう話が出るたびに、闇深そうだけどPHP4のプロダクション環境を一度触ってみたいなーと思う!
  • 去年Laravelにリプレースした
  • はじめの一歩の期間
    • 自己研鑽
      • 本を読む
      • ブロク記事を読む
      • ギャップをしる
      • アウトプットして知識として定着させる
        • プロダクトに影響ないところからやっていく
    • 信頼貯金
      • 目の前にあるタスクをやりとげる
      • プラスアルファとなる工夫を加える
      • 目線や視座をあげる
    • 1人目の改善仲間をみつける - なにか改善したいとおもったときに賛同者がいる状態
    • 仲間を見つけられたきっかけ
      • 自分の興味を伝えるコミュニケーションをする
  • そこから次の一歩
    • 次のゴール
      • 3人目の改善仲間をみつける
        • ランチにさそう
        • 勉強会に誘う
        • 社内に向けたアウトプットをする
  • レガシーな文化の改善には時間がかかる
    • できることを積み上げる
    • 同じ志の仲間を見つける

今だからこそ振り返る register_globals

https://speakerdeck.com/gongo/phperkaigi-2020

GitHub Actionsで始めるPHPアプリケーションのCI実践入門

https://speakerdeck.com/fortkle/ga-phperkaigi2020

  • Github Actions
    • 設定ファイルはyaml
      • CircleCIとパット見、かなり似てそう
    • publicリポジトリは無料
    • Github上のあらゆるイベントをトリガーにできる
  • ワークフロー
    • runs-onでubuntuとか指定できる
    • runでコマンドの実行
  • アクション
  • 現実的な使い方できる
  • 各種ツール
    • PHPUnit, phpstan, phpcs
    • composer installしてコマンド実行
  • Github ActionsでPHPアプリをCIするのは、十分現実的な選択肢になっている

SRE NEXT 2020の参加メモ #srenext

遅くなりましたが、1/25にSRE NEXT 2020というイベントに参加をしてきました。

f:id:kuromoka16:20200129040855j:plain

そもそも最近までは「SRE」という言葉自体あまりよく知らなかったのですが、ここ最近この分野の個人的な関心が高まっていることもあり参加してみました。

簡単なまとめ

同時進行のセッションがあったので全部聞けたわけではないのですが、大まかには次のような話が多かったです。

  • SREの概念的な話
  • SREを実践した技術的な話
  • SREの組織的な話

またどのセッションでもしきりに「SLI / SLO」というワードがよく出てきて、決めた指標を元に各社いろいろなSREの取り組みをしているんだなーという印象でした。

懇親会も参加したのですが、話をした限りではSREという組織やチームの中で働いている人は意外と少なく、自分と同じようなバックエンドエンジニアやインフラエンジニアの方が多かったです。

聞いたセッションのメモ

分散アプリケーションの信頼性観測技術に関する研究

https://speakerdeck.com/yuukit/a-study-of-sre

  • さくらインターネットで研究をされている方の発表
  • SREとはなにか
    • 失敗を前提として信頼性を制御する工夫
    • 信頼性低下のリスクを減らすことで変更速度を上げる
  • 失敗のリスクをへらす工夫
    • 事前予測
      • キャパシティプランニング
      • サブシステムの依存関係の把握
    • 事後の最小化
      • 自動回復(フェイルオーバー)
      • アラート
      • 因果関係の特定
      • インシデントの対応体制
      • 高度なデプロイメント
  • 地理的に分散したアプリケーションの信頼性向上というテーマでの研究
    • 既存アプリケーションへの影響を与えないようにする
    • 目的
      • 時間軸方向での可観測性
      • 空間軸方向での可観測性
      • データの一貫性を保証
    • 具体的な研究内容については、レイヤーが低めの話もあり自分には少し難しかった

絶え間なく変化するメルカリ・メルペイにおけるSREの組織と成長

https://speakerdeck.com/tjun/sre-next-2020

  • メルカリとメルペイそれぞれで、SRE組織をどうやって作ってきたか
  • メルカリ
    • マイクロサービス化を進めている
    • chocon
    • 半分近い開発チームはマイクロサービスの開発に関わっていて、SREとしてもその状況を後押ししたい
    • これまでは本番環境を支える「門番」として信頼性向上に関わってきた
      • 今後のマイクロサービス化に伴い、SREチームがボトルネックになるかもという懸念
      • マイクロサービスの開発チームに対応していきたい
    • 専門性の異なる3つのサブチームに分けた
      • SRE Core
      • SRE Edge
      • SRE Advocacy
        • マイクロサービス開発の一員
  • メルペイ
    • @tjunさんが、2018年に1人目のSREとして入社してから現在までの話
    • 2019年の2月にメルペイがリリースされるまでは、なかなかチームとしては動けなかったようで結構苦労してそう
    • 現在
      • エンジニア組織の生産性や運用負荷を改善したい
      • サービスの信頼性を高める
      • 自分ではなくメンバーにできるだけ任せる
    • 組織やチームの段階によってリーダのやるべきことは変わる
    • 最終的にSREチームを超えて、エンジニア組織の生産性と信頼性を作っていく

計画的に負荷リスクを排除するためのキャパシティプランニング

https://speakerdeck.com/sekino/ji-hua-de-nifu-he-risukuwopai-chu-surutamefalsekiyapasiteipuranningu

  • タップルSREの話
  • 全体的に少し駆け足感はあったので、20分ではなくもう少し長い時間でも聞いてみたい
  • 負荷的な観点でセキュアベースになるための取り組みについて
  • 取り組むことになったきっかけ
    • イベント開始のpush通知をきっかけに大量アクセスが発生
    • サービスの復旧に時間がかかった
  • キャパシティプランニングのゴール
    • 継続的なシステムキャパシティの把握
    • 負荷レビューの手順と実施フローの整備
  • 継続的なシステムキャパシティの把握
    • 定期的な負荷試験環境を構築
      • 本番と同様の試験環境
      • AWSアカウントだけ分けて、スペックとか構成は同じにしているっぽい
      • 誰でも使えるようにスクリプトや手順書を作った
    • 負荷試験の実施フローの整備
      • 定期実施
        • 限界値を把握するためのロードテスト
        • 限界値を把握するためのスパイクテスト
          • 固定したECSタスクにスパイクアクセス
            • オートスケールの設定がスパイクアクセスを想定していない設定のため
        • エンジニア主導での実施
          • 性能劣化をチェックするテスト
    • レイテンシSLOを定める
      • ビジネスサイドとの連携にも使用したい
      • APIが遅い環境を用意し、各リーダやPMに集まってもらって「API遅延体感チェック会」を実施
        • こういうのいいなーと思った(小並感)
      • チェック会を元に具体的なSLOを決定
  • 負荷レビューの手順と実施フローの整備
    • 施策単位でのレビューフロー
      • 施策の一覧をSREが負荷的に問題ないかをチェック
        • 施策段階では具体的な情報が少ないので、経験則や体感的なものによる
      • 担当エンジニアによる負荷レビュー
        • 施策の担当エンジニアが実施
        • 手順
          • レビューに必要な情報をプランナーに聞く
            • 施策の概要
            • 施策の想定効果
          • 担当エンジニアが増加するアクセス数の想定を出す
          • 負荷試験結果と付き合わせる
            • ここで定期的な実施が聞いてくるのかなーと思う
        • すべての施策で負荷レビューするのはコストがかかるので特定の施策のみ
    • push通知の設定レビュー
      • サービスをスローダウンさせないように配信するため
      • SREが配信設定をレビュー
      • 手順
        • レビューに必要な情報をもらう
          • 配信ユーザ数
          • 配信時間帯
          • 流入の期待値
        • 想定流入数を出す
        • 想定流入数から必要なスループットを出す
          • 最初のフリックの操作をほとんどのユーザが行うので、このエンドポイント単位
        • スパイクテストの結果を元に配信スケジュールを決定
          • 必要なECSのタスク数
          • 限界スループットを超えている場合はpushを分割
          • ECSにスケジュールベースのオートスケールの設定
  • これらを行ってきた結果
    • push通知や施策のリリースでSLOに違反するようなスローダウンが減った
    • エンジニア主導での気軽な負荷試験の実施

freee のエンジニアは障害から何を学び、どう改善しているのか?

https://speakerdeck.com/manabusakai/what-do-freee-engineers-learn-and-improve-from-failures

  • 障害対応に課題を感じている人が改善のための第一歩を踏み出せそうと思えるようになること
  • freeeの特徴
    • お金や人に関する情報が多い
    • 上場をした
  • 障害へのシビアな対応が求められる
  • ただし新しい価値を生み出す上で障害は避けられないもの
  • 障害にどう立ち向かってきたか
    • 2017年ごろまではフォーマットもバラバラで障害対策の学びも属人化していた
    • 2018年に「SOC1」取得に向けた準備の一貫で、障害対応フローが作成
    • 障害の影響度に応じてレベルを定義 -障害判断のブレがなくなった
    • 2018/10/31の障害
    • この障害をもとに対応を改善
      • 対応の明瞭化
        • 「SOC1」取得に向けて整備した障害対応フローをブラッシュアップ
        • 障害発生時の対応について、「すべて」をまとめたドキュメントを用意
          • 初動対応
          • 障害対応における役割
            • 指揮を取る人や意思決定者は手を動かさない
          • 社内外のコミュニケーション
      • 障害対応エリアを設置
        • ディスプレイがある物理的なスペースを用意
        • 情報を集約して作業のお見合いなどを防ぐ
      • 初動の省略化
        • Slackのbotで障害対応のドキュメントが出るように
        • ポストモーテムの自動作成
        • GASでの社内に連絡すべき人への告知の自動化
  • 障害の学びを広める
    • freeeの開発文化には失敗から学ぶ文化が根付いていた
    • 失敗.js
      • 障害の学びを開発組織全体に共有する場
      • 犯人探しや責任追及の場ではない
      • 障害がなかった月は寿司
    • 割れ窓を改善し隊
    • alertを振り返り隊
      • 直近1週間のalertを振り返りノウハウを共有
      • 障害対応の属人化を防ぐ

SLO Review

https://speakerdeck.com/chaspy/slo-review

  • SLI / SLOを定めることは重要
  • ただし最初は完璧ではない
  • Quipperでのケーススタディ
    • Define the Ownership
      • 日本と海外にチームがあり、それぞれのチームでオーナを決める
    • SLO review by myself
    • SLO review with Devs
      • Dos Detector
        • Dos攻撃対策として503エラーを返していた
        • 設定しているSLIに5xxが含まれているため、攻撃されるとするとすぐに違反になってしまう
        • 代わりに429を返すようにした
      • パスが分からないので送るようにした
      • Envoyでのマイクロサービス間のメトリクスを取得(たしか)
    • Set Error Budget Policy
      • まだ
  • こんなSLIを定めたほうがいいというデフォルトセットを用意しておく
  • SLIの設定はコード化しておく
    • 開発者が簡単に変えられるようにするため

急成長するPairsと共に変化・成長し続けてきたエウレカのSRE戦略

https://speakerdeck.com/kaneshin/how-to-keep-growing-sre-team-at-eureka

Designing fault-tolerant microservices with SRE and circuit breaker centric architecture

https://speakerdeck.com/takanabe/sre-next-2020-c6-designing-fault-tolerant-microservices-with-sre-and-circuit-breaker-centric-architecture

  • Cookpadのグローバルチームでの話
  • Cookpadのレシピ検索の改善として、「Serch v2」と「ML API」を開発
    • この開発チームを「Serch / MLチーム」として、SREとしてどのように改善したのかといった構成の話
  • 最初はMLの研究者と開発者とバックエンドエンジニアがコラボして作業をしていた
    • うまくいかず…
    • 理想と現実のギャップ
      • 技術
        • 新しいプロダクトはpythonk8sを使う予定でいた
        • チームごとに使う技術がバラバラになってしまうのはよくないと考えている
        • ただ機械学習pythonを柄う
      • サービスレベル
        • 実験的な内容をプロダクトに入れたことによるエラーの発生
      • オンボーディングなしで簡単なプロセスで、リリースをできるようにしたい
  • 解決するためのSREチームの具体的な取り組み
  • すべての課題に対してDesign Docsを書く
  • Serch / MLチームの技術選択
    • AWSアカウントやリソースを分けて、本体側に影響出ないようにしてチーム内で自走するようにする
  • 本体側が停止しないようなマイクロサービスの導入
    • サーキットブレーカーを導入
      • サービスが不安定なときにすぐに本体側と切り離せる仕組み
      • 設定したしきい値を超えたとき、マイクロサーヒスへのリクエストを遮断(503を返す)
      • ヘルスチェックの結果をもとに元に戻す
    • TraefikというGo製のツールを使っている
    • サーキットブレーカーのしきい値をどうやって決める?
      • SLOをもとにする
      • なにをSLOにするかは難しいのである程度のプリセットを用意しているらしい
    • しきい値を超えたらサーキットブレーカーによって、リクエストが遮断されるコンセンサスをチームと取る
  • オンコールからの開放
    • サーキットブレーカーで切断したあとに自動的に古いプロダクトに戻すことで、手動での対応を不要にしているっぽい
  • 実験的な内容のリリース
    • リクエストパスごとに、新旧のプロダクトを切り替える

サイト信頼性エンジニアリングの原則

  • SREの何たるが全然分かってない自分にとっては、エラーバジェットなどの説明や具体例も一緒に話してくれたのは非常に分かりやすかったです。
  • スライドは公開されてないですが、登壇した@ymotongpooさんのブログ記事があったので、こちらをメモ代わりに貼っておきます。

ymotongpoo.hatenablog.com

Webサービスを1日10回デプロイするための取り組み

https://speakerdeck.com/fujiwara3/sre-next-2020

  • 内容はタイトルの通り
    • こういう闇を改善していく話は聞いてて面白い
  • Lobiのサービスでの取り組み
  • 1日10回デプロイしたい
    • 以下すべてをデプロイと定義
      • サーバサイド
      • フロントエンド
      • EC2のプロビジョニング(Chef)
      • AWSの構成変更(Terraform)
    • 修正や機能追加や削除はすぐにデプロイしたい
    • 常にデプロイしていればデプロイが怖くなくなる
  • 1日に何時間使えるか
    • 営業時間内(9時間)
    • 営業時間外や休日の前の午後は基本的にデプロイしないようにしている
      • 夜のピークタイムに問題が発生
      • 夜間バッチで問題が発生
      • ユーザからの問い合わせが休日に増える
  • 7時間で10回デプロイするには
    • 1回のデプロイに使える時間は30分以下
    • 1回1回のデプロイの高速化
    • 専任の担当者を作らずだれでもデプロイできるようにする
    • いつなにがデプロイされたかを記録する
  • 以下のデプロイの要素を早くする
    • CI
      • テストが通ってないものはリリースできない
    • ビルド / 配付
    • エラー検知
    • ロールバック
  • CI高速化
    • 本体APIPerlでのモノリスなアプリ
    • アプリケーション26万行 + テスト26万行
    • 実際にMySQLやRedisを起動してテストをしている
    • 何も考えずにテストを実行すると日が暮れるとか…
    • 並列化を行い10分で終わるようにした
      • 10分だとpushをしても他の人のテスト待ちで10分以上掛かる
      • ローカルで修正箇所だけテストをするようにしたりしたが、pushして全部をテストするとこけたりしていた
      • 緊急対応時にもどかしい
    • Jenkins → Circle CIにして、コンテナの並列化をした
      • 10分から3分になった
      • PRを作ってから説明を書いているうちに、CIが終わるようになった
    • Circle CIのイメージはus-east-1に置くようにして、Circle CIの実行環境と物理的に近くなるようにするとよい
  • ファイル配付の高速化
    • 2010年〜
      • EC2のデプロイサーバから各ホストでgit pull
    • 2013年〜
      • デプロイサーバから各ホストにrsync
      • 10並列でrsyncしても終わるまで3-4分
      • この方法だとオートスケールへの対応がやりにくい
    • Stretcherを開発
      • https://github.com/fujiwara/stretcher
      • デプロイの配布物をS3に置くようにして、各ホストでStretcherコマンドでS3から取得して展開するようにした
      • オートスケールで起動したホストもS3から取得して展開
    • rsyncの3-4分から、1分程度に短縮
  • エラー検知
    • デプロイはエラーがないことを確認してからでないと完了にならない
    • ログから問題を検出する仕組み
    • NorikraでログにSQLクエリを投げれるようにした
    • ログ検知を適切なwindowsで実行する
      • エラーが大量発生しても1分に1回だけ通知する(通知が膨大に来ないようにするため)
  • ロールバック
    • デプロイして問題が発生したらすぐに戻したい
    • いままでのフロー
      • リバートのPR作成、レビュー
        • 間違ったコミットをリバートしていないか
      • リリースブランチにマージ
        • CIの待ち
      • デプロイしなおし
    • どう急いでも5分以上かかっていた
    • Stretcherでロールバック
      • デプロイ前の直前の成果物がS3に残っている
      • 直前のURLを指定すればロールバック完了
    • 30秒でロールバックが完了するようになり、人間が介入しないのでミスしないようになった
  • 誰でもデプロイできる仕組み
    • これまでは特定の担当者がデプロイをしていたが、コードを書いた人がデプロイできるようにする
    • Rundeckを使った
    • デプロイ履歴の管理にghch
    • Slackbotによるデプロイの管理
      • テストが通ってなかったり時間外のデプロイを行おとすると警告する
  • コンテナ移行後のデプロイ

VS Code Meetup #1 で登壇してきた #vscodejp

この記事は「Visual Studio Code Advent Calendar 2019」の19日目の記事です。

12/18に以下のイベントでLTをしてきました。

vscode.connpass.com

スライドはこちらです。

発表内容について

「初回基礎編」というサブタイトルだったので、「2年半VSCodeを使ってきて意外と知らなかったこと」という題目で、あまり難しくない基礎的な内容にしました。
自分がVSCodeを2年半使ってきて「え、こんな機能あるの?」と思うことがたびたびあり、そういう機能を紹介するような内容です。具体的には以下の機能について紹介しました。

ワークスペース

ワークスペースを使うとフォルダを2個同時に開くことができます。これを知るまでVSCodeも2個開いてたという話をしたら、結構同じ方がいるようで安心しました!

詳細検索

検索パネルの右下にある「…」みたいなボタンを押すか、フォルダー内検索をしたときに有効化になる機能です。
通常の検索では全体を検索しますが、詳細検索では検索対象に含めたり除外したり*1するファイルやフォルダを指定することができます。

Git機能

左バーの分岐マーク(でいいのかな?)を押すとソース管理のパネルが開き、コミットや変更を戻すなどの操作ができます。ブランチの作成や切り替えなどは左下のブランチ名を押すとメニューが出てくるので、そこからできます。

タスク

任意のコマンドをタスクとして登録しておくと、VSCodeからそのタスクを指定して実行できるような仕組みです。作り方はスライドに書いてあるのでご参照頂ければと思います🙏
当日は@sakkuruさんが、LT前のセッションでタスク機能の説明やデモまでしてくれたので、発表ではあまり細かくは触れませんでした。

その他もろろろ

と称して、ペラ1のスライドで以下の3つの機能を紹介しました。

選択範囲のみ検索

ファイル内を「command+F」で検索するときに、デフォルトだと選択範囲がある状態でもファイル全体が有効になってしまいます。
右の方にある棒グラフみたいな謎ボタンを押しておくと、選択範囲のみを対象にして検索することができます。

マルチカーソル

「option+クリック」をするとカーソルを増殖させることができます。複数行や複数箇所を同時編集したいときに便利です。
ただ実はこれは一例で、マルチカーソル機能は結構奥深く私もまだまだ使いこなせてはいません。以下の記事がとても詳しく説明されていておすすめなので、ぜひ見てみてください!

mugi1.hateblo.jp

Compact folders

これは機能というよりまあ設定なんですが、最新の1.4.1のバージョンで新しく入った設定です*2
デフォルトが有効なので気づいている方も多いと思いますが、子供のフォルダが1個しかないときの表示が変化します。

反響

まず反響がとても多く正直驚きました。LT直前にスライドをツイートしたのですが、拡散していただきありがとうございます!

はてブのホットエントリーにもなって、一時的に「テクノロジー」カテゴリの一番上にも掲載されたのでキャプチャを残しておきました。

f:id:kuromoka16:20191219193333p:plain

そんな中で良い反応もあったのですが、「内容が薄い」って反応もチラホラあり、これについては完全同意で反省点かなーと思っています😢
5分間のLTという時間の中で、多くの機能を紹介しようとしたので個々のスライドでの説明が薄くなってしまったかな、と感じています。逆に言うと今までの登壇活動ではこういう指摘をもらうほどの反響がなかったので、今後の登壇を改善していくための良い機会と捉えていきたいと思っています!

全体的な感想

まずVSCodeは自分がとても好きなエディタで、そういったVSCodeに関する勉強会の1回目に参加して登壇できたことはとても光栄でした!今後2回目、3回目と続いていくとのことなのでとても楽しみです。
LTの登壇者にはイケてるバッチをもらえたのもよかったです!

今回は「初回基礎編」 で、次回は「Live Share編」とのことで*3、全然使ったことない機能なので登壇はお休みして、一般参加として参加できたら勉強をしにいく心構えで行くつもりです。もしまた登壇する機会があったらぜひ登壇したいなーと思います!

*1:スライドでは除外のことしか書いてないのに、例は含めるの方を紹介するようなキャプチャになっていますね、すいません!

*2:https://code.visualstudio.com/updates/v1_41#_compact-folders-in-explorer

*3:https://vscode.connpass.com/event/160083/