2020-06-02

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

はじめに

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

ふりかえり

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

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

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

背景

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のみならず普段ファシリテーションする中での心がけになります。

かかわり方のまなび方: ワークショップとファシリテーションの現場から (ちくま文庫)

作者:西村佳哲
発売日: 2014/10/08
メディア: 文庫

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

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

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

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

作者:ＥｓｔｈｅｒＤｅｒｂｙ,ＤｉａｎａＬａｒｓｅｎ
発売日: 2017/07/15
メディア: Kindle版

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

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

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

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

作者:山崎啓支
発売日: 2016/10/21
メディア: Kindle版

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

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

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

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

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

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

booth.pm

2020-05-22

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

devops gitops kubernetes technology

はじめに

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実現にあたって必要なものを説明しています。

必須

クラスターの状態を管理するGitリポジトリー(マニフェストリポジトリー)
CIによる不変イメージをプッシュするコンテナーレジストリ

オペレーション

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

flux, helmを利用したGitOpsデモ

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

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

所感

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

2020-05-21

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

kubernetes gitops devops technology

はじめに

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の利点

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

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さんによるコスト効率、コンプライアンス、速度などなど良い点をてんこ盛りに説明して頂いてます。

GoogleのDevOps 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習熟度で、この辺は変化していきそうな気がします。

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

2020-05-15

リモートワークでやってみてよかったこと 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やろう」とメンバーが声がけするだけで、文化が浸透し全体の効率が上がりました。

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

2020-04-30

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

devops technology kubernetes

背景

Microsoftの AKS を利用して 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の任意のコンテナーのスケーリングを促進できる。Horizontal Pod Autoscalerなどのkubernetes コンポーネントと連携して動作し、上書きや重複なしに機能拡張できます。

keda.sh

KEDAの役割

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

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

Architecture

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

対象ソース

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処理なの運用設計に困っている人がいれば是非触ってみてほしいです。

2020-03-26

初心者の負荷試験入門 2

性能試験負荷試験 technology

はじめに

本記事は初心者の負荷試験入門シリーズの第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 転送データ量
サーバミドルウェア	コネクション数
アプリケーション	プロファイラーにて監視

今後について

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

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

2020-03-26

初心者の負荷試験入門 1

負荷試験性能試験 technology

はじめに

Webアプリケーションについて負荷試験が必要になり、初心者ながら負荷試験についての基礎事項を調べてまとめておこうと思います
この分野に詳しい人の話をぜひ聞いてみたいものです…

負荷試験って目的とは

負荷試験の目的とは、システムの可用性を高めることだと思います。そしてそれはオンプレミスの場合とクラウドの場合で異なる
- オンプレミスの場合
  - ユースケースを想定して、システムの応答性能を推測するため
  - 高負荷時のシステム改善を実施するため
  - 目的の性能を提供するために必要なハードウェアをあらかじめ選定するため
- クラウドの場合
  - ユースケースを想定して、システムの応答性能を推測するため
  - 高負荷時のシステム改善を実施するため
  - 目的の性能を提供するために必要なハードウェアをあらかじめ選定するため
  - システムがスケール性を持つことを確認するため
  - システムのスケール特性を把握するため
    - クラウドではスケーラブルなクラウドデザインパターンを構成するのみでなく、スケール性をもつシステムを担保することが非常に重要である

負荷試験の指標

スループット
- 単位時間に処理を行う量
  - webシステムでは「1秒間に処理を行うHTTPリクエストの数」を示すことが多く、rps(Request Per Second)と呼ぶ
- 「ネットワーク上を流れるデータ転送速度」として利用する場合もある
  - ネットワーク帯域と呼ぶ
レイテンシ
- 処理時間には2種類が存在する
  - 「ユーザーから見た処理時間」
    - ユーザーがリクエストを送ってレスポンスを受け取るまでの時間
  - 「システムから見た処理時間」
    - Webシステムがリクエストを受け取ってからレスポンスを返すまでの時間
  - 2種類の処理時間には以下のような関係が成り立つ
  - 「ユーザーから見た処理時間」=「システムから見た処理時間」+「データがネットワークを往復する時間」
  - ブラウザを利用する場合は、ブラウザがデータを受け取ってから画面描画が完了するまでをレイテンシと呼ぶ場合もある

システムの性能改善

スループットの改善
- 複数のサブシステムによって構成されているWebシステムは、もっともスループットが低いサブシステムによって全体のスループットが制限される
  - もっともスループットが低いサブシステムをボトルネックと呼ぶ
- ボトルネックを改善したら次のボトルネックを検知して間然するPDCAを繰り返して全体のスループットを向上させる
  - ボトルネックは移動するものだと理解すること
  - 重要なことは負荷試験は繰り返し実施されること
レイテンシの改善
- 待ち時間を含めた各サブシステムの処理時間の総和であるため、「大きな処理時間を要している処理」から順々に改善できる点がないかを検討する
- 処理時間にとって最大の改善個所はアプリケーションの実装部分であることが多い
  - 非効率なアルゴリズム
  - 無駄なI/O
  - データベースのインデックス不足
- アプリケーションの実装部分である場合は、プロファイラーを利用して処理の詳細な処理時間を確認することが可能
  - yourkitなど
    - https://www.yourkit.com/
- 重要な点としてレイテンシは「待ち時間を含めた時間」であるため、スループットが上限に近づくと必然的に待ち時間も増加するため、裏を返せばスループットが向上すればレイテンシも改善することもありうる

今後について

ひとまず負荷試験を行う上での用語や性能改善については調べられたので、今後は負荷試験に利用するtoolを調べてみることにする