天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

ふりかえりカンファレンスで熊平 さんのkeynote(「リフレクション」って何?)を聞いてきた

ふりかえりカンファレンスに参加してkeynoteを聞いてきたので、その様子を書いていこうと思います。

retrospective.connpass.com

リフレクションの定義

「自身を客観的かつ批判的にふりかえる行為」をリフレクションとして定義するという話がありました。

リフレクションが必要になってきた背景

前例がある時代は、計画偏重でPDCAモデルが重視されてきましたが、前例がないことが求められる時代になったことで、経験が重要なAARモデル(行動→リフレクション→見通し)を高速に回すことが重要になってきて、その文脈でリフレクションが重要視されるように鳴ったという話がありました。

また、これまで結果に対して行ってきた「反省」ではなく、経験や得た学びに注目する「リフレクション」が重要視されるようになってきたということです。

メタ認知とリフレクション

「認知していることを認知する」メタ認知は、意見/経験/感情/価値観の4点セットを活用することで高められるという話がありました。

人々は過去の経験により形成されたものの見方でものごとを捉えるため、同じ情報に触れても同じ意見を持たないということです。

内発的動機を引き出すリフレクション

人の創造力を高めるためには、クリエイティブ・テンション*1を高める必要があるということで、そこにリフレクションが使えるということでした。

ビジョンと現状とのGapを埋める動機の源は、仲間と一緒にプロジェクトを成功させた時などといったやりがいを感じた理由であるということで、小さくてもよいので個々人で動機の源を探求することが重要だということです。(Googleの「情報へのアクセスは民主的であるべき」はまさに動機の源)

主体性のアップデート

これまでは、他人から求められていることに対して積極的に動けることが主体性として定義されていましたが、これからは自分が必要だと思うことに対して積極的に動くことができる主体性が求められているという話がありました。

感情のメタ認知

自身の主体性を見つけるためには、ネガティブな状態でネガティブな感情に対してメタ認知をすることができるとよいという話がありました。

ネガティブな感情は自分自身の「願い」に基づいて起きるものが多く、認知としてもポジティブな感情よりもはっきりとしているため、メタ認知の良い機会になるということです。

感情はおろそかにされがちですが、感情は自身の価値観の認知に先駆けて身体に出るものなので重要だということで、前に紹介された意見/経験/感情/価値観の4点セットが活用できるということです。

ビジョンを語る

ビジョンを語る際、何をどのように実現したくて、メンバーに対してどのような期待を持っているのか?で語られることが多いですが、それはビジョンを語っているとはいえないという話がありました。

ビジョンを語る際には、どうやって実現するのかよりも、なんでそれが必要なのかや、それに関連する経験や感情といったパーソナルストーリーを語ることが大切だということです。

MVVにもあるように、ミッションは共有してそれを行動計画に落とし込み、学びのサイクルを回していくということが重要だということでした。

経験から学ぶリフレクション

経験学習サイクルは非常にシンプルな一方で、質の差が非常に出ていることが気になるという話がありました。

そこで、質を担保するために、想定していた結果と実際の結果を計画(行動計画/仮説), 経験(経験/感情), 学び(経験からの学び/法則の定義/行動計画)の3観点からふりかえることが重要だということでした。

また、質を測る指標として、レベル1は出来事や結果、レベル2は他者や環境、レベル3は自己の行動、レベル4は自己の内面になると捉えることができるということでした。

ダブルルーム・ラーニングとアンラーニング

ダブルルーム・ラーニングは、個々人が持っているメンタルモデルを前提から疑って軌道修正することであるという話がありました。

また、アンラーニングは、アインシュタインの「問題を起こしたときと同じ思考では、その問題を解決することはできない」という言葉にある通り、過去の体験をもとにして形成されたものの見方を変えることだという話がありました。(過去の体験を否定したり消したりする必要はない)
アンラーニングしているときは、新しい物の見方に自分を変えるかどうかという選択をする際が一番大きなストレスとなるため、行動を変えないなら変えないではっきりと選択しておくことがおすすめだということでした。

対話にリフレクションが欠かせない理由

対話は自己内省して評価判断を保留して他者に共感する聞き方と話し方をすることであるため、意見/経験/感情/価値観の4点セットでリフレクションをすることで自己の内面をメタ認知し、内省と共感を起こしていくのが重要だということでした。

また、

  • 個々 × 創造&変化 = 対話
  • 個々 × 現状維持 = ディベート
  • 一体 × 現状維持 = ダウンロード
  • 一体 × 創造&変化 = 共創

だという整理がありました。*2

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

自分たちの会社で掲げられているChange to Changeはアンラーニングと同じなのか?

Change to Changeがよくわからないのでなんともいえないのだが、似ているような気がする

チームメンバの主体性を高めるためにできることはなにか?

まさにチームメンバーのリフレクションを促すことが重要だと思う

アンラーンでは価値観のアップデートがあると思うがこれは無闇にやっていいものではないと思えるのだが、やったほうがいいかどうかという基準はあるのか?

何か誰かに言われているからアンラーンする、みたいなのは奨励できない。
この状態に自分は合わないな、と思った時、「なにをなぜ今手放したいのか?(なぜ違うものを横におくのか?)」というのを考えることが重要だと思う

全体を通した感想

ふりかえりは勿論ですが、想像以上にアジャイルスクラムとのコネクト要素も多かったのには驚きました。
自分もそいうですが、Discordをみていても皆さん自身のいろいろな体験や経験に繋がってくる話が多かったので、そこでもコネクト要素があったのも非常によかったのかな、と思いました。

一方で、個々のトピックがどのようにコネクトしているのかや、個々のトピックが有益な背景や理由付けが今ひとつ腑に落ちない部分もあったので、リフレクションをしてもう一度見直そうと思いました。

*1:ビジョンと現状とのGapを埋めること

*2:ただ、一方的に話すkeynoteはダウンロードで

最後の門番はもう古い!? QA2.0をQA立ち上げ期の2社が語るに参加してきた

timeedev.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

株式会社タイミーは「一人ひとりの時間を豊かに」をビジョンに掲げ、日々の開発を行っています。 そんな私たちが開発を通じて得ている学びを発信することで新しい取り組みを後押ししたり、アンチパターンに陥らない様に出来るのであればそれもまたエンジニア一人ひとりの時間を豊かに出来ているのではないかと考え、定期的に勉強会を通じて我々の学びを発信していく予定です。

今回は株式会社カカクコムとの共催イベントです! 現在、カカクコムでQAの立ち上げを担う伊藤由貴さんをお招きして、タイミーでQAを担う矢尻さんでそれぞれのセッション後にパネルトークを行う予定です。 二人が考える良いQAの在り方やこれからのQAのあるべき姿など見所たっぷりでお届けします! ハイブリッド開催でオンライン視聴も可能ですのでお気軽にお申し込みください!

会の様子

QAがQAしないでQAするために by伊藤さん

QA組織の目指す姿

開発者主体で品質保証に関する活動およびその継続的改善をする姿を伊藤さんは目指しているということでした。
理由としては、

  • 伊藤さんが働いているカカクコムでは、100名程度の開発組織に対してQAは一人であり、QA採用も難しいので、最後の門番となるような体制を作ることができない
  • 伊藤さんは一人目のQAとしてjoinしているので、元々は開発者自身でテストを行っていたのでそこを大切にしたいと思った(QAがテスト業務を「はがして」もどうせQAが見てくれるマインドになるような開発者に悩む可能性もある)

を考えているということです。

目指す姿を実現するための取り組み

上述した体制を整えるために、

  • QA活動の指針としてのQAガイド作成(QA活動について共通してやるべきことやった方がいいことを定義し、品質向上のためにできることを把握するとともに品質向上の土台を作りたいと考えている)
  • 現状把握のためのQAクライテリア作成(QAガイドに即した活動ができているかのセルフチェックリストを用意して開発者に定期的にやってもらうことで、状態を把握している。アンケートは状態把握と共に、じわじわとやるべき活動のメッセージが浸透することを期待している)
  • テストのスキルや考え方のトランスファー(取り入れやすく小さな効果が得られそうな部分を伊藤さんから伝えるとともに、能動的に情報取得できる媒体を用意している)

の2点の活動を行っているということでした。

組織の変化

まずポジティブな点として、QAクライテリアの結果が徐々に改善するとともに、QAへの支援依頼*1や相談が増えたということです。

一方でネガティブな点として、状況を可視化して次の改善活動に向けたパワーが足りていないところと、障害数やリリース速度などの定性成果がまだ足りていないということでした。

駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話 by矢尻さん

開発チームへ飛び込み

矢尻さんはイネイブリングチームにQAとしてjoinしたそうで、ここでは高速に石橋を叩いて渡れるようにQAコーチとして振る舞いをしていこうと最初は考えていたそうです。

モヤモヤの始まり

チームに入ったところ、QAってテストのことだよね?という話や、QAが品質に責任を持ってくれるんだよね?という話、テストは何のためにやるのか?といった話が出ていたことにモヤモヤした矢尻さんは、

  • QAはプロダクトではなくプロセスの品質も見ること
  • QAはテストではなくアジャイルのライトウィングであること
  • QAのケイパビリティは全員にある
  • アジャイルテストの4象限

といった話をしたそうです。

イネイブリングの流れ

上記のような状態だったことを踏まえ、

  • 現在地点を評価してビジョンを共有する
  • アジャイルテストの4象限をもとに戦略を練る

を実施したそうです。イネイブリング活動を行っていくなかでは、「知識は経験から生まれ、意思決定は観察に基づく」というスクラムガイドの一節を大切にしているということでした。

また、教えるための手法としてはアクティブラーニング手法であるThe4Csを使うことを大切にしているということです。

パネルトーク

講演の後はパネルトークがありました。以下、テーマと議論内容を箇条書きかつ常体で記載していきます。

一人目QAは何を学び初手に何をするのか?
  • 既存の文化を大切にしながら、今までの知識や認知を捨てるアンラーニングすることが多い
  • 飲み会をやってとにかく仲良くなった
  • 全チームの代表者とMTGをして、顔合わせ兼ヒアリングをした
  • QAに対して悪い印象を抱いている開発者もいるので、そう思われないように振る舞えたのがよかった
現場のやる気、どう引き出す?
  • 割と上手くいっている状態でjoinしたので、「もっとこういう部分はよくやれますよ」という話をしたり知的好奇心をくすぐるような知識を渡すようにした
  • 心配事を引き出して、その心配事がわくわくに変わるようにするためにはどんなことをすればいい?という話をした
  • マインドマップを使ったテスト設計手法など、細かい道具を渡すとやる気が引き出せることに気がついた
QAとしての成果の計測はどうすれば良い?
  • 4 keysの変更失敗率やインシデント分析を実施している
  • それなりの期間計測できてきた実績がないと意味が薄いと思っている
  • 売上とかにどうつなげて話をするのか?というのは難しいと思っている
QAだと減点主義になりがちだと思うがその弊害はあるか?
  • テストをやる限りにおいては減点のコミュニケーションになりがちなので、バグをハッピーと言い換えるとかは他社事例ではあるがある
  • バグとか障害を見つけたときに躊躇う場面が出てきてしまう
  • 偉い人からの今どうなっているんだ!?みたいなものがプレッシャーになる

会全体を通した感想

きれいにまとめすぎることなく、課題感も含めてやっていることを話してくれていたのが非常によかったです。

1人目のQAとして入ると、どうしても短期的な成果を求めたくなるフォースはあるのかなあと思っていましたが、そこで長期的に活動が必要な部分から入れているのが、すごくいいなあと思って聞いていました。

*1:これやってとかではなく、これを自分たちでやりたいのだけどどうやるといいんだろう?

詳解 インシデントレスポンス - Forkwell Library #48に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

インシデント対応には、様々な専門分野の知識を必要とし、様々な分野のトレーニングを継続的に受ける必要があります。

本書は、セキュリティ侵害を試みる攻撃者の活動に対し、日常的に予防・検知・対応を行う実務家によって書かれた実務家のための書籍で、2022年1月に発売されました。 今回は訳者の石川 朝久 氏をお招きし、本書の概説をしていただいたのち、実践的な技術の学び方や本書に関連する技術の学び方などをお話しいただきます。

また、ブルーモ証券の取締役CTOの小林 悟史 氏、バックエンドエンジニアの下村 拓 氏にも事例講演としてご発表いただきます。

会の様子

セッション1 〜『詳解 インシデントレスポンス』で学び倒すブルーチーム技術〜

ランサムウェアをもとにした事例研究と本の全体感の紹介

ランサムウェアによる攻撃が発生して3台の被害端末が暗号化されていることが判明し、最低限の処理が済んでいるという事例を題材にインシデント対応に関する話がありました。

まず、インシデント対応をする前にはProcess/People/Technologyの「備え」が重要だという話がありました。
具体的には、指揮命令系統やチームへの連絡係を事前に決めておくことなどが挙げられているということです。

次にトリアージパートとして、目に見える被害はないが同じセグメントにいるなど技術的・論理的に考えて被害を受けた可能性があるサーバの取り扱いにまつわる問題(=スコーピング問題)の話がありました。
こういったときはトリアージを実施するということで、具体的な技術としてWMICやPowerShellサードパーティ製品などが書籍内で紹介されているということです。

次に保全パートの話がありました。
本の中では、法医学の文脈にあるロカールの交換原理が紹介されているということで、状況に応じてデータの保存手法や保全対象を選定する必要がある*1ということでした。

続いて、解析パートの話がありました。
解析パートでは、ネットワーク・端末間の分析*2と端末・端末のアーティファクト分析*3が紹介されているということです。

最後に改善パートの話がありました。
解析が終わった後は影響範囲と根本原因が判明した後のアクションが記載されているということで、本書では脅威ハンティングなどの手法が紹介されているそうです。

さらなるブルーチーム技術の向上方法

更にブルーチーム技術を上げたいときの方法として、

  • 技術を磨く(学習向けのイメージを使って分析練習を行うか、ラボ環境を構築して攻撃→分析を行う)
  • 技術をアップデート(DFIR Summitをはじめとしたカンファレンスやブログなどの情報をキャッチアップする)
  • 関連技術を学ぶ(Linuxやモバイル・フォレンジッククラウドフォレンジックといった関連書籍を読む)

の3つが紹介されていました。

セッション2〜東証障害報告書を読み解く〜

障害当日に起こったこと

最初に障害自体の説明がありました。以下、経緯を常体かつ箇条書きで整理していきます。

  • 7:04 : NAS1号機でメモリ故障が発生して異常発生のアラートが鳴った。さらに、NAS2号機への切り替えが起きなかった
  • 7:06 : 一部端末で売買管理画面、運用管理画面へログイン不可となる
  • 7:10 : 富士通に連絡
  • ~7:30 : 処理されるべきバッチ処理が行われていないことを確認
  • 7:37 : 障害対策本部の設置
  • 8:00 : 証券会社から注文が送られてきて受付は正常に処理できたが、売買管理や運用管理画面の操作はできない
  • 8:37 : 全銘柄の売買停止を通知
  • 8:54 : 証券会社とArrowheadとのロードバランサの接続を強制遮断
  • 9:00 : 証券会社との接続は切ったものの、約定処理などは停止できなかった
  • 9:11 : 相場情報配信側のロードバランサも切断
障害の原因(NAS1号機からNAS2号機に切り替わらなかった理由)

パニック通知電文受信時のon_panic設定が間違っていたことが障害の根本原因だったという話がありました。

これは、途中でNetAppの仕様変更が入ったことに追従できていなかった(デフォルトの仕様変更があったことに気が付かなかった)が故に発生したということです。

調査委員会の見解

調査委員会としては、誤った仕様変更をしてしまった富士通の責任は重いと考えつつも、テストケースを作れなかった東証の責任も一定数あると判断したそうです。
一方で事故当日の対応に関しては妥当だったという判断をしたということでした。

再発防止策としては、高可用性を堅持しつつ、障害回復力を高めていくことが上げられたそうで、NASをはじめとしたあらゆる機器の点検や切り替え手段のマニュアル整備、網羅的なテストの実施、市場停止や市場再開のルール整備が挙げられたそうです。

セッション3〜ブルーモのインシデントレスポンス〜

ブルーモでは、疑わしき以上は全て報告することと意思決定は全て文書化することが基本ルールとしてあるそうで、そのうえでレスポンスフローを整備したということです。

具体的には、

  • 手動アラートによるフィルタリングと集約で判断フローを単純化し、Slack Workflowで自動化
  • 判断できる人間が捕まるまでエスカレーションし続ける
  • 異常時はチャンネルを自動作成して、ストック情報とフロー情報を分けて整理
  • ST環境で1週間実験

という部分を工夫したということでした。
インシデントレスポンスを整理したことで、

  • 金融関連かつ少人数の条件でも実践可能なフローは作れる
  • フローを可能な限り単純にしてドキュメント化しても浸透はしない
  • 業務プロセスの導入やヘンコではドキュメント化に加えて実体験とFBの繰り返しが重要

という学びが得られたということです。

Q&A

セッションの後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

インシデントレスポンスを的確に行うための事前準備を知りたい
  • 訓練や教育を重視している。もしこれが起きたら?という観点でディスカッションを頻繁に行っている
  • 障害対応にまつわるいろいろなソースを事前にキャッチアップしておく
  • 事故が起きたときに元気になる人を大切にしている
  • 意思決定をなるべく早く行えるようにする
インシデントレスポンス未経験者はどう本を読んだらいいか?
  • まずは保全の部分を読んでほしい。そのうえで解析パートを読んでもらえるとよい
インシデントレスポンスであったベースラインの把握に効果的な方法はあるか?
  • 毎週定期的に監視して差分をチェックする

会全体を通した感想

セッション1でインシデントレスポンスの話を聞きながら、自分が経験した大きな障害である東証の障害を思い描いていたら、次のセッションで東証の障害の話が出てきてめちゃくちゃ驚きました笑

インシデントは起こる前提で日頃からどのように準備していくのか?という部分は非常に重要なので、そこにまつわる体系的な整理や実践事例が聞けてよかったです。

*1:大量のメモリを搭載し続けているサーバに関してはPCと動揺のメモリダンプの取得は不適切な可能性がある

*2:ネットワークセキュリティ監視、横断的侵害の分類

*3:イベントログ分析、メモリ解析、マルウェア解析、ディスクフォレンジック

オブジェクト指向のこころを読む会 Vol.12

yr-camp.connpass.com

今週もこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

最初にいつも通り読んできた章(12章)のあなたの意見に関してディスカッションをしたあと、今日はモデリングの品評会をしていきました。

会の様子

著者のアレグザンダーへの傾倒

この本の著者は銀の弾丸などないと言いながらも、「アレグザンダーを読んだ結果人生における物事の真価が分かった」「アレグザンダーの理論を適用した結果素晴らしい結果を得ることができる」と言った具合に激推ししているので、読んだときに動揺したという話からスタートしていきました。

あなたの意見2

音楽理論だと、理論通りに進行することが望ましいという話もありつつも、同じくらい意図的に外すというテクニック*1も受けているそうで、人によってこれが好き、これが嫌いみたいなものが分かれているという話がありました。(ただし、現代では外す流れの方が受けている傾向がある)

日本ではAメロ->Bメロ->サビメロみたいなパターンが王道ではありますが、海外ではあまり好かれないというのもあったりして、文化圏の違いも出ているのではないかという話も出ていました。

モデリング品評会

モデリングの品評会をしていきました。
以下、箇条書きかつ常体でそれぞれのモデルのポイントを記載していきます。

モデル1

  • 室外機とかの部分がうまく表現できていない
  • ControllerをかませてModeを操作するようにした
  • operation()を常に回すことで温度を監視&取得するイメージ
モデル2

  • Clientから直接Modeを操作させるのではなく、Controllerを一度かませるようにした
  • 冷房/暖房それぞれが室外機と室内機をいじれるようにしている
  • 具体的なメソッドとかまでは考えられていない

  • ドメイン知識を得て全体的にモデルに反映させた
  • 冷房/暖房それぞれが室外機と室内機をいじれるようにしている
  • 室内機の制御はinterfaceを経由してコントロールするようにしている

  • 空気を調整する際は、冷暖房の変化による調整と温度変更による調整と風量による調整それぞれで違うので、リモコンがModeを直接いじれないようにした
  • 空気の調整は室外機と室内機それぞれがあったり熱媒体の話があったりというのは分かったのだが、理論を理解しきれなかったのでモデリングに反映できていない

  • 浴室のエアコンに対しては適用できない
  • 一部屋に二つエアコンをつけることは想定していない
  • 意図的にエアコンより広いコンテキスト(部屋など)も含めている
  • Stateパターンを将来的に使用することを想定
  • マスタ側のエアコンと操作する側のエアコンを意図的に分けている(アナリシスパターンにあるようなテクニック)

会全体を通した感想

今日は新たにモデリング品評会をやってみて、多種多様なモデルが見れたのでよかったです。
ドメイン知識が足りていなかったり、練りきれていない部分が自分も含めた皆さんがあるということで、次回もやることになったので、今日聞いた話やオブジェクト指向のこころを参考にモデリングを洗練させていきたいと思います!

*1:厳密に言うと外し方にも癖が出ている

大人のソフトウェアテスト雑談会 #206【付け焼き刃】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

出ずっぱりな人々

最近色々なイベントやPodcastなどにEmiさんが出ており、出ずっぱりですよねとおおひらさんとRyoさんが言っていたのですが、おおひらさんもRyoさんも最近ずっと出ずっぱりなので、ブーメランを食らっていました。

知花さんの行動力

知花さんのことを知花さんとみんな呼んでいるのか?里香さんと呼んでいるのか?という話から、知花さんの驚異的な行動力の話になりました。

具体的には、知花さんはコーチンアジャイルチームを読んだあと、特に面識がないのにも関わらずすぐにLyssaに連絡を取りに行ったり、Lyssaに影響を受けてWomen in agileをやりたいと言ってすぐにサポートを求めたりしていたのがすごかったという話を聴いていきました。

森崎先生のイベントはハードルが高い?

森崎先生が生成AIを活用したコードリーディングのイベントを今度開催する予定だそうですが、これの人数を増やすにはどういうことができそうか?という話をしていきました。

前回のイベントは、技術的負債の数値化という意味だとあまり世の中に出ていないトピックなので真新しさがめちゃくちゃあったのに対して、今回はLLMを使ったソースコードリーディングということで、ちょっと検索したら資料がたくさん出てくるのが原因ではないかという仮説や、JavaGoFに詳しい年代とLLMに詳しい年代が違うのではないか?という仮説が出ていました。

他にも色々とノウハウや裏話などが出ていましたが、あんまり書きすぎると色々と妨害行為になりそうなのでやめておきます。

Vim-Easymotionを使ったプレゼンづくり

Ryoさんがふりかえりカンファレンスの資料を作っていたのですが、そこでVim-Easymotionを使いながら資料を作っていました。
途中、トラブルシューティングができる人を探していましたが、誰もいませんでしたw

全体を通した感想

今日は色々とオフレコの話もあったので途中aki.mミュートをかけられる場面もありましたが笑、色々な裏話が聞けたのでよかったです。

そして、いつか知花さんのとんでもない行動力を観測してみたいなと思いました笑

Kubernetesマイクロサービス開発の実践 - Forkwell Library #47に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第47回目では『Kubernetesマイクロサービス開発の実践』を取り上げます。

コンテナ、Kubernetesおよびそれに関連する技術を活用して、アプリケーションの開発と運用を行う方法について解説している本書をテーマに、Kubernetesおよびクラウドネイティブ技術を効果的に活用して実装、運用する方法を学んでいきましょう。

今回は著者の早川 博 氏、監修の北山 晋吾 氏のお二人をお招きし、Kubernetes上で動作するアプリケーションに対して、頻繁な更新とサービスの安定性を同時に実現するための様々なプラクティスをお話しいただきます。 また、モデレータに株式会社サイバーエージェントの青山 真也 氏をお迎えし、さらにDeepなところまで深掘りしていただきます。

会の様子

基調講演1〜マイクロサービスは本当に必要だったのか?〜

K8sの成熟度

2018年にK8s完全ガイドが出たことに加え、SRE/Platform Engineeringをはじめとした運用の役割定義分割が発生していることから、K8sキャズムに入ってきたのではないかな?という感覚で北山さんはいるということでした。

アプリモダナイズへの投資状況

現在は既存アプリケーションをどのようにコンテナ化するのか?という部分に関心が移りつつある*1ということでした。細分化すると、

  • Repurchase(完全に置き換えしたい場合に取る方法)
  • Refactor(アプリケーションを分割してまでビジネスが伸びる見込みがある場合に取る方法)
  • Replatform(移行費用や工数を抑えながら保守性のあるシステムを作るが、システムが古いと改善箇所が増えてしまう方法)
  • Rehost(移行費用や工数はかかるが保守性を最適化したサービスができる)

に分かれるそうです。

移行影響としては、Rehost、Replatform、Refactorの順に高く、コストを抑えながら保守性を高められるReplatformがトレンドの一つになっているということでした。(=マイクロサービスへのリファクタリングというのは実はほとんど行われていない)

基調講演2〜Kubernetesで、アプリの安定稼働と高頻度のアップデートを両立するためのプラクティス〜

近年のアプリケーションに求められるもの

アプリケーションは頻繁なアップデートを理由に様々な理由で再起動されるため、頻繁に再起動があっても安定して稼働し続けることが求められているという話がイントロダクションとしてありました。

具体的には、

  • 十分な準備
  • 意図しないクラッシュの予防
  • GracefulなPodの終了

という3観点に分かれるということでした。

十分な準備

Pod内のコンテナはReadyになるまでにリクエストを受け付けるための準備が必要であるため、アプリケーションごとに対応の必要があるということでした。(DBとのコネクション確立、初期ヒープメモリの確保、キャッシュを読み込む、暖機運転を利用したコンパイラ最適化...)

具体的なプラクティスとしては、initCotainersやPodStart lifecycle hookなどが利用できるということです。

意図しないクラッシュの予防

コンテナの停止をはじめクラッシュの原因も様々ありますが、

  • 負荷試験とチューニングの実施(requests, limitsの設定)
  • GCの特性を踏まえた設定変更
  • 不安定にならないためのlivenessProbe

といった内容が必要だということでした。

GracefulなPodの終了

Podが終了する際は、コンテナの終了&トラフィックの停止が起こる上に動作には決まった順序がないため、preStop lifecycle hookによる待機を活用したり、Gracefulシャットダウンの無効化を設定しておくことなどが重要だという話がありました。

Q&A

基調講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

Rehostを選択して運用が大変になった事例はあるか?

大体大変になる印象はある。IPアドレス周りやログ、セッションレプリケーションなどのトラブルが多い印象はある。

マイクロサービス化はどこまで必要か?
  • アプリケーションの更新頻度を基準に考えると思う
  • 保守性を基準に考える。なお、保守性はチームの技術力にも依存するので、もしK8sを触ったことがないチームなら大きいままでも放っておいた方がいいかもしれない
トラフィックの停止を待つのにsleepコマンドで待っていたが、ネットワークなどを監視してトラフィックがなくなったことを認識してから終了することはできるのか?

アプリケーションのメトリクスをPrometheusのエクスポート的な形で出しておいて、SIGTERMが来たら処理待ちするみたいな連動の仕方になると思われる。ただし、sleepで我慢するほうが結果的に楽になる気がする。

ヘルスチェックを導入している時、DBとの接続チェックは行うべきか?通常通り動作するロジックは提供し続けることはできるのか?

しない方がいいと思っている。アプリケーションが停止したからといってDBが復旧するかはわからないのであまり意味がない気はしている。そのため、DBの状態とアプリケーションの状態は連動しないほうがいいと思う。後半部分はサーキットブレイカーが近いのではないかと思っている。

暖機運転は本当にいるのか?
  • JITコンパイラを進めるという意味だと、暖機運転の手前にやることがあるはずだとは思う
  • シビアにパフォーマンスを求められる環境だと必要な場面は出てくる
商用環境でK8sはどのくらいの頻度でupdateするのか?アップデート対応を効率的にやる方法はあるか?
  • アプリケーション側のE2Eテストを作って段階的なバージョンアップをしていくと早くupdateできるようになるはず
  • 基本は3ヶ月に1回

会全体を通した感想

業界のトレンド的な話や一般的な話を北山さんがしてくれて、実際の業務で使えるプラクティスの話を早川さんがしてくれたので、流れが見事にできていて良いイベントでした。

RefactorよりRehostというトレンドは体感と一致していましたが、正式なリサーチ結果として出ているのは知らなかったので、レポートを読んでみようと思いました。

*1:Research conducted by lliminas参照

スクラムフェス金沢のプロポーザル募集を開始しました!(スクラムフェス金沢の打ち合わせ第10回目)

今日もスクフェス金沢の打ち合わせをして、今日からプロポーザル募集をオープンしました!

ということで、今日はプロポーザルオープンにあたって会話したことをブログにしていきます。

www.scrumfestkanazawa.org

confengine.com

セッション締切日

セッション締切日は元々4月末を予定していましたが、プロポーザル提出までの時間がかなり短いことを元々運営で気にしていたことに加えて当初の締切がGW中だったため、5/8に締切日を設けることにしました。

採択結果の連絡

今回スクフェス金沢の運営メンバーはセッション採択経験がないメンバーが多いということもあり、少し長め(1ヶ月)にセッション採択までの期間を取ることにしました。

また、その結果、スクフェス金沢で残念ながらrejectすることになってしまったプロポーザルをすぐにスクフェス大阪にCloneして回すということが可能であるため、なるべく早く採択か不採択かの連絡はできるといいよねという話が運営の中で出て、「採択のご連絡」ではなく「採択結果のご連絡」を5月中には行う旨を追記しました。

発表場所

他のカンファレンスと異なり、発表場所は全員現地を想定しているため、その旨を明記しました。

初登壇の方の応援

スクフェス金沢では、初登壇の方を支えたいという気持ちがあるため、セッション内容次第ではありますが、初登壇の方を何枠か意図的に採択することを考えています。

そのため、初登壇の方は自分が初登壇であることが分かるようにしてもらいたく、Tagをつけてほしい旨を記載しました。

カテゴリ

金沢カテゴリ以外は過去に実績のあるカテゴリを踏襲していますが、過去に実績のあるカテゴリでも「このカテゴリの話を聞きたい」というのを選びました。

特に、前述したように初登壇の方を応援したい気持ちがあるため、

  • はじめの一歩をいれる
  • この話カテゴリに沿っていないからできないかな...をなくすためにOthersをいれる
  • Advancedセッションが多くなりそうなカテゴリ(新しい提案や実験など)は外す

の対応をしました。

全体を通して

いよいよプロポーザルをオープンにできて、わくわくしています!

期間が短いこともありプロポーザルが集まるかどうか不安に思っていますが、そんな不安がどこかに吹き飛ばされるべく、皆さんからたくさんのプロポーザルが集まることを願っています。