SRE兼スクラムマスターのブログ

チーム開発が好きなエンジニアブログです。検証した技術やチームの取り組みを書いていきます。

チームサポートするにあたって心掛けていること

はじめに

社内で新しいチームにをサポートしていくことになりました。 チームリーダーの方やマネージャーと「1 on 1」を実施して、抱えている問題や 自分が協力できそうなことを話し合い、7月から本格的にサポートしていくことになりましたが、自戒の念を込めてサポート時に心掛けようとすることをいくつかまとめておこうと思います。

心掛けていること

この内容がすべてではないですが、チームサポートするにあたって、とくに初期段階でおろそかにしないように気をつけたいことになります。

サポートに徹することを明確にする

自分がチームサポートする時に、「チームが、良い方向に進められるように全力を尽くします。しかし、実際に良いチームを作るのは皆さん自身です。」ということを伝えるようにしています。チームメンバー自身に 良いチームを作る意思がなかったり、サポートに参加する自分がすべてを決定するようでは、最終的に自己組織化されたチームが生まれにくいからです。 自己組織化するために必要なチームの対話や、メンバー間のコラボレーションについては、知識やスキルが必要になるので実践の方法やアクティビティについてアウトプットするようにしています。

チームの目標を統一する

チームの目標について共通認識をもつようなプラクティスを実施するようにしています。なぜならば、これまでのチームサポートの経験では、 「目標が人によってバラバラである」 「目標が明確でも達成するための道筋は不明瞭である」 といった状態が多く、総じて同じ方向を向いてることが少ないです。

その場合は「インセプションデッキ」を使って目標、これからの進め方について議論し、理解し、合意するフェーズを設けています。 しかし「インセプションデッキ」は時間のかかるプラクティスで、チームによっては、そのようなイベントに抵抗がある場合も多いです。そういったときは、ふりかえりでも使われる「帆船」を使って自分たちの目標や立ち位置を明確にしていただいてます。

インセプションデッキ」や「帆船」の詳しいやり方は説明しませんので こちらの記事を参照してください。

takaking22.com

note.com

メンバーの価値観を可視化する

同じチームでコラボレーションしてくには、メンバー間で得意なことや 大切にしている価値観を開示していることが大切です。これを実現するために 自分がよく取り入れているのは「ドラッカー風エクササイズ」です。 実践することで 「何に対してモチベーションを感じるのか?」 「どういう部分で協力があると良いのか?」 という点で、メンバーに伝えることもできるし、言語化することで自分自身にも新しい気づきが生まれます。

ドラッカー風エクササイズ」詳しいやり方は説明しませんので こちらの記事を参照してください。

tech.pepabo.com

アジャイル」という言葉を使わない

これも経験談ですが、「アジャイル」という言葉を使わない方が割とうまくいくことが多かったです。これに関しては「アジャイル」のみならず、新しすぎる横文字なども多用しないようにしています。 その理由は、下記の2つではないかと推測しています。 「過去にアジャイル手法だけやって、うまくいかなかった」 「大きな変化を求められているようで抵抗感があった」 前者は、何度か見てきたことがあるのですが人は一度うまくできなったことに対してもう一度チャレンジするのは心理的にハードルが高いからです。 後者は、自分たちのこれまでのやり方が否定されているように感じるからだと思います。 私自身「アジャイルをやろう」というフレーズは、本質を見誤っているようで好きではないです。自分たちが働きやすく、成果を届けられるようにカイゼンを続けた結果「アジャイルな状態」になっていた!くらいがちょうどよいと考えています。

まとめ

久々に新しいチームのサポートをすることになったのでだいぶ緊張しているので サポート時に気をつけたいことまとめました。 まとめていて思ったのはフレームワークやプラクティスを適用する時は チームの成熟度に合わせることが重要ということです。 1つのチームでうまく言った方法が全てのチームでうまくいくと考えると大変なことになるので肝に銘じてやっていこうと思います。 自戒のために心がけをまとめてみましたが、「こういうのも大事だよ!」っていうのがあればコメント頂けると嬉しいです

「1 on 1」ふりかえったら自分のためになっていた

はじめに

去年の9月に新チームが発足し、チームメンバーに何かできることがないかを考えたときに「1 on 1」という選択肢を選択しました。 そこから「1 on 1」を始めて半年以上たちましたので、やってきたことをふりかえり、気づきをまとめようと思います。 これから「1 on 1」を始めてみようという方や迷っている方の参考になればと思います。

ふりかえり

ふりかえるために、頭の中で考えていたことを「マインドマップ」で表現しています。

ここから各項目について文章でまとめておきます。

※ツールはMiroを使っています。

1 on 1 マインドマップ
マインドマップ

背景

1 on 1をはじめたもっとも大きな理由は「評価」です。 半期に1度メンバーの評価を行うシステムでしたが、感じた課題は「フィードバックが遅い」ことです。 個人的には半年の評価時に「評価低いよ」といわれるのが、誰も幸せにならないと感じていたからです。 評価を受ける人も、「今自分はこう思われているんだな」、「こういうことをやった方が良いな」など 短期でフィードバックされれば、途中からカイゼンできる可能性だってあります。 そういった評価に対するもどかしさを解決したい思いで「1 on 1」を導入しました。

実態

背景で述べたように、モチベーションは「評価」でした。 しかし、実際に「1 on 1」を進めていくと、テーマが徐々に変化したので時系列ごとに書きます。

1~2ヵ月

  • 目標/評価ベース

初めのうちは予定通り、評価するために「1ヵ月」「2ヵ月」「3ヵ月」の目標を立ててもらい定期的にフィードバックしました。 この方法によって定めた目標に対して停滞しているようであればカイゼンのアクションを話し合ったり成果の見える化に注力していた時期です。 いまふりかえると、この時の「1 on 1」は割と自分が発言しており参加メンバーは同意が多かったと思います。 効果として、目標や課題駆動で物事に取り組む習慣がついたように感じます。

2~4ヵ月

  • ふりかえり/アクションベース

目標が明確になったため、「ふりかえり」を中心に進めました。 @viva_tweet_xさんのふりかえり読本にもある ふりかえりの「型」を意識してふりかえりました。 メンバーの抱えている内容によって「学びを最大にする」、「多角的に捉える」、「問題を解消する」などなど 使い分けました。 効果として、立ち止まって考えることで仕事の問題をカイゼンできたことや、メンバーとの信頼関係が気づけました。 このころになると、「1 on 1」では、傾聴が中心になりメンバーの発言がほとんどでした。

4ヵ月~

  • フリーテーマ

メンバーの発言がほとんどなため、とくに「テーマ」を決めず、話したいことを話してもらいました。 変化が表われたと感じたのは、整理できてなくてもどんどん発言してくれることです。 1 on 1の場を自分の考えを整理する場や課題を解決するための場として認識し、トレーニングできるので 会議などでも、考えをまとめて発言したりまとまらないときに困っていることを伝えるなど言語化してつたえる力がついたと思います。

ラクティス

1 on 1をやるにあたって、実施したプラクティスやツールを書いておきます。

  • チェックイン

ふりかえりによくある「場を設定する」方法です。簡単な質問をしてメンバーに答えてもらいます。 たとえば「今の気持ちを一言で答えてください」のように業務に関係ないことでも問題ありません。 1 on 1という場だと、評価する側、評価される側の構図ができやすく発言しにくい空気になるので 気軽に発言できる場を作るために取り入れました。

  • プラス/デルタ

同じくふりかえりである「ふりかえりを終了する」方法です。今回はふりかえりでなく1 on 1です。 1 on 1自体のフィードバックをします。プラス(続けたいこと)デルタ(カイゼンしたいこと)で それぞれ考えてもらいました。自分たちにとってより良い1 on 1をしたいので取り入れました。

  • 5つのなぜ

ふりかえりで行う方法ばかりな気がしますね。。。「アイデアを出す」ための方法です。 課題や悩みに対して、原因が何なのか?どこがボトルネックなのかを明確にするため取り入れました。 主にメンバーが課題解決を望んでいる場合に使っています。4つめ、5つめくらいの「なぜ」を考えるのが難しいです。

  • 1 on 1カード

XP祭りのときに存在を知りました。 1 on 1実施時に会話の引き出しを増やすために使うことがあります。あまりしゃべらない人のときに非常に役立ちます。

  • 外部1 on 1を受ける

私自身が1 on 1を受けたことが無かったので、体験するために外部の方に1 on 1して頂きました。 会社の中で行うのとは別の視点から物事を捉えるので発見が多い場になりました。その時の振り返りはこちらにまとめてあります。

cabi99.hatenablog.com

学び

学びはたくさんありましたが、とくに学びが大きかったことを紹介します。

  • やり方より在り方

人と接する時に効果的にできる「やり方」はもちろん大切です。 とくに1 on 1を始めたころは私自身「やり方」に固執していました。しかし、 1 on 1を実施し体験することで 過去に1 on 1体験したときにも感じたのですが、「自分がどうあるか?」「興味をもっているのか?」など 自分の姿勢は言葉にしなくても相手に伝わることが分かりました。そんな相手がアドバイスしようが、話を聞こうが 相手のアクションに繋がらないし、本音を打ち明けてくれることはありません。 なので、成長や変化を促したい場合は、自分が成長し変化する姿勢を見せることがとても重要だと思います。

さいごに

半年とちょっと続けてきた1 on 1についてふりかえり、まとめました。 はじめはメンバーのために始めたことでしたが、気が付くと1 on 1自体が自分の成長にも大きく影響していました。 コツコツカイゼンを続けていく中でメンバーとの信頼関係も築けるので、迷っている方ははじめてみることをオススメします。

参考

参考にした書籍をいくつか載せておきます。

やり方とあり方についてよく説明されている本です。

1 on 1のみならず普段ファシリテーションする中での心がけになります。

  • アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

ふりかえりの手法について説明しています。

状況や目的に応じた手法が載っています。

  • NLPで最高の能力が目覚める コーチングハンドブック 知識と経験を最大化するセンスの磨き方

コーチングについての全体像が載っています。

1 on 1を組み立てるうえでヒントにしました。

  • ふりかえり読本 実践編~型からはじめるふりかえりの守破離~ - ふりかえり実践会

ふりかえりについて、「型」ベースに説明しています。

具体的な例や目的をわかりやすく説明しています。 booth.pm

  • 会話の引き出しを増やす 1on1カード と 使いこなしブック

初めに何を話したらよいか?

あまり話が続かないときに使ってみると良いかもしれません。

booth.pm

GitOps Days 2020 参加レポート 2日目

はじめに

2020/5/21(木)開催のGitOps Days 2020のDay2に参加してきましたので、 まとめていきたいと思います!

※1日目と同様に発表者ではなく、ただ聞くだけです。。。

1日目の参加レポートはこちらです。 cabi99.hatenablog.com

印象深かったセッションなど

ここでは印象深かったセッション(など)についてまとめていきます。 Day 1ではGitOpsを実際に導入するための具体的な技術をチームに定着させる方法やGitOpsの今後について説明するなど、 1つ1つのセッションが濃ゆい内容になります。

11:00 – 11:57 am PT: Flux and Helm: Intro and How to teach your teams – Stefan Prodan and Leigh Capili

@stefanprodanさん@capileighさんが従来のCI/CDパイプラインの課題を明確にし、GitOpsに変更する利点と具体的なデプロイの流れを説明しデモを見せてくれました。

従来のCI/CDの課題

従来のCI/CDではビルドとデリバリーを自動化できていましたが ここでの問題提起は監視や復旧といったオペレーション観点となっています。 CI/CDを導入しているチームに共通して抱えている課題のように感じます。

トレーサビリティ

  • クラスターで実行されているアプリのバージョンを確認するか?
  • 複数ビルドを並行して実行するとどうなるのか?

セキュリティ

  • クラスター認証の管理方法をどうするのか?
  • 複数クラスターをターゲットにする方法は?

ディザスターリカバリ

  • インフラ依存関係に対処する方法は?

GitOpsに変更する利点

全体的にGitで宣言的に管理できるようになります。 これにより従来のようにrebuildする機会も減り、Gitのマニフェストを 前バージョンに戻すだけで切り戻しができるようになります。 OPAのようなポリシー適応はまだ実現していないので興味深いです。

  • インフラストラクチャの変更についてPRsとレビューで協力できる
  • 静的分析(OPA)でポリシーを適用できる
  • rollbackとrevertが簡単
  • 平均回復時間を短縮できる

GitOps準備

GitOps実現にあたって必要なものを説明しています。

必須

オペレーション

  • リポジトリ変更を監視し、通知する
  • 設定ドリフトを検出して修正する
  • 設定とドリフトに関するアラート
  • コミッターのバリデーションを行う

flux, helmを利用したGitOpsデモ

デモについては省略します。

fluxの使い方はこちらを参考にしてください。 cabi99.hatenablog.com

所感

2日目は1日目に説明した概念について具体的にデモをする場面が多いです。 これから導入する人や動作のイメージがわかない人向けのような気もしました。 2日間を通してGitOpsは概念であり、実現の方法が1つでないこと、そしてセキュリティに対して利点が多いこと。 これらが参加する前の自分になかった視点なのでとても参考になりました。 また、これらの新しい知識をプロダクトチームにoutputできるのでよりチームのDevOpsが促進することを楽しみにしています。 とても有益なイベントでしたので次回開催もぜひ参加したいと思います。

GitOps Days 2020 参加レポート 1日目

はじめに

2020/5/20(水)開催のGitOps Days 2020に参加してきましたので、 まとめていきたいと思います!

※発表者ではなく、ただ聞くだけです。。。

www.gitopsdays.com

GitOps Daysは、私が知っている限りではGitOpsに関するはじめての大きめイベントです。 はじめてGitOpsについて学びたい人や、GitOpsの利点を理解するようにチームを説得する人向けのようです。 現在のプロダクトでGitOpsを導入しているので世界的にGitOpsがどのように浸透しているのか?今後の展望はどうなっていくのか?などに興味を持ち参加しました。

GitOpsとは?

まずGitOpsとは何ぞや?という疑問もあると思うので説明します。 GitOpsはWeaveworks社が提唱した、Kubernetesの運用ベストプラクティスであり、 宣言的インフラストラクチャとアプリケーションの「Single source of Truth」としてGitを利用し、システム実行環境やアプリケーションの変更を行う方法です。

簡単に述べるとgitのcodeと環境面が同期して常にcodeの状態が正になる方法です。 メリットとして、codeですべて管理できる、環境構築が容易になる、セキュリティが向上するなどが挙げられます。

過去にGitOpsを実現するfluxを検証したことがあるので興味がある方はご覧ください。 cabi99.hatenablog.com

印象深かったセッションなど

ここでは印象深かったセッション(など)についてまとめていきます。 Day 1ではGitOpsがどのようなものなのか?概念やメリットを説明しています。 他にも具体的なプラクティスを紹介し、導入企業のエンジニアが事例を紹介しています。

10:00 – 10:27 am PT: GitOps Practitioner Highlight – Palo Alto Networks – Javeria Khan

Javeria KhanさんがGitOpsプラクティスを紹介してくれました。

利用する技術以外にもメリットやオンボーディング時の注意点が興味深かいです。

GitOpsの利点

  1. 可逆性
  2. 監査証跡
  3. 透明性
  4. 反復的なタスクを自動化する
  5. 開発および運用チーム間のコラボレーション

5番以外の利点は認識としてありました。 GitOpsにより環境が同期するため、コード管理時にDevelopとOperationを意識する。 これによりDevとOpsのようにチームが完全分業体制から共通の概念を持つ one teamとして機能しやすいのだと解釈しました。

Layer別の役割と技術

GitOps導入で技術の統一は必須でなく、それぞれの用途に合う仕組みを採用します。 また、環境なのかアプリケーションなのかでオーナシップを持つメンバーが変化します。

インフラ層(IaC)

ステークホルダー

  • SRE
  • Infra Engineers
  • Management

プロビジョニング(例)

  • Terraform → Atlantis
  • Salt → Scheduled states

設定情報(例)

Puppet → code manage Flux, Argo → cluster controllers + config repos

アプリ層

ステークホルダー

  • Developers
  • DevOps, Test Engineers

アプリケーションTemplating, Deployments

  • Helm, Kustomize
  • Flux, Argo: cluster controllers + app manifest
  • Flagger: Blue/Green

オンボーディングで心掛けること

自分たちのチームもGitOpsを導入しているのですが、 オンボーディング時の心掛けはかなり同意です!

  • Dev

    • 時間を先行投資して、仕組みと文化を定着させること
  • Management

    • 個人への依存をなくすこと

12:40 – 1:10 pm PT: GitOps for Cost Efficiency, Compliance, Velocity, Security, Resilience, and more! – Cornelia Davis

@cdavisafcさんによるコスト効率、コンプライアンス、速度などなど良い点をてんこ盛りに説明して頂いてます。

GoogleDevOps Elite performance reportでは、セキュリティについてあまり言及されていないので、ここでGitOpsだよ!と述べています。 システムの可用性、セキュリティを支えるために、必要な要素がGitOpsによりどのようにカイゼンするか?明確になるセッションでした。

GitOpsを支える5つの要素

  • アプリケーションチームの生産性
  • アプリケーションチームの自主性
  • 安全なネットワークの確立
  • 再現性
  • 冗長性

ここは動画が公開されてもう一度視聴してからまとめようと思います。。。

1:10 – 1:17 pm PT: Security and GitOps – Maya Kaczorowski

パズルがアイスクリームと同じくらい大好きな @MayaKaczorowski さんによる GitOpsがもたらすセキュリティの利点の説明です。

個人的には従来のCIOpsのようなpush型デプロイからpull型デプロイへ変更されるため kubernetes clusterのip制御が無くなるので、セキュリティホールのリスクが減る認識でした。 このセッションでは、それ以外にもセキュリティの利点があることを学べました。

セキュリティ利点

管理

さまざまな仕組みが「〇〇 as Code」で実現するため、 バージョニングや不変なものをSingleSourceに集約でき、全体を管理しやすくなる。

監視

デプロイ方法が決まるため、監視しやすい

セキュリティアップデート

デプロイが単純化されるため、セキュリティアップデートに集中する時間が取れる。

軽くまとめてみる?

gitログ、PRコメント、およびレビューポリシーにより、責任を共有しセキュリティの脆弱性の解決に対して協力体制が作れるようです。 同じ指標が持てるようになれば、同じ方向に向かって協力できるようになるのが良いです。 なんだかエンジニアリングでプロジェクトをデザインしている感じが好きです。

GitOps = IaC + Config as Code + Policy as code + Policy as code + thing as code

所感

Day 1は主にGitOpsの抽象的な部分を説明が多かったです。 GitOps自体は哲学であり、それを実現する仕組みは1つでなく、目的に併せて変化するものだと感じました。 実際に導入事例の紹介でも企業によって「GitOps = 〇〇 + △△」の定義が異なることも 多く、各企業が自分たちのモデルにあったものを探して適応している印象です。 もしかすると組織のDevOps習熟度で、この辺は変化していきそうな気がします。

※英語を学習中なので、所々説明している内容と異なるかもしれませんがご了承ください。 むしろ、これはこういうことだよとかフィードバックがあると嬉しいです。

リモートワークでやってみてよかったこと Tips

背景

コロナによる緊急事態宣言でリモートワークに切り替わり、チーム開発やコミュニケーションをとることに苦戦している人も多いと思います。 今回は2ヵ月リモートしてきた中で試してきたものをいくつかまとめておくので 何かの参考になればと思います。

ツール

リモート時に利用するツールはさまざまなものが紹介されていて、すでにご存じだと思うので良く使っているものを紹介します。

コミュニケーションツール

Slack

画面共有時にペンなどで場所を指摘したり書き込みできるので「右上の、、、」、「下から2番目の」のように場所を伝えるのに苦労しないです。

slack.com

ホワイトボードツール

Miro

図形を描いたり、付箋を使ったり「ふりかえり」のイベントに使いやすいです。 また、カスタマージャーニーマップやユーザーストーリーなどのテンプレート機能が豊富で、アジャイル開発との親和性が高いです。 あとは、リモートでアーキテクチャを図解して説明する時に非常に便利です。

miro.com

リモートワークのTips

リモートワークしてきた中で、役に立った取り組みを紹介します。 当たり前のことも多いですが、当たり前が浸透すると効果が発揮できるので はじめることが重要です。

ミーティングの約束

発言時は声がけする

複数人でのリモートミーティングあるあるだと思うのですが 思いのほか発言が被ってしまって、収集つかなくなることが多いです。 回線によっては通信速度の差もあり、遅れて聞こえてくる場合もあります。

そこでミーティングで発言する時に「○○ちょっとしゃべりまーす」みたいな感じで 一言声がけすると、次に誰が発言したか、また被って発言していた人が気づいて場をいったん整理するタイミングを作れます。 これによりミーティング中の発言が被ることによる謎のカオス時間が激減しました。

ミーティングは決まったチャンネルを使う

slackを利用している場合ですが、チャンネルが複数あって どのチャンネルでミーティングするのか分からずに、迷っているだけで開始時間が5分ほど遅れるのがザラでした。 そこでチームではあらかじめ「mtg」チャンネルを設けて、人数を集めて話す場合は 決まったチャンネルでcallするようにしています。 そうすれば開始時間にcallするとおのずと人が集まってくるようになりました。

Quick Callする

これはMicrosoftの牛尾さんのブログに書かれていたことをチームが取り入れました。 詳細はこちらをご覧ください。

simplearchitect.hatenablog.com

簡潔に述べると、困ったときにすぐ「1 対 1」の通話をして、サクッと解決しちゃおうということです。

困ったことをため込んで、ミーティングの時にまとめて共有するケースが見受けられたのですが、解決しないことでミーティングまで時間がムダになりがちです。このほかにも、大人数の前で説明して的確に伝えられない場合があり非効率になります。何より困りごと満載のミーティングは参加していて楽しくないです。 Quick Callを導入することで、個々の生産性が目に見えて上がっており、チャット上で長文のやり取りも減るので、非常におススメです。

所感

リモートワークを続けて気づいたことは、自分の当たり前はあくまで自分の中だけだということです。 たとえば「Quick Call」を例に挙げると普段から仕事をしている中で必要なメンバーと連絡を取るのは頻繁に行っていましたが、このメリット自体は周りに広がっていないです。 しかし、「Quick Callやろう」とメンバーが声がけするだけで、文化が浸透し全体の効率が上がりました。

ここから、個々が日々業務している中で、より良くするための取り組みがたくさん転がっており、それを周りに伝えるだけでも大きな成果が得られるのだと再認識しました。 チームの中なら「ふりかえり」をすることで徐々にカイゼンされているのですが、良い部分はどんどん横展開していくことが大切なので、何かアイディアを出せば意外な形で効果があるかもしれません。

KEDA による イベント駆動オートスケール と 使い方を考えてみる

背景

MicrosoftAKS を利用して kubernetes を運用しており、podのauto scaleはHorizontal Pod Autoscalerの機能を利用しています。 Horizontal Pod Autoscalerは、簡単に説明すると指定したmetricをpodから取得して、閾値に達した場合、podをauto scaleする仕組みです。 これはkubernetesでcontainerを安定し運用するための便利な仕組みです。しかし、kubernetesのリソースに対して監視するため 外部リソースの状態に応じてpodをscaleする場合は、別の仕組みを検討する必要があります。

KEDAとは

KEDA (Kubernetes Event-driven Autoscaling)は、 kubernetes clusterに追加できる単一目的の軽量コンポーネントで、CNCFのSandboxプロジェクトにホストされているkubernetesベースのイベント駆動オートスケーラーです。宣言的に定義されたイベントに応じて、kubernetesの任意のコンテナーのスケーリングを促進できる。Horizo​​ntal Pod Autoscalerなどのkubernetesコンポーネントと連携して動作し、上書きや重複なしに機能拡張できます。

keda.sh

KEDAの役割

KEDAはkubernetes内で2つの重要な役割を果たします。

  • Agent kubernetes deploymentをアクティブ/非アクティブ化を管理します。

  • Metrics kubernetes metricsサーバーとして機能します。キューの長さやストリームラグなどのイベントデータをHorizo​​ntal Pod Autoscalerに公開してscale outを促進します。ソースから直接イベントを消費するのはDeploymentの役割であり、これにより、豊富なイベントの統合が維持され、キューメッセージの完了や破棄などのジェスチャーをそのまま使用できます。

Architecture

公式の説明からKEDAはetcdや外部リソースを監視して標準のHPAや対象podに命令します。

https://keda.sh/img/keda-arch.png

対象ソース

AWSやAzureなど幅広く対応しています。また、「External」リソースを利用することで柔軟なevent操作ができます。 詳細はこちら https://keda.sh/docs/concepts/#event-sources-and-scalers

デプロイ

今回はYAML Manifestを使ってdeployします。 ※HelmやOperatorも可

  • KEDAのrepositoryをcloneし、CRDを作成する
kubectl apply -f ./deploy/crds
  • scaleとtriggerを行うCRDがあることを確認する
$ kubectl get crds
NAME                                 CREATED AT
scaledobjects.keda.k8s.io            2020-04-21T01:43:13Z
triggerauthentications.keda.k8s.io   2020-04-21T01:43:13Z
  • CRDを作成したらKEDA operatorとmetrics serverを作成する
kubectl apply -f ./deploy
  • デフォルトでは「keda」namespaceに作成される
$ kubectl get all -n keda
NAME                                         READY   STATUS    RESTARTS   AGE
pod/keda-metrics-apiserver-f465ccb68-wdk5l   1/1     Running   0          23h
pod/keda-operator-8fdf64d5-pkwf9             1/1     Running   0          23h

NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
service/keda-metrics-apiserver   ClusterIP   10.105.111.250   <none>        443/TCP,80/TCP      23h
service/keda-operator-metrics    ClusterIP   10.110.125.60    <none>        8383/TCP,8686/TCP   23h

NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/keda-metrics-apiserver   1/1     1            1           23h
deployment.apps/keda-operator            1/1     1            1           23h

NAME                                               DESIRED   CURRENT   READY   AGE
replicaset.apps/keda-metrics-apiserver-f465ccb68   1         1         1       23h
replicaset.apps/keda-operator-8fdf64d5             1         1         1       23h

これでKEDAのdeployは完了です。

動作確認

KEDAのdeployが完了したので実際外部リソースをtriggerしてpodのauto scaleを確認します。 今回はnginxのpodをAzure storage accountのblob container file uploadイベントをhookしてpodをscaleさせます。

簡単なサンプルですがこちらに載せておきます。 https://github.com/JunichiMitsunaga/keda-example

  • Azureにresource groupとstorage accountを作成する
az group create --location japaneast --name keda-example
az storage account create --name kedaexample --resource-group keda-example
  • connection stringを取得する
az storage account show-connection-string --name kedaexample
  • 取得したconnection stringでk8sのsecretを作成する

01-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: account-secret
  namespace: keda-scale
data:
  connectionString: ***
  • auto scale用のpodをdeployする
kubectl apply -f .deploy/
  • 「keda-scale」namespaceにpodがdeployされていることを確認する
$ kubectl get all -n keda-scale                         
NAME                              READY   STATUS    RESTARTS   AGE
pod/scale-nginx-898f5b6d4-x8897   1/1     Running   0          46s

NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/scale-nginx   1/1     1            1           47s

NAME                                    DESIRED   CURRENT   READY   AGE
replicaset.apps/scale-nginx-898f5b6d4   1         1         1       46s
  • KEDAによるscaleを実施するために「ScaledObject」をデプロイする
kubectl apply -f keda-hpa/
  • 「ScaledObject」がdeployされていることを確認する
$ kubectl get ScaledObject -n keda-scale
NAME                      DEPLOYMENT    TRIGGERS     AGE
azure-blob-scaledobject   scale-nginx   azure-blob   28s

ScaledObjectをdeployするとscale条件にマッチしてないため該当のpodは0スケールされます。 ※この仕組みは地味にうれしいですね

$ kubectl get po -n keda-scale
No resources found in keda-scale namespace.
  • triggerを満たしてauto scaleを確認する 今回のtriggerはblob containerにfileを2つ以上uploadすること

1つ目のfileをuploadする 条件を満たしていないのでscaleされない

$ kubectl get po -w -n keda-scale

2つ目のfileをuploadする 条件を満たすのでpodがscale outされる

$ kubectl get po -w -n keda-scale
NAME                          READY   STATUS    RESTARTS   AGE
scale-nginx-898f5b6d4-zhgdm   0/1     Pending   0          0s
scale-nginx-898f5b6d4-zhgdm   0/1     Pending   0          0s
scale-nginx-898f5b6d4-zhgdm   0/1     ContainerCreating   0          0s
scale-nginx-898f5b6d4-zhgdm   1/1     Running             0          4s

fileを削除して条件を満たさないように変更する

$ kubectl get po -n keda-scale -w
NAME                          READY   STATUS    RESTARTS   AGE
scale-nginx-898f5b6d4-ftffd   1/1     Running   0          16s
scale-nginx-898f5b6d4-ftffd   1/1     Terminating   0          70s
scale-nginx-898f5b6d4-ftffd   0/1     Terminating   0          72s
scale-nginx-898f5b6d4-ftffd   0/1     Terminating   0          72s
scale-nginx-898f5b6d4-ftffd   0/1     Terminating   0          75s
scale-nginx-898f5b6d4-ftffd   0/1     Terminating   0          75s

以上よりAzure Blob Storageのeventからpodをscaleできた。

運用を考えてみる

リソース監視からのauto scale

背景で述べているようにkubernetesの標準機能はmemoryやcpuをtriggerにするため、Databaseのような外部リソースやpod内のthread、connection数といった他のmetricをtriggerにするのが困難でした。KEDAを利用することでAzure Monitorなどといった監視サービスと併用することでpodのconnection数が上限をtriggerにscale outするなどの運用方法が考えられます。 ただし、scale outする場合の他のリソースへの影響を考慮するため キャパシティプランニングする必要はあります。

Serverlessの実行

Serverlessアプリケーションは、AWS LambdaやAzure FunctionsなどのFaaSやAzure Container Instance(ACI) によるpodの起動など、さまざまな方法が挙げられます。もちろん、これらの仕組みでも十分に実現できますが、KEDAを利用することでkubernetes cluster内に一元管理できるためコストが楽になると感じました。 とくに長時間のbatch処理は「Azure Queue Storage → KEDAによるAuto Scale」といったシンプルな実装で管理でき、タイムアウト意識する必要も減るため有用な仕組みになりそうです。

所感

触ってみた印象としてKEDAは、kubernetes cluster内で実現するFaaSのイメージです。とくにkubernetesを普段運用している方は、扱いやすいものだと思います。 プロダクトを安定させる使い方や、新機能を効率よく動かす使い方など、プロダクトの課題に沿った形で柔軟に使えそうなので、auto scale や batch処理なの運用設計に困っている人がいれば是非触ってみてほしいです。

初心者の 負荷試験入門 2

はじめに

本記事は初心者の負荷試験入門シリーズの第2弾です!

前回の 初心者の負荷試験入門 その1 では、負荷試験のざっくりとした目的や指標、性能改善をまとめました。負荷試験を実施するにあたってどのような指標が必要なのかは何となくわかりましたが、実際にどのようなToolを利用してシステムに負荷をかけていくのかはまだ見ていないので今回はそれをまとめてみようと思います。

負荷試験ツール

ひとえにツールといっても負荷試験のツールにはいくつか種類があるようで、主に「攻撃ツール」、「モニタリングツール」、「プロファイリングツール」の3種類のツールを利用する。 ツールの役割はこんな感じ 攻撃ツール:システムに負荷を与えるツール(大量リクエストの送信など) モニタリングツール:システムのリソース状況を観測して可視化するツール プロファイリングツール:ミドルやアプリケーション内部を解析して可視化するツール

攻撃ツールの選択

攻撃ツールとは

システムを利用する側の動きをシミュレーションすることにより、対象のシステムを高負荷状態にできるツールのことを指します。 攻撃ツールを利用することでシステムに大量のリクエストが発生し、Dos攻撃を受けたかのような状態となります。

攻撃ツールに求められる要件

負荷試験を行うために攻撃ツールに必要とされる主な要件は下記の4つになります。 1.リクエストを正しくシミュレーションできること 2.攻撃の強さを制御できること 3.対象のシステムに対して十分な負荷を発生させられること 4.攻撃ツールの設置場所、起動場所を選択できること

1.リクエストを正しくシミュレーションできること 攻撃ツールによってはシナリオを組んだ攻撃が出来ないツールも存在するため、負荷試験の要件にそぐわない場合はこれらのツールを選定から外した方がよさそうです。

2.攻撃の強さを制御できること クライアントの同時起動数、リクエスト間隔、最大スループット数を調整することで攻撃の強さを設定できます。

3.対象のシステムに対して十分な負荷を発生させられること 攻撃ツールにより、どこまでの高負荷状態を効率よく発生させられるかが異なる為、自分たちのシステムの特性に合ったツールを選択する必要があります。

4.攻撃ツールの設置場所、起動場所を選択できること 攻撃ツールによって起動できる攻撃サーバに制約がある為、攻撃サーバを設置する場所が制限されるものがあります。

攻撃ツール用語

ツールによって多少用語が異なることがありますが、たいていの攻撃ツールは下記表のような概念が存在しています。用語を理解していればツールが変更になったとしても同じように負荷試験が行えるようです。

用語 説明
クライアント HTTPリクエストを同時に1つだけ発行できるリクエスト生成機
クライアントの同時起動数 攻撃ツール上で利用される攻撃用クライアントの数
Ramp-Up 期間 攻撃開始後にすべてのクライアントが起動するまでのウォームアップ期間
シナリオ クライアント毎に設定されたHTTPリクエストの発生パターン
シナリオ実行回数 クライアントがシナリオに沿ったリクエストを実施する回数
スループット システムが単位時間あたりに処理できるリクエストの数
レイテンシ 攻撃ツールがリクエストを出してからレスポンスを受け取るまでの期間

攻撃ツールの例

具体的な攻撃ツールを一部紹介しています。(各ツールの詳細については割愛します…調べたら記述予定)

  • Apache JMeter 特徴
    • リクエスト毎に動的にパラメータを変更可能
    • 複数のURLを組み合わせたシナリオを実施できる
    • GET,POST,PUT,DELETEメソッドの試験が可能 etc
  • Locust 特徴
    • シナリオをPythonスクリプトで記述できるため、柔軟なシナリオが作成できる
    • 結果表示がシンプル
    • 必要なサーバリソースが少ないた為、攻撃サーバで負荷をかけやすい etc
  • Gatling 特徴
    • developerフレンドリーなシナリオファイル
    • 見やすいレポートHTML etc

攻撃ツールにはそれぞれ特徴があり、負荷試験の対象となるシステムによって使い分けることが必要です。 とくに同じシステムに対する負荷試験でも利用するツールによって大きく結果がことなることがあるため、場合によっては複数のツールで攻撃を行い結果を比較してみることも必要かもしれません。

モニタリングツール/プロファイリングツール

攻撃ツールの中にはスループットの監視ツールや可視化ツールが含まれているものも多いですが、攻撃ツールから観測できるレイテンシはシステム全体のレイテンシのみであり、個別のサブシステム等のレイテンシは観測できません。

サブシステムにおける詳細なモニタリングやプロファイリングを補助するためのツールとして以下があります。 - topコマンドとnetstatコマンド - AWS管理コンソール(AWSを利用している場合) etc

そしてこれらのツールを利用してモニタリングしておきたい項目が以下の表になります。

サブシステム 監視すべきもの
ネットワーク 転送量
ハードウェアやOS CPU,メモリ,プロセス数,SWAP
TCP 外部へのコネクション状況
ディスク R/W 転送データ量
サーバミドルウェア コネクション数
アプリケーション プロファイラーにて監視

今後について

負荷試験に利用するツールについて調べたが主に攻撃ツールの特性による試験の向き不向き等が見えてきました。モニタリングについては文章ベースなので今後、実際にサンプルアプリケーションを作成して負荷試験を試してみる中でモニタリングのやり方を学習していこうと思います。

そのほか、こんなツールがあるよなど情報があればぜひご連絡頂ければと思います。