PyCon JP 2021でLocustについてお話しさせていただきました

10月15日、16日に開催されたPyCon JP 2021にて、「Locust実践編: Pythonで書く負荷試験一問一答」というタイトルで登壇させていただきました。

speakerdeck.com

https://github.com/TatchNicolas/pyconjp2021-locust

最初は資料「日英両方」として申し込みましたが、スライドを作るうちに「これ対訳いれながら見やすさ追求するのしんどくないか？」となり、CfP書いた時の自分を少し恨みました。

自分が登壇する直前まで聞かせていただいていたIkuo Suyamaさんのスライドが日本語版・英語版それぞれで出されてるのをみて、「ああ、なんで思いつかなかったんだろう...」と後悔しました...また内容も、JX通信社でも流行しているFastAPIのパフォーマンス改善についてとても具体的かつ深いことまで発表されていて、とても勉強になりました。

PyConへの登壇は初めてでしたが、事前準備・リハーサル・本番まで、スタッフの方の手厚いフォローもあり、聞きに来てくださった方たちもとてもあたたかく迎え入れてくださって、緊張しながらも無事登壇を終えることができました。

また、当日は1つのトークに1つのDiscordチャンネルがコメント・質疑応答などのために用意されていたのですが、そこへ昨年同じくLocustをテーマに登壇されていた方がコメントを残してくださって嬉しく思いました。

JX通信社としては今年もスポンサーをしており、ブースではミニゲームを用意していましたが、こちらもいろんな人に楽しんでいただけたようでした。

KeyNoteも他の方々のセッションもとても刺激的で、一人の参加者としても目一杯楽しめた2日間でした。FastAPI、asyncioあたりが社内でもよく使われるので、今年は関連セッションがいくつかあってとても学びが多かったです。

今回の登壇にあたっては、社内の同僚にも資料のレビューをしてもらったり、直前は準備に集中できるように業務面で助けてもらったりと、非常に助けられました。

スタッフの皆様、また当日聞きに来てくださった皆様、本当にありがとうございました。

ISUCON練習で雑デプロイのためにGitHub ActionsでSecretsをファイルに書き出した

TL; DR;

  • GitHub ActionsにおいてSecretsの値は echo しようとしても安全のための機能としてマスクされてしまう
  • echo $YOURSECRET > secret_file とリダイレクトしようとしても、**** **** **** となる
  • runnerにpythonがあれば python -c 'import os; print(os.environ["YOURSECRET"])' > secret_file でいける
  • 良い子のみんなは真似しないでね

背景

ISUCONの練習の一貫として、アプリケーション渡されてローカル開発環境とGitHub Actionsによるデプロイ構築をどこまで短時間で出来るか、行き当たりばったりでやろうとしました。

単発のファイル配置やコマンド実行はMarketplaceにいろいろ使えそうなActionsがあるのですが、できれば融通の効くshellscriptを普通に書きたいと思いました。

sshでコマンドなりシェルスクリプトなり実行して、その中で systemdで管理しているnginx/go/mysqlの再起動とかを行いたい。

やったこと

ダメだった方法

`echo $YOURSECRET > secret_file`

SSH秘密鍵を入れて使おうとしても、invalid formatと怒られるので、ためしに当たり障りのない値でcatで試してみたところ、値が *** とマスクされていたようでした。

うまく行った方法

python -c 'import os; print(os.environ["YOURSECRET"])' > secret_file

GitHubが内部でどうSecretの出力を検知しているのかは分かりませんが、上記のやり方でリダイレクトすることで鍵をとりあえずファイルへ書き出すことはできた。

まとめ

チームでやった予行演習ではちゃんとローカル開発環境 + CI/CD作った方がよさそうだったので、明後日も最初の1-2時間程度は問題把握しつつ開発環境整える作戦でいきます。あと鍵の書き出しは御行儀良くなさそうなのと、踏み台越しにしかサーバも触れなそうなので当日の構成みて実際にはやらないかも。

Terraformjp #04 行ってきた

Terraform meetup tokyo#4 - connpass に参加させて頂きました。

「ワールドカフェ」という形式

ツールやプラットホームに対する習熟度や抱えている課題ががいい具合にバラついて、いい具合に揃っていたことが大きかったと思います。

自分が抱えていた課題感としては「CI/CDみんなはどうしてんだろう」「ステート単位どうしよう」という点でした

ざっくり感想を言うと、

  • ワールドカフェ形式おもしろい
    • 抱えている課題や規模感などがいい感じにバラついて、いい感じに似たような境遇の人と話せた
    • うまく回るかどうかは形式自体よりもファシリテーションや参加者同士の相性もありそうで運営は難しそう?
      • 今回は全体の人数が少なく、最終ラウンドでは一度話した方と再度同じグループになったりしましたがその分深い話ができた
  • 自分が「この方法が筋良さそう」と思っている範囲は思いの外狭かった、もっとAlternativeを知るべきだった
    • ある設計の選択を「しなかった」ことの説明ができるまで考え抜けると強そう
  • 「今の自分の組織の状態」「次に目指したい状態」「将来的に目指したい状態」の順番で考えなければいけないなぁというのは、SRENextに参加させてもらったときと本質的に同じ(当たり前かも)
  • Terraformソースコードリーディング会に参加してなかったことに非常に損した気分、次がもしあれば絶対行きたい

CI/CDみんなはどうしてんだろう

これには二つの観点があって、(1) 何を記録として残したいか (2) 実際にインフラを触る人が何人いるか によって色々な意見を聞くことができました。

自分が考えるときに最初に参考にさせて頂いたのはこちらです。

www.slideshare.net

(1) 何を記録として残したいか

Infrastructure as Codeの動機の一つは構成管理の記録を残すことだと思います。

その動機に対して、操作する人が自分だけまたは十分に少ないのであれば手元でapplyしても良いのではとも思いましたが、それだけでは「いつ、誰が、何の変更を適用したか」という操作記録は抜け落ちてしまいます。

terraformであろうとCloudFormationであろうと、(CI/CDに限らず)統一されたワークフローがなければ「コード上はこうなってるけどこれいつ反映されたの(あるいはまだされてないの？」という不確かさが残ってしまいます。

CloudTrailなどで頑張って追いかけることも不可能ではないと思いますが、「せっかくGit管理されていてアプリケーションのCI/CDで使っているツールあるのだからそれに乗っかってしまえばよい」と。

(2) 実際にインフラに触る人が何人いるか

これは、「今インフラに触るのは何人？」という問いと「今後インフラに触る人を何人にしたい？」という問いに分解できそうです。

今回お話させて頂いた参加者さんの中にも「立ち上げ期の数人のチームで自分がまるっと面倒みるし、ワークフロー構築よりもポチポチつくったほうが早い」というケースと「少人数だからこそ最初からインフラも含めたCI/CDをカッチリ作り込んでいる」というケースの両方がありました。

そこから思ったこと

人数が少ない(究極は一人の)場合だと、ブランチが増えたりHEAD≠現在の状態になることも少ないし、正直CI/CDカッチリしなくてもSlackで「今からXXスケールアップしまーす」で済んじゃうこともあるかと思います。

でも触れる人数が増えればいつかは限界がくるし、アプリケーションでは当然のようにやってるなら、シンプルかつ確実に解決する方法としてインフラでもより広めていっても良さそうかも、と考えました。

「自分で作るアプリケーションは自分で動かす」状態を維持したまま、デプロイのスピードを上げるにはどうすれば良いか、今後新たなメンバーを迎えたり、既存メンバーでも担当領域を変えた場合にも「どうすれば最速でデプロイを回せるか」は自分でやっていかないと...

ステート単位どうしよう

モジュールやコンポーネントの単位についても色々な意見を聞けて収穫が多かったです。

ライフサイクルの長さ(Mutable v. Immutable、Dynamic v. Static)は重要というのはある程度皆共通認識で、それらをどうリンクしていくかという話。

「remote stateよりもdata resourceを使うケースがある」というのは自分が参加するまで持っていなかった視点で、自分はremote stateはどんどん使うものだと思っていたのですが、「state間で依存関係を持ってしまうのが気持ち悪い」という考え方もあることを知りました。さらにすすめて、module化もせずにフラットなresourceに書いていく流派もあると聞きました。

せっかくterraform管理下にあるのにremote stateではなくdata sourcesなどを通じて参照するのは「インターフェイスで明示的に宣言されていない属性やメソッドにアクセスする」ような忌避感を自分は持っていました。しかし、「依存先で想定外の変更があった場合、依存元がコケるので気付ける。DynamicなリソースたちとStaticなリソースたちを上手くコンポーネント切り分けておけばいい」という考え方を聞いて納得しました。

「こうするのがよい」「かくあるべき」っていう一つの考えに凝り固まりがちなので気をつけないとなぁと思うなど。

まとめ

  • 上手く回れば参加者の課題や規模などが近いと直接活かしやすい知見を共有できるし、異なる場合は違った確度からの話が聞けて良い
    • 逆に参加者同士がいい感じに協調しないと不発になっちゃうかもしれない、そこは参加者の責任かなぁと
    • 全員が等しく話すチャンスがあることも大事だけど、ある種共犯関係というか、雰囲気で合意があれば「そこもっと詳しく！」が続いてしまうのはアリかも？
      • 初回ラウンドで一人目の自己紹介からすぐに本題に入って話が盛り上がってしまった
      • 結果的に話が深堀りできて面白かったんだけどワールドカフェのガイドラインには則れなかった感
  • 強制的にグループ作って話し始めるのはコミュ障にはありがたい
  • 次は是非ソースコードリーディング会のブログを書きたいなっ

SRENext行ってきた

会社ブログとの連携用にはてな垢作ったけどずっと放置してたのと、今年の目標最低毎月1本と会社Slackで宣言したのでやっていきます。

起源?母体?SRELoungeには一度だけ聞きに行かせてもらいました。そのときのパネルディスカッションや懇親会で聞いたり話したりしたことが衝撃的というか自分にとってすごく得られるものが多かったので、本イベントの告知があってからもずっと楽しみにしてました。

(早めに会場についてTully'sで悠々とお茶を飲みながらOpen＆ヨガ講座待ち...のはずが皮肉なことにこのタイミングでアラートを受けてKeynoteにも間に合わなかったのが悔しい...)

とりあえず当日参加したセッションのメモから思うところをピックアップしてまとめます。

イベントを通して思ったこと

  • 自分は目の前の小さなことに拘泥して、全然大きな流れを意識できてなかったなぁと痛感、とりあえず順番にやっていこうと思った
    1. 「理想と現実のギャップを知る」
    2. 「できることから」「完璧じゃなくても」
    3. 「先をみて決断していく」
  • タスクの分割が甘いから自分の首しめてるのを痛感
  • 「専門職としてのSREは減っていく」はパネラーの方の間でも意見が一致してた
    • 属人化排除と「巨人の方に乗る」突き詰めるとそうなるなぁと
    • 真っ先に思い浮かんだのはこの言葉

※ 以下、スライドの下に色々書いてるのは私の感想であり登壇者さんの発言とは異なる場合があります

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

  • 「段階ごとにできることから」「最初はtoilも障害も受け入れるしかない」って言葉が印象的
  • いま自分が「ああまた防げなかった...」って後ろ向きな気持ちになってしまうことが多かったので
  • ですが「できていないことがあった = できることが見つかった」と前向きに捉えて、とにかくもっと試してみようかと
  • 後半のメルペイにおけるSREチームの変遷の話は、1人から始まって7人体制のチームを率いる立場になるまでの軌跡はこれから自分がやってくべきことだなぁと...

パフォーマンスを最大化するための SRE のオンボーディング事例

  • オンコールのシャドウイングの話は面白かった
    • (よく知らないけど)手術を見学するようなイメージ?
    • 自分が教育実習行ったときも、他教科含めて授業を見学させてもらうことがあった
    • 確かに、やってみなきゃ出来るようにはならないけど、いきなり実際にやるのはハードルが高い
    • その間を埋める方法としてすごく良さそう
  • ざっくりいうと「一人前になってほしい」 は一人前が定義できてこそ言えるよなぁと
    • オンボーディングができる <- タスクがきちんと切り分けられている <- 責務やミッションが明確である

Practices for Making Alerts Actionable

  • ダッシュボードをロールごとに分けているらしい
    • 維持管理が大変そう
    • ロールが違うと技術的にもドメイン知識的にも知ってる範囲や触れる範囲がことなるのでそのほうが良いかも
    • 自分の周囲に目をやると
      • (普段運用系の作業をすることのある人は)メンバー間で触れる範囲に大きな差がない
      • なので、(まだ)ダッシュボードを作り分けなくていもいいかも
  • 構成図とお話にCloudWatchが出てこなかったので、「オンプレから移り変わってきた経緯からOSSベースの監視なのかな？」と思っていたら登壇者さんからTwitterで「使ってるよ！」と補足いただきました

SLO Review

  • ほぼ全員がSLOを知っていても実践できてる人は会場の1/4、Error Budgetまでできてるのは数名
  • Coursera あるの知らなかった
  • 「SLOはあることが大切だ」(某架空の総理大臣をイメージ)
    • 実際、設定しようとして取れてない、メタ情報足りないことに気づくメトリクスもあるし
  • 依存先(クラウドプロバイダ、または自社内部のAPIなど)のSLOを超えることはできない、勝手にそれ以上設定するのは無責任ですらある

スクラムを1年回してSREと開発組織がどう変わったのか

  • 言われてみれば SRE/Devの共依存 と「理想的な協調」って全然違う
  • 自分の周りをみれば、自身はもともとバックエンド開発が中心だし、プロダクトチームも自身でインフラ触れる
    • タスクを誰にでも出来るように分割する の 「誰」にあたる人々のレベルが高いので、分割できてないのは自分の問題感...
    • その点ではある意味恵まれた環境なので、工夫してもっとProductivityとReliabilityのバランスを高く保ちたい

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

(※本記事を書いた時点でスライドの共有は見つからず)

  • ざっくりいうと、Circuit Breakerを含めSLOを真剣に守る仕組みを作ることで、思い切った施策もできるようになる
  • Cookpadさんの規模でも「小さいから何でもサポートすることはできない」という判断をする
    • 自分の環境はもっと小さいので、「制約による効率化」はもっと取り組んで良いかもしれない
  • (bonus talk)
    • on-callシフトは週単位が好きな人、日単位が好きな人、週末入るのが好きな人など色々居る
    • 会社で決めるよりチームで決めたほうが良い

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

  • 終わりのキーノート
  • 「常にデプロイしていれば、デプロイが怖くなくなる」
    • デプロイは別にアプリケーションに限らない
      • サーバのプロビジョニング
      • terraformのapply
  • ざっくりいうと、スピードがないと10デプロイは無理
    • ピーク時、休前日はデプロイすべきではないことも勘案すると意外とデプロイできる時間は短い
    • CI・テスト・ロールバックも含めて、単にアプリケーションを置いて終わりではない
      • ロールバックのためには迅速なエラー検知が必要
      • test in production的な
    • 3分かかってるのが1分になる -> Twitterを見なくなる
  • コード書いた人がデプロイ
    • これは今の自分の環境もできてる(その過程をもっと手軽にすることはできるかも)
    • 最初にそのコード書いた人以外が、もっと気軽にContributeできるようになればなお良さそう