CNDT の記事一覧

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、CFPセッション「しきい値監視からの卒業！Prometheusによる機械学習を用いた異常検知アラートの実装」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会　プリンシパルエンジニア高橋 拓也（@takutaka1220） 「しきい値監視からの卒業！ Prometheus による機械学習を用いた異常検知アラートの実装」 https://speakerdeck.com/takutakahashi/sikiizhi-jian-shi-karanozu-ye-prometheus-niyoruji-jie-xue-xi-woyong-itayi-chang-jian-zhi-aratonoshi-zhuang 「しきい値監視からの卒業！Prometheusによる機械学習を用いた異常検知アラートの実装」と題しまして、GMOペパボの高橋　拓也が発表させていただきます。 今回のアジェンダはこのようになっております。 自己紹介 まず軽く自己紹介させてください。私はGMOペパボでインフラエンジニアをやっております高橋拓也と申します。コードを書くこととKubernetesが好きで、自宅サーバを飼っていることが自慢です。たくさんあります。宣伝です。GMOペパボでは今回のCNDT2022で合計5セッション登壇しております。もうすでにすべて終わってしまっているので、後日アーカイブが放送されますのでそちらをご覧ください。 それではアジェンダの続きにいきます。 監視どうしてます？ 「監視どうしてますか？」という話です。大クラウドネイティブ時代においてもなくならないもの、それは監視です。いろいろな監視手法がありますね。外形監視したりメトリクスを監視したりとか。監視対象もたくさんあります、CPUとかレスポンスコードとかプラットフォームが動いているかとか、いろいろあります。監視はめちゃめちゃ大変ですよね、これは皆さん同意していただけるかなと思います。 では監視するものっていうのはどういうものがあるのか、だいたいこんな感じかなというのがあります。システムのメトリクスだとCPU使用率とかメモリ使用率などが想定よりも高くないか、あるいは低過ぎないか、あとサービスメトリクスに関してはステータスコードが200が多いか404が多いか、500が出ていないかとか、リクエストレイテンシに関しては遅過ぎないかとか、そういったようなことを監視します。この想定より高くなっていないか低くなっていないかといった部分に関しては、主にしきい値を用いてアラートを発報する手法がよく行われます。これをしきい値アラートと呼んでみます。特定の基準を超えた場合にアラートを発報する手法です。例えばCPU使用率が80%を超えたらアラートを出すとか、レスポンスタイムが2.0秒を上回ったらアラートを出すとか、そういった手法です。 では、このしきい値はどうやって決めていくのかといいますと、平常時の負荷から決めていくことが一般的だと思います。平常時のCPU使用率がだいたい40%で、高くても50%だから60%にしよう、そういったようなことをよくやられると思います。そういう場合、だいたいピーク時に60%を実はちょっとだけ超えてしまってアラートが頻発してしまうとか、繁忙期にはもうベースが50%を超えてしまって、ずっとアラートが出ているとか、そういったことが起こりがちと思います。そういう場合は、しきい値を見直していくと思うのですけれども、しきい値を都度見直していくのってすごく大変です。何回やるのだっていう感じになってしまいます。ではしきい値をもともとどういう理由で定めていたかといいますと、その普段の挙動がどういった挙動でそれと違う挙動を見つけるためにしきい値を決めていた、そうですね。このいつもの挙動、というものを発見する、そして違う挙動を発見するといった手法に異常検知という手法があります。こちらを今回ご紹介したいと思います。 異常検知アラートとは 「異常検知」という言葉は聞き慣れない言葉の人もいるかなと思いますが、Anomaly Detectionという英語で表現されます。何らかの方法で通常の動作というものを定義します。そして通常の動作の範囲内とする幅を指定します。今ここの下のグラフに映っている灰色の幅、これが通常の動作の範囲内としている幅です。その幅を超えたら異常であるとして検知をする、そういった手法になります。この赤いところ、これが異常だと判断されているポイントです。DataDogには「異常検知モニター」という名前でこの異常検知アラートが提供されています。DataDogに送られているすべてのメトリクスに対して、この異常検知モニターは設定が可能になっています。さらに皆さん大好きなAWS、こちらに関してもCloudWatchのmetrics/alarmで利用することができます。このように、プルダウンから簡単にパッと選んだらパッとこのようなアノマリーバンドが出てきて、AWSの監視はこれだけで実はよいのではないかというほどすごいと思っている機能です。パブリッククラウドいいなあ、AWSいいなあ、と思います。オンプレにも異常検知アラートが欲しい…オンプレ向けの異常検知アラート…オンプレ異常検知…監視…Cloud Native…Prometheusだ！ということで、Prometheusをデータソースとした異常検知を実装することができないか、と考えました。 Prometheusを利用した異常検知アラートの実装 Prometheusを使用した異常検知アラートの実装の中身についてみていきましょう。異常検知ってそもそも何をやったらできるのかという問いに関してですが、異常検知というものは時系列データの予測という問題に置き換えることができます。既知のデータを使って未来の値を予測する、これが時系列データの予測になっています。そして、実際にメトリクスとして収集された値と、予測した値、これを比較することによって、異常であるかどうかというのを見ることができるようになります。時系列データというものに関しては、この時間軸に沿って並べられたデータのことを指します。例えば年間の気温の推移とか、株価の推移とか、そういったものが時系列データですね。システムのメトリクスも時系列データといえます。Prometheusに格納されるデータは基本的にすべてが時系列データとなります。 ではこの既知のデータを使って未来の値を予測する、この方法について研究していきます。時系列データの予測モデルとしてはいくつか存在します。その有名なものの中にこの2つ、ARIMAとLSTMというのがあります。まずARIMAモデルに関しては、Auto-Regressive Integrated Moving Averageの略で、自己回帰(AR)と差分(I)、移動平均(MA)、この3つを組み合わせたモデルのことを指すみたいです。DataDogの異常検知モニターでも利用されており、結構枯れた古典的なモデルだと評価されているみたいです。対してLSTMは、Long Short Term Memoryの略で、リカレントニューラルネットワークというものを使った深層学習、いわゆるディープラーニング、そういったものらしいです。今回はARIMAの方を採用して予測モデルを作ってみました。 ARIMAを選択した理由としては、計算量が少なくて済む点がよいと思ったからです。構築済みモデルに適切な次数、パラメータを与えるだけで使えるモデルとしてそこそこ精度が出るものができるみたいでした。あとはGPUを使わなくて済むからLSTMよりやりやすいというのがあります。さらに、採用実績は実は結構豊富で、先ほどDataDogでもARIMAモデルは使われていると言及しましたが、詳しくはSeasonal-ARIMA、季節性ARIMAモデルというものを使っています。今回、以下この季節性ARIMAモデルのことをARIMAと指しておりますが、使っているのは同じものです。さらにBigQuery MLの時系列予測モデルとしても、実はARIMAモデルが使われている、かなり豊富に世の中でよく使われているものみたいです。 それでは早速このARIMAを使った時系列予測の手順について解説していきたいと思います。主にこの6手順をやっていきます。 環境を用意するデータを用意するデータを整形するデータをテスト用と学習用に分ける問題に最適なモデルを探索する探索してできたモデルに対して結果をテストデータで確認する この6手順です。 まず環境を用意します。機械学習といえばPythonということでPythonを使います。そしてあれこれ試行錯誤するために、Jupyter Notebookというものを使います。そしてモデルを使うためのライブラリとしてpmdarimaというものを使っていきます。Jupyter Notebookについて聞いたことない方もいらっしゃるかと思うのですけれども、特定のスニペットを実行したりとか、グラフをシュッと表示してくれたりとか、結構便利なインタープリターというような感じです。VS Code Extensionが実はかなりよくできていて、環境構築までやってくれてめちゃくちゃ便利なので、ぜひ、なんだこれは？と思った人は使ってみてください。そしてデータを用意します。とあるKubernetes PodのCPUの使用率を利用しました。だいたいこんな感じの周期的なデータで、予測しやすそうだというデータを用いました。PrometheusからREST APIを利用してデータを取得します。こんな感じで書いて、そうするとunix timeとvalueの配列を得ることができます。さらにこのデータに関してですが、データの数を減らして計算しやすい周期にするということが必要になってきます。例えば、この左のデータはPrometheus APIのstepパラメータ=600というのを指定したもので、結構ギザギザしていますが、右のデータ、step=3600、3,600秒につき1個のデータ数というものを使っても、これでも十分周期が表現できているので、予測ができそうということで、今回は3,600秒=1時間に1個のデータを使って予測することにしました。データを学習用とテスト用に分割します。これは過学習というものを防ぐためです。テスト用データで学習をしてしまうと、これは一種のカンニングになってしまうので、学習用の時は学習用のデータだけを使おうというのが定石となっております。これはpandas.Seriesという形を使っていろいろ設定して、このようにpmdarima提供のメソッドに入れてあげると、なんとシュッと分割してくれる結構便利なメソッドがあります。 分割した結果がこれで、赤が学習用、青がテスト用のデータになっています。時系列データでは未来のデータを使って過去のデータを予測することは基本的にないので、過去のデータを使って未来のデータを予測します。つまり、赤の学習用のデータが先に来て、青のデータがあとに来るというような感じになります。 それでは、最適なモデルを探索していきます。データによって適切なモデルへの入力が異なります。ARIMAモデルでは以下の入力を必要とします。pとdとq、それぞれ自己回帰と差分と移動平均のパラメータを表すものです。こんな感じで表現して、さらにSeasonal-ARIMAの場合はARIMA自体の周期というかARIMA自体の次数でまたもう1個次数、P,D,Qがあります。そして周期を表すmを用いてこんな感じで、この赤字で示した感じで表記します。このパラメータの意味するところは正直私にはよく分からないので、お近くに機械学習に詳しい方がいらっしゃったらお聞きくださると非常に助かります。 では、これらのデータを埋めていきます。差分のd,Dの部分は、1が一般的らしいので1を使っていきます。なぜかは聞かないでください。mは季節周期なので、データによって個別に設定いたします。今回はここの部分がmになってきます。なので1日周期です。1日周期なので、m=24となります。それで残ったのがp,Pとq,Q、この2つを埋めていく必要がありますが、ここでpmdarimaのすごいメソッドが登場してきます。auto_arima()、”自動arima”というメソッドがなんとあります。最適な次数を出してくれる最強メソッドで、総当たりでモデルを作成してその中で一番結果のよいものを自動的に選ぶような挙動をします。そのモデルの評価には赤池情報量基準（AIC）というものを使っていきます。これも何かは聞かないでください。こんな感じで表示があるのですけれども、AICが小さいほどその結果がよいモデルというふうに認識します。最終的にこの(1,1,1)(2,1,1)というARIMAのモデルが選択されました。このように(1,1,1)(2,1,1)の次数が選ばれました。これが一番よいモデルになります。 これで問題に最適なモデルを探索することができたので、最後、テストデータで結果を確認していきます。今回はmodel.predict()というメソッドを使って予測の数値を出していきます。このn_periodsは、そのpredicateの長さを表します。今回はテストデータの長さ分を出します。そしてもう1つ、return_conf_intというものにTrueを入れていますが、これは何かというと、信頼区間の配列をリターンするかどうかのパラメータとなります。信頼区間というのは統計的に真の値が含まれる可能性の高い範囲を指します。このグラフでいうところの灰色の部分、これが信頼区間になります。信頼区間のminと信頼区間のmaxが2つデータとして出てきます。実績値がこのminとmaxの間だったら予測は当たりとなります。 最終的に同じグラフに対して予測データとテストデータをプロットしてみました。こんな感じで、よい感じに予測できているのではいう結果が出ました。 作成したモデルで予測APIを実装する 作成したモデルで予測APIを実装していきます。アラートが出せるようなAPIとして実装していきたいので、メトリクスとしてexporterの形式でレスポンスを返せてPrometheusが収集監視できるとよさそうだなと思ったので、exporterとして実装していきます。GitHubの私のリポジトリのpromadというプロダクトとして実装しております。引き続き pmdarimaを使うためにPythonで実装しているexporterになります。 それでは、最適な次数を手に入れたのでそれを入力値として持っていきます。rules.yamlにクエリとそれに対するARIMAの次数を指定して、yamlを書いてあげてこれを入力とします。次数が既知の場合はpmdarimaのメソッドを使ってモデルを作成することができます。このようにfit()とやると学習させることができて、モデルが出てきます。探索するよりも計算量が少なめになります。orderはtupleなのでliteral_evalメソッドを使ってstrをtupleにしてあげます。そしてfit()の入力の部分にはPrometheusをクエリしたデータを入れてあげます。このquery_range()メソッドでラップしていますが、これはクエリの結果になります。これが実際のメトリクスとして出している部分ですが、大まかにどんなことをやっているかというと、model.predict()、先ほど使ったメソッドで予測値と信頼区間を出して、現在時刻と一番近い時刻の予測値を出して、現在時刻の実績値を出して、現在値が信頼区間に入っているかを計算して、Prometheusがscrapingできる形式に変換してレスポンスしてあげる、こういった流れになります。大事なのはこの部分、現在時刻と一番近い時刻の予測値を出すという部分ですが、なぜこんなことをやっているかというと、Prometheusの制約として過去や未来の時刻のメトリクスをPrometheusは入れることができません。その収集したタイミングの時刻のデータとして、Prometheusは認識します。なので、モデルを作成した時に過去2～3時間前までのデータを使ってモデルを作って、そしてscrapeした時に予測値を出して、その3個目の値、2時間前までのデータを使ったら2時間後の値を出すと現在時刻のデータになる、そしてそれを収集させる、そういったことをさせる必要があります。こんな感じで、現在時刻が例えば深夜0時だったとしたら、現在時刻の2時間前、10時からのデータを使ったら11時と深夜0時のデータが含まれてきて、この一番近い予測値を出してきてそれを実際に使うというようなことをやる、という感じです。そして最終的に exporterとして収集できる形式で予測値を出力します。で、Prometheusにscrapeさせて完成となります。この紫の線（図では赤線と書いてありますが）が実績値で、その上下の線が信頼区間となって、実際、実績値の間に信頼区間、実績値が信頼区間の間に入っているので概ねよさそうな感じに見えます。そして、最終的に異常検知したかどうかというメトリクスとして、anomaly_detectedメトリクスを作りました。これが0か1かで、1だったら予測から外れた、anomalyがdetectedされたというような表現にして、これを監視しているだけである程度よい監視ができるようなメトリクスにしてみました。 異常検知APIの課題 それでは最後に、異常検知APIの課題をお話しいたします。なんと、これだけではしきい値監視を卒業できないということに気付いてしまいました。タイトル詐欺をしてしまったのですけれども、結果そうなってしまったという感じで、課題について言っていきたいと思います。 まず1つとしては、リソース使用量がとても多いという課題が挙げられます。データ間隔が1時間のメトリクス1つに対して、2.8GHzのCPUにリソースリクエストとして2000m割当を使ってそれを100%消費されて、だいたい1分ぐらい1つのモデルを作るのに時間がかかってしまいます。さらに傾向が変わるとモデルを作り直さなければいけなかったり、時間経過によってモデルの鮮度が落ちてしまって作り直さないと精度のよいモデルにならなかったり、そのようなことがあるので、結構何回もモデルを作る必要がありました。すべてのメトリクスを異常検知モニタリングするには、リソース使用量の削減の工夫が必要そうだなと思いました。 さらに、苦手な時系列が存在するということに気付きました。先ほどのメトリクスのような一定周期のものは得意ですが、例えば単調増加とか徐々に増加していく、こういったグラフは変化に追従していってしまうため苦手だ、ということが分かりました。Seasonal-ARIMAが苦手というだけなので別の手法を使えばよいのですけれども、CloudWatchはこの点12,000以上の内部モデルにルーツを持っているというふうに書いてあるのでめちゃめちゃがんばっているんだなぁという感想は得ました。すごいなあと思いました。 終わりに 異常検知の道はまだまだ続くよ！ということで、実際に実装してみて有用性は確認することができました。しかし、既存のしきい値監視の置き換えはまだデータ量や計算量の問題で難しそうだということが分かりました。さらにこのpromad自体の実装としてはまだまだいくつかやることがあるので、それをやっていきたいと思いました。そしてインフラ課題をこのようないろいろな技術を使って解決していきませんか？We are HIRING!!!ということで、ぜひ弊社に応募していただけると嬉しいです。 ということで、今回の発表をおしまいにしたいと思います。ご静聴ありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/pjvyqWwrbzA

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、CFPセッション「ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践した話」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　技術部プラットフォームグループ（PFG）渡部 龍一（@ryuichi_1208） 「ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践した話」 https://speakerdeck.com/ryuichi1208/pepabonosregasheng-chan-xing-noxiang-shang-womu-zhi-sicloud-nativenatimuzuo-riwoshi-jian-sitahua プロローグ 本日は、パパボのSREが生産性の向上を目指しCloud Nativeなチーム作りを実践した話というタイトルでお話ししていきます。 最初に、簡単にプロローグの話からしていきます。これは2021年の11月頃の上司と私の会話になります。「チームの体制変わるんだけど、スクラムマスターやってみない？」という声をかけていただき、私は二つ返事で「やったことないけどやってみます！」と回答しました。それに追加した情報としては、「今後も人増えたり移動したりってのは短期的に発生する予定です」ということで、私は「チームをスケールさせる必要があるということですね」と理解しました。 本日のセッションは、スクラム経験がほぼなかった私が、SREチームのスクラムマスターとして1年間奮闘したお話となっております。対象者はチームでの開発を行っているすべての方と思っております。 自己紹介 最初に、簡単に自己紹介をさせていただきます。私は渡部 龍一と申します。所属は、技術部プラットフォームグループというところで仕事をしています。以降、「PFG」と省略させていただきます。役割としてはSREがメインで、あとはスクラムマスターを兼任しております。好きな言語はGo言語で、好きなミドルウェアはNginxです。趣味は旅行、ドライブだったり技術書集め、ちょっと古めの技術書が好きで古本屋などへ行ったら見ています。 セッションの内容にも関わるので、ちょっとだけ経歴についてお話しさせていただきます。2017年から2019年は、Linux向けファイルシステムの開発プロジェクトに開発メンバーとして参画していました。そのあとは、ニュースサイトの運用開発ということで、こちらも2年ぐらい開発メンバーとして参画しておりました。2021年7月にGMOペパボへ入社して、ちょうど1年前、2021年11月に現チームのスクラムマスターになりました。 所属チームの紹介 次は所属チームの紹介をさせていただきます。先ほど申しましたように、私が所属しているのはPFGというところで、役割としてはGMOパパボのサービスの可用性を確保し、成長に合わせて適切な環境を提供するグループとなっております。ミッションとしては、サーバーの調達やキッティングに留まらず、SREによるサービスレベルの向上や、あとはクラウド環境の検証や選定を行い、必要に応じて事業部門のアプリケーションの改善、開発を通して事業の成長を支えるというものになっております。 簡単にいうと、主な活動としては事業部を横断したSRE活動などを行っています。詳細に関してもし興味があれば、過去に登壇した資料があるので、こちらのスライドをご覧ください。 もう少しチームの内容を深掘りしていくと、PFGは14名いまして、その中でさらにチームが細分化されており、3つのチームに分かれております。その中でも私が入っているのは「pfg-ec-team」と呼ばれているチームで、カラーミーショップやGoopeといったサービスを主に見ているチームになっております。これらのサービスインの時期は2005年からや2009年からなので、17年ほどのサービスとなっております。 Cloud Nativeなチームと生産性の定義 本題に入る前に、まずは「Cloud Nativeなチーム」と「生産性」の定義をしたいと思います。Cloud Nativeとは、CNCFが定義しているCloud Nativeについての文章があるので、こちらから抜粋しております。その中でも、チームビルディングに役立ちそうなものに関して赤字を引いております。特に、「回復性、管理力、および可観測性のある疎結合システムを実現します」という部分に私は目を付けました。あとは「堅牢な自動化」だったり、「エンジニアのインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができる」といったところに、何かしらのチームに対してできるのではないかと考えています。これらの内容をそれぞれまとめますと、以下のようになっていくと思っております。先ほど述べられていた回復性、管理力、可観測性は、チームにおいてこんな感じで生かせると思っております。回復性から見ていくと、障害時や不測の事態でチームの体制が一時的に崩れたとしても、やるべきタスクをこなせている状態、管理力については、現状のチームの状態を管理できている、例えばチームが抱えている不安要素などを把握できている状態が、管理力のあるチームだと思っております。あとは分かりやすいところでいうと、可観測性の部分になりますが、パフォーマンス、のちほど定義される生産性を可視化できている状態が、可観測性のあるチームだと思っております。 疎結合と弾力性についてですが、疎結合なチームとは、メンバー全員が主体性を持ってタスクをこなせている状態、弾力性はメンバーが増えても短い時間でパフォーマンスが出せる、メンバーが仮に減ってしまったとしても、タスクの引き継ぎや割り振りなどの変更が容易である、こういったチームを「Cloud Nativeなチーム」と定義しております。 なので、Cloud Nativeと呼ばれるものは、モダンなソフトウェアを使って構築されたサービスでないように、「Cloud Nativeなチーム」も同じくモダンなツールを使っているチームではない、と私は考えております。 続きまして、今回の発表での「生産性」の定義をしていきます。生産性という単語の意味としては、「費やした資源に対し、どれくらいの成果が得られたのか」という指標になります。SREチームということで、サービスに対するシステムの開発なども行うので、今回指標とした生産性は、デプロイの頻度、例えば特定リポジトリでのデプロイフローの実行回数を計測しました。あともう1つは、チームが割り振られたタスクがあって、そのうち実際に完了させることができたタスク数、それぞれを生産性の指標として挙げております。 我々のチームが抱えていた課題 続きまして、我々のチームが抱えていた課題の話をしていきます。我々のチームが抱えていた課題としては、担当しているサービスが冒頭でも述べたようにサービス開始して約17年と長く続いているサービスとなっております。そういった中でSREとしてサービスの運用を行っていましたが、ドキュメントや構成図がないなど、暗黙知に頼り切った運用が前提となってしまっておりました。そんな中で、プロローグにもあったように、2021年11月にチームの体制変更があって、ガラッと変わってしまったというのがありました。体制変更後には、生産性の部分はだいぶ大きく下がってしまった状態となってしまいました。 体制変更を簡単に図にするとこんな感じです。上が体制変更前、下が体制変更後となります。サービスに携わった期間が長いメンバーが3名、短かったメンバーが3名でやっていたのですが、体制変更後は長かったメンバーが1名に減ってしまって、歴の浅いメンバーが4名というチームになってしまいました。 生産性の低下を招いた原因を考察しました。暗黙知による運用・開発がメンバー入れ替えによって通用しなくなったのが大きな原因と思っております。例えば「何かをするのに実は○○が依存している」というのを知っているメンバーがいなくなってしまったので、必然的に作業するのに対してもすぐに終わらせることができない、といったようなイメージです。サービスのデプロイ1つとっても、mainブランチへマージしたあと、何をすればいいのかということが文書化されていないので、記憶に頼っていたものが一切できなくなってしまい、実は何もできていなかったということが起きていました。 あとは、必要な技術スタックに関して習熟しているメンバーがいなくなったというのもあります。左の図にあるのが、我々の勤務で見ている技術スタックの一部になりますが、これだけの数を使っております。それぞれ簡単には使えないものが多く、必要な知識が幅広く、メンバー間に知識格差が生まれてしまったというのもあります。例えば、Kubernetesクラスタのアップグレードや、MySQLの設定値の変更について、タスクごとの属人化がより進んでしまい、仮に誰かが休むとその分がタスクの遅れに直結してしまっていました。 課題に対して実際に行ったアクション ここからは、こういった課題に対して、具体的に実際に行ったアクションについてお話ししていきます。大きく2つに分けてお話しします。 あらゆるチームルールの言語化と文化作り 1つは、あらゆるチームルールの言語化と文化作りを行いました。あらゆるチームルールの言語化と文化作りに関してお話しします。チーム作りにおいて割と重要視したのは、タスクをこなすだけでなく、良かった動きは再現性を高めるために、行動の言語化を徹底しました。言語化するメリットは以下のように挙げていて、物事を整理して考える力が身につき、自分の思考を客観視することができる、あとは観察力、思考力、要約力といった力を意識するきっかけにもなります。あとは、言語化しておくことによって、例えば新メンバーが参画した時には、我々のチームがどう考えてどういう風に行動しているかの共有を行いやすくなりました。 ちなみに、この言語化はIaCにおける宣言文と命令文の考えからヒントを得ております。例えば、決めたルールは宣言文として言語化することで、チームでタスクをこなす上でありたい姿の共有を行うことができました。このあと実際に言語化した内容を紹介しますが、それらの内容は全メンバーがある程度同じ品質で再現可能な状態に持っていくことができました。 具体的に言語化したものは次のようになります。チームの発足時に考えたチームテーマというものがあり、それを言語化していきました。テーマは「ハイスケーラブルなチーム」を目指しました。狙いとしては、弾力性のある、スケーラビリティのあるチームを目指すものになっております。特に、頻繁にメンバーの入れ替えが発生するということは分かっていたので、入れ替わり時にスムーズにバリューを出せるチーム作りが必須だと思い、ドキュメントの作成、環境構築などの自動化、複雑な手順はゼロベースで単純化を実施する、などを行いました。 ほかにも、タスクの重要度や優先度の決め方についても言語化しました。例えば、仕事をする上で自分たちが大事にしている考えを全員で共有した上で決定、新しいタスクの発生時にはスライドの右下にある「家訓 - タスクの優先度」を決めて、こういったものをルールをもとに作業のアサインなどを実施していました。もちろん例外はあります。あと、大きめのタスクには担当者を明示的にアサインしております。SLI/SLOの策定・運用や、マルチクラウド化といわれるものを現在我々は行っていますが、そういった年単位、半年単位で行われるタスクについては、スクラムメンバーひとりに責任を持つために、責任者をアサインしています。 あとはドキュメントの作成の定着といって、コードレビュー時のドキュメント更新の有無や、古くなったドキュメントの継続的見直しなどを定期イベントとして開催して、書くのが当たり前のチームへ向かいました。ほかにも、インセプションデッキの継続的なアップデート機会を提起しました。実態に即しているかを四半期に1回程度見直すことで、ある程度、自分たちがなりたい姿ややるべきことを見直すタイミングを作りました。 こういったチームテーマやチームルールを行う上でのTipsとなりますが、こういう考えで今後はこんなチームになっていきたいといった考えを言語化してメンバーに伝えることが大事だと思っています。策定する際は、「こう思っているんだけどどうする？」のように、決定事項として共有するのではないことを心掛けたりしました。 言語化してよかったこととしては、新しくメンバーが入ってきた際に、言語化されている状況から文化や風土などを読み取れることができるようになりました。あとは、ルール自体は結構頻繁に作成しては破棄をしたりしていたので、ルールを浸透させやすい文化ができあがったと思っています。 スクラムイベントの見直し もう1つはスクラムイベントの見直しです。前述のとおり、技術スタックが多く、それらに習熟しているメンバーがいなくなりました。例えば、体制変更前に30分でできていた作業、TerraformでMySQLのパラメータを変えるとか、アラートが出た時に即座に対応できるようなものも、1日掛かってしまうことが散見されました。そういった時に考えられるのは、弾力性の面でいうと、メンバーが減ってしまった時にタスクの引き継ぎや割り振り変更が容易である、とはいえないチームになってしまっておりました。 なので、目指したい姿とのギャップを埋める方法を模索しました。チーム事情より知識格差が大きいという課題もありました。知識格差を埋めるためには、スクラムイベントやチームのイベントとして取り組むべきだと判断しました。 スクラムイベントの見直しの内容としては大きく2つあって、メンバー間の会話する機会を増やすのが大事だと思って取り組みました。進捗報告で止まってしまっていたデイリースクラムでディスカッションを促すようなタイムスケジュールへ変える、あとは雑談時間を意図的に入れるなどをしました。 あとはモブプログラミング用の時間を毎日入れて計画を行いました。デイリースクラムの時間で収まらなかったディスカッションをやる場として、事前に予約してカレンダーに入れたりもしました。この内容に関しては、プログラミングだけでなく、プルリクエストのレビューだったり、あとはトラブルシュートなども実施しました。 ほかにも小さなものとしては、タスク消化数などの計測を行いました。あとは勉強会やLT会の開催です。特定技術が得意なメンバーに依頼して、会を開催するなどして知識格差を埋める取り組みなどを行いました。それぞれの得意領域をメンバー間で認知することで、その分野における主体性を持った取り組みが行えるような試みを行いました。 結果 実際にこれらの課題に対して行ったアクションで、どのくらい結果が出たのかについてお話しします。 縦軸がタスク数と本番環境へのデプロイ数のグラフになります。青線がこなしたタスク数で、緑線がデプロイ回数です。一応どちらも右肩上がりにはなっているように見えます。タスクについては1.5倍をこなせるようになった、マージ数に関しては4倍近い数字を出すこともできました。なので、効果はあったと考えております。 ただ、メンバー間で数値にばらつきがあるのが現実です。また、こなせているタスクの数に関しても、実はまだまだ自分たちでやれるのではないかという思いがあるので、この結果について満足はしていないという実態があります。なので、グラフ上では伸びていますがまだまだ道半ばという感覚です。今後も改善を続けていく必要があります。 では、我々は「Cloud Nativeなチーム」になれたのか、という話をしていきます。回復性については、コミュニケーションを増やすことで例えば障害時でも期限のあるタスクをこなすことができました。ただ、属人化はもちろん排除し切れておらず、特定メンバーがお休みした際にはタスクが進まないなどといったものは変わらず発生しています。管理力については、インセプションデッキを定期的に見直すことで、現状のチームが抱えている不安などを把握できている、そういったチームにはなったと思っております。 可観測性の面に関しては、可視化はできました。ただ、可視化できただけで、具体的にそれをもとにしたボトルネックの特定や改善活動へ活かすといった、データドリブンな行動までには至りませんでした。なので、ここについてはまだまだ伸びしろがあると思っています。疎結合に関しては、メンバーの得意領域において主体性を持って取り組めるようになったというものがあります。これは、モブプログラミングや勉強会の開催で培われたものと思っております。弾力性については、ドキュメントの整備やルールの言語化で、新参画メンバーがバリューを出すまでの時間が短くなったと思っております。受け入れ体制が整ってスケーラビリティの向上を実感しております。 まとめ 最後にまとめとなります。Cloud Nativeな考えというのは、チーム作りにも活かすことができたと思っております。ただ、実績が出るまでには時間がかかるので、「近道はない。やるしかないんだ。」ということを常に念頭に置く必要があると感じました。今後やりたいこととしては、可視化の部分に関してFour Keysの指標のうち1つしかできていないので、可観測性をより上げて取り組むべきと思っております。 以上で発表を終わります。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/McLhpnvh85k

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、CFPセッション「実例から学ぶ Kubernetes Custom Controller のステータス管理」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　プリンシパルエンジニア高橋 拓也（@takutaka1220） 「実例から学ぶKubernetes Custom Controllerの状態管理」 「実例から学ぶKubernetes Custom Controllerの状態管理」と題しまして、GMOペパボの高橋 拓也が発表させていただきます。 https://speakerdeck.com/takutakahashi/shi-li-karaxue-bu-kubernetes-custom-controller-nozhuang-tai-guan-li 自己紹介 まず最初に自己紹介をさせてください。GMOペパボでインフラエンジニアをやっております高橋 拓也と申します。コードを書くことと、Kubernetesといじることが好きで、自宅サーバーを飼っていることが僕の自慢です。これが終わったら自宅サーバーをもう1個飼おうかなと思っております。おすすめを教えてください。 宣伝です。GMOペパボでは、CNDT2022で合計5セッションの登壇を実施しております。本日分はすべて終了してしまうのですが、明日11月22日、Track Fで13時20分から14時の間にハーフセッションが2本予定されております。ぜひこちらをご覧ください。 Kubernetes Custom Controllerの難しさ Kubernetes Custom Controllerの難しさについて語っていきたいと思います。 みなさん、カスタムリソースというものを使っていますでしょうか？カスタムリソースとは、Kubernetesの自作リソースを作成できる機能のことと、その機能で作られたサードパーティーなリソースのことを主に指します。’kubectl get ○○’などで操作できるようになるようなリソースです。身近なクラスタでこのカスタムリソースの定義であるCustom Resourcce Definitionをgetしてみるとどうなるでしょうか。だいたいこのくらい出てくると思います。マネージドなクラスタを使っている場合、例えばEKSとかGKSなどを使っている場合は、それぞれのプロバイダが入れているカスタムリソースディフィニションが出てくるといったこともあるかと思います。なので、使ってないという方はたぶんいらっしゃらないと思います。 カスタムリソースを作ったことはありますか？kubebuilderというジェネレータを使うと、意外と簡単に作成することができます。主な作り方に関しては、zoetroさんという方の「つくって学ぶkubebuilder」という資料が非常に参考になるので、ぜひこちらをご覧いただければと思います。特に何か実装しなくても、‘kubectl get （自分の作ったリソース）とやるだけでもだいぶテンションが上がるので、1回作ってみると楽しいかもしれません。 カスタムリソースをきちんと実装することはできるのでしょうか？これはとても大変で、というのもリソースを単体で作っただけだと、etcdに格納されたデータでしかない、それ以上でもそれ以下でもない情報になってしまいますが、これにカスタムコントローラを加えると、それによって操作対象をリソースに沿った状態へ収束させて、いろんなオペレーションをすることができるようになります。しかしこのカスタムコントローラの実装が非常に大変だと僕は思っております。 コントローラの大変ポイントは、主にこの3つです。 テストを書くことが大変複雑な処理を実装するのが大変監視のためのメトリクスを実装するのが大変 今回は、この「複雑な処理を実装する」という部分にフォーカスしてお話をしていきたいと思います。 複雑な処理とは何かというと、状態遷移が多い処理のことを指すと思います。様々な対象からデータを取得して、そのデータをこねこねして目的の状態に収束させる処理を指すと。そして、Kubernetesの概念としてReconciliation Loopという概念があります。これをそのまま忠実に実装していくのが結構大変です。今回は詳しい説明を割愛して他の資料に回しますが、何度もループを回して理想状態に収束させるような動作のことを指します。 軽く図で説明しますとこのようになっています。リソース内容に更新があるたびにReconcileのメソッドが実行され、Reconcileの中でリソースの状態を更新したり、別の操作対象を更新したりします。その繰り返しを行って、操作対象を理想的な状態へ収束させるという流れがReconciliation Loopです。 Deploymentの挙動から見る状態管理の難しさ Deploymentの挙動からその状態管理の難しさというものについて詳しく見ていきたいと思います。ローリングアップデートをDeploymentするのですけど、それって難しくないですか？僕は実装できる気がしません。ローリングアップデートというのは、Pod全体の一部の割合を順繰りに更新していくようなやり方のことを指します。例えばPodが3つあったら1つずつ新しいバージョンに更新していく、そういったものがローリングアップデートと呼ばれます。 例えば、この図のように青いPodから赤いPodに状態を更新していくようなローリングアップデートを見ていきたいと思います。今回は左から右の赤いPodにPod Aの部分がアップデートされたと、次はこの真ん中の青いPodをアップデートしましょう、とした時に、何らかの原因で青いPodが消えてしまった、delete podしたということだったり、ノードのハートビートがなくなって応答がなくなってしまった場合も考えられます。こういった時に、ではこのBのPodを新しく作るのが正しいのか、赤い状態で作るのが正しいのか、青い状態で作るのが正しいのか、これをどうやって判断しましょうか？というような難しさがあります。 これを文章で表すとこのようになります。Podの更新有無の管理や、更新中のPodの更新の成功可否の管理、あとは先ほどのPodが削除されてしまった場合のようなイレギュラー時の処理の決定など、これらのようなことが難しい。これらをまとめて、リソースの状態管理と今回は呼ぶことにして、このリソースの状態管理が非常に難しいと感じております。 状態管理の種類と実例紹介 それでは他のプロダクトなどはいったいどうやってその状態管理を行っているのか、その実例とともにご紹介していきたいと思います。 今回はこの3つのプロダクトについて実装を確認していきます。1つはKubernetesのDeployment、もう1つはcert-manager、もう1つはrookです。 Deploymentの状態管理 まず、Deploymentはどのようにやっているのかをご説明したいと思います。 Deploymentは、ReplicaSetという子リソースを持っています。ReplicaSetがPodの個数を管理するという役割を持っており、Deploymentは直接Podを操作するような役割を持っていません。ReplicaSetを介してPodを操作します。例えばReplicaSetがReplica:3の場合、Podが1個消えた場合だともう1個立て直す、といったようにReplicaSetがPodの個数の管理を実行します。そして特徴的なのは1つのReplicaSetのうちにぶら下がっているPodはすべて同じ設定、同じバージョンのものが動いていて、そのバージョンを変更したい場合はもう1つ別のReplicaSetを作って状態をなんとかするという運用になります。 そしてこのローリングアップデートは、ReplicaSetをうまく使うことで実現しております。Deploymentの中に2つのReplicaSetがあり、新しいバージョンのPodを司るnewと、古いバージョンのPodを司るold、この2つがある状態になってます。このoldからnewにPodを移し替えていくことがローリングアップデートです。 今回このnew rs のreplicasを1にして新しいPodを1個立てます。そうするとnew rsがNot Readyであるという状態を持ちます。Podが起動してくるまでこのNot Readyの状態は続いて、これがReadyになるまでDeploymentは処理を停止します。Readyになったら、今度はoldの方のReplicasを1個減らして、またReadyになるまで待機します。それを以下繰り返して、このようにoldが0、newが3の状態になってローリングアップデートが完了する、こういったような処理の流れになっています。 ではローリングアップデート中にPodの削除が発生したらいったいどうなるのでしょう？その場合は、oldのReplicaSetがその責務を全うすべく、Podを1個立てます。Podが立っている間、ReplicaSetはNot Readyの状態を持つため、Deploymentは処理を中断します。oldの方の処理を待っている状態です。そして、oldの処理が終わってReadyになったら、処理を再開します。この流れを「単一責務パターン」と今回呼んでみることにします。責務の異なるリソースの階層構造となっており、子リソースにPodの管理などの責務を委譲しているという形で実装しているといえます。この単一責務パターンのメリットとしては、Deploymentは想定するReplicaSetが作成できるかどうかに特化すればよいため、実装がシンプルに保てます。DeploymentはReplicaSetを作るだけなので、Podを作ったり、そのほか何かいろいろしたりすることはありません。さらに、リソースのテストもDeploymentを入力として出力のReplicaSetがどうなったかをチェックするだけで済むので、リソースのテストも記述しやすいものとなります。さらに、このパターンは自作のカスタムリソースにも非常に応用しやすい形だと思っていて、例えば何かしらPodを立てたい、ワークロードを動かしたいなどの要求があった時には、Deploymentをとりあえず作っておけば、そのほかの状態管理に悩むことはなくなります。複雑な状態管理は、得意なほかのリソースを選定してそれをカスタムリソースの処理の中で作成してしまえばよくなります。例えば、Podを複数立ててロードバランスをしたくなったら、サービスリソースを作ればよいというように、どんどんそのほかのリソースに対して責務を委譲してあげることで自分は楽ができる、そういったような実装ができます。 デメリットとしては、結合テストが結構難しくなると思います。例えば最終的にワークロードを立てる、Podを立てる際にそのPodが本当に起動してちゃんとそのパラメーター、コマンドライン引数を解釈してきちんと動いてくれるかというのは、実際のところ動かしてみないと分からないようなことがあったり、Podが立たない、リソースが足りないとかアフィニティが付いていてPodがペンディングになってしまっている状態をきちんとその親のリソースが解釈できるかというのも、実際にPodを立ててみないと分からなかったり、もうちょっと詳しいテストをやってみないと分からないので、少し結合テストが必要になってくるような場合があります。 さらに、自作のリソースを作る時の最大のデメリットは、状態管理の実践の仕方を学習できないという致命的なデメリットがあります。今は、Podの状態をReplicaSetに委譲しているのですけれども、ではReplicaSetを作りたくなった時はどうすればいいのか分からないですね。それはどうしていこうかというのは、次のプロダクトを見ていくと若干分かるかなと思うので、見ていきましょう。 Deploymentのまとめです。1つのリソースにつき1つの責務を管理する、単一責務パターンを使っています。リソースの通知する状態を監視することで、状態を管理してうまく運用しているという流れになっています。 cert-manager cert-managerについて見ていきます。cert-managerは、証明書を管理、運用するプロダクトです。主なユースケースとして世の中で使われているのは、ACMEプロトコルを利用してLet's Encryptの証明書を作るというのがだいたい行われていますが、その他にもself-signedの証明書を作ったりとか、HashiCorp Vaultから証明書を作ったりとか、結構いろいろな機能があります。このcert-managerですが、複数のCustom Resource Definitionが連携して、単一的なパターンを踏襲している作りになっています。いちばんトップのリソースとしては、 Certificateリソースがあります。これはそのまま名前の通り証明書の情報を持つリソースで、issuerという証明書を発行するための情報を持ったリソースから証明書作成に必要となる情報を参照してどんどんやっていくという流れになります。このCertificate自体は証明書を作らずに、CertificateRequestが証明書を作る処理をまた子リソースに委譲していくという流れをやっています。Certificateリソースが完了するまで待機して、完了したらそのTLSの実体となるシークレットリソースを作る、そういった役割を持っています。そして、CertificateRequestなどの状態管理にこのStatus.Conditionsというものを使っています。ここにあるのはCertificateのConditionの例ですが、’kubectl get ○○-o yamlした時にこういうステータスを見たことある方は結構いらっしゃるのではないかと思います。このConditionというのは、特定の状態を確認するという目的で使います。 今回ちょっと例を用意しました。「カレー作り」をConditionで再現してみます。カレーを作るコントローラがそれぞれの状態を見てどういうことをやっていくのかというのを決めていきます。今ここまでは、肉に火が通っている状態までがあって、鍋に水が入っておらず、カレーはできていない状態を作っています。そして、このコントローラは各状態を表すConditionを見て次の行動を決定します。ここまでできているのだったら次は鍋に具材と水を入れて火にかけるということを導き出せるような状態の作りになっています。そして仮に別スレッドや他のコントローラが鍋に水を入れると、鍋に水が入っている状態を更新して、Trueにします。その場合、元いたコントローラはその状態をさらに見て再度何をやるかを決定します。この場合は先ほど水を入れていましたが、今は水を入れる必要はないので、鍋に具材を入れて火にかける、というのが次のアクションになります。こうやってConditionを使っていきます。 Certificateリソースは、2つのCondition Typeを持ちます。Ready:処理が完了しているかどうかと、Issuing:処理中かどうか、の2つのConditionを持っています。意味はたぶん若干違うのですけれども、こういう解釈をしました。IssuingがTrue、つまり処理中である場合、新しいCertificateRequestを作るといった実装がコード中に見られます。さらに、Certificateは証明書の再作成も責務とします。Let's Encryptの証明書は90日で切れてしまうので、いずれかのタイミングで再作成（e-issue）をしないといけませんが、それを必要かどうかをCertificateリソースは監視しています。証明書が再作成する必要が出てきたら、このCertificateリソースのコンディションのIssuingをコントローラがTrueに書き換えます。そうすると、その状態の収束に必要な処理がガチャガチャと動き出して、再度証明書が作り出されて、IssuingがFalse、ReadyがTrueになるという状態になります。つまり先ほどの図のところではCertificateRequest.Status.ConditionsのReadyというタイプがTrueになるまで、Certificateリソースは処理を見続ける、監視するといったような振る舞いをすることが処理の実態としてはいえます。 CertificateリソースはOrderリソースを作って、OrderリソースはChallengeリソースを作ります。そして、ChallengeリソースはACME Challengeを実行してその結果をOrderに通知して、OrderはCertificateRequestに通知して、CertificateRequestはCertificateに通知する、そういったバケツリレーのような形になります。 cert-managerのまとめです。Certificateを頂点とする階層構造を持ちます。状態管理はConditionsパターンを用いており、親は子リソースの状態をステータスコンディションから取得します。 rook 最後にrookです。rookはCloud Nativeなストレージクラスタオペレータで、国内ではサイボウズさんがrook/cephを使ってCephクラスタをプロビジョニングしたり管理したりするために使っています。サイボウズさんは積極的にrookを開発していて、すごいと思いながら見ております。 今回はCephClusterリソースについてご紹介します。CephClusterリソースは、そのままCephのクラスタバージョンや、Cephが動くのに必要なプロセスの個数などを管理するために存在します。CephClusterもConditionを持ちますが、コントローラからはほぼほぼ参照されないものです。ではこれは誰が参照するのかというと、実際のユーザーである私たちが目で見て参照します。今その処理の状態がどこまでいったかをこのMessageというアトリビュートから見るというようなことをやるために存在すると、ソースを見る限り思います。 では状態はどうやって管理しているのかというと、実際状態は全く管理していません。OperatorのReconcile関数内ですべての手順を1回実行します。つまり先ほどループがあったじゃないですか、そのループ1回ですべての処理を終了させるというのがrookのOperatorになっています。各手順が高度に冪等性が担保されており、何度実行されても大丈夫です。なぜrookは状態を管理しないのかを推測してみたのですけれども、Cephクラスタはk8sクラスタ1個に対して20個も30個もできるものではないので、1リソースに対して使える処理時間が長いという特徴があるのと、そもそもCephはストレージのクラスタなのでデータの耐久性を何よりも重視しているということが挙げられると思います。なので逐一状態を見ながら1つのスレッドでやった方がより安全である、そのためにそういうふうな作りになっていると思います。余談ですが、状態を管理しないのでテストがめちゃめちゃかっこいいです。これは、r.Reconcileを実行するというテストで、これめっちゃいいなと思いながらソースを見ていました。 rookのまとめです。状態を管理しないという選択肢もあるというのを、これを見て思いました。 まとめ 最後にまとめです。状態管理はとても難しく、イチから実装するのはとても大変です。その代わりに、広く使われているリソースの肩に乗ることで楽をすることができます。今回見た単一責務パターンのようにです。さらに既存の実装をよく観察することが大事です。Conditionsパターンはコアのリソースでも使われており、とても広く使われているので、いろいろな実装を見ることで自分のものにして自分のコントローラを実装することができると思います。 最後に、多くの自作コントローラを弊社では本番投入しながら実践で学んでいっております。一緒にコントローラを開発して状態管理は難しいという話をしてみませんか？We are HIRING !!!ということで、このURLから弊社の募集などを見て、ぜひ弊社に興味を持っていただけたら幸いです。 それでは今回の発表はこちらで終了とさせていただきます。ご清聴ありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/8w9oKMeUDD8

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、CFPセッション「k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　技術部プラットフォームグループ シニアエンジニア/SRE菅原 千晶（@ch11aki） 「k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話」 https://speakerdeck.com/ch1aki/k8s-operatordeyun-yong-fu-dan-jian-and-haiburitudokuraudonokosutozui-shi-hua-wositahua 「k8s Operatorで運用負荷軽減とハイブリッドクラウドのコスト最適化をした話」と題しまして、GMOペパボ株式会社 菅原 千晶が発表します。 改めまして、GMOペパボの菅原 千晶と申します。弊社ではあだ名文化があり、社内では「akichan」と呼ばれています。私が所属する技術部プラットフォームグループは、特定のサービスの事業部には所属しない、サービス横断のSRE組織です。サービス運用の効率化、サービスレベル目標設定や、それを達成できるようにするための支援などを行っています。私の簡単な経歴としましては、2018年3月に未経験者向け研修付き採用制度の「ペパボカレッジ」枠で入社しました。昨年までは主にネットショップ作成サービスのカラーミーショップの運営に携わり、k8sの導入支援やGitOpsの推進などを行ってきました。現在はハンドメイドマーケットサービスのminneに注力し、サービスの信頼性とエンジニアの生産性を向上させるあらゆることに取り組んでいます。最近ではArgo Rollouts導入によるプログレッシブデリバリーの実現や、CDNコストの削減、RailsアプリのN+1問題の解消などを行いました。 本日お話しするのは、タイトルにある通り私が担当するminneの運用において、k8s Operatorを開発して運用課題を解消した話です。まず、minneのインフラ構成とそこにあった運用課題について説明します。そして、そこで得られたk8s Operatorで運用課題を解決することのメリットについて説明します。Operatorの詳細な実装方法などについては時間の都合上触れられませんので、発表を聞いてOperatorの開発をやってみたいと思った方は、ご紹介する書籍やWebページ等をご覧ください。 Section1│minneのインフラ構成 それでは、まずminneのインフラ構成から説明いたします。私が担当するminneは、ハンドメイド作品をインターネット上で販売・購入できる国内最大級のハンドメイドマーケットです。数値でみると、作家・ブランド数は80万件以上、作品数は1,500万点以上、モバイルアプリのダウンロード数は1,300万件以上の大規模なサービスとなっています。 そんなminneのインフラは、AWSとプライベートクラウドのハイブリッドクラウドで構成されています。ペパボではNyahと呼ばれるOpenStackベースのプライベートクラウドを持っています。AWSではEKS、Nyahではself-hostedのk8sクラスタを運用しており、ほとんどのアプリケーションはその上で動作しています。それぞれのk8sクラスタで動作しているアプリケーションは同一のものです。NyahはAWS Direct ConnectでAWSへ専用線接続されているため、相互の環境は透過的にアクセス可能になっています。例えばステートフルなDBやCache等はAWSのマネージドサービスを利用していますが、プライベートクラウド環境からもアクセス可能になっています。また、AWSだけでサービス持続可能なように設計されています。 プライベートクラウドNyahについてもう少しご説明します。Nyahの最大の長所は安価であるということです。同程度のスペックのEC2 instanceを利用するのと比較して、利用コストが数分の一で済みます。しかし一方で短所もあり、パブリッククラウドに比べるとスケーラビリティに制約があります。ある程度の余剰はありますが、爆発的なリソース需要の急増には対応することが難しいです。 minneでパブリックとプライベートのクラウドでハイブリッドクラウドの構成を選択している理由としてはいくつかあります。1つはプライベートクラウド自体の障害の対策です。社内で運用しているサービスのため、時には障害が発生し利用できなくなる可能性もあります。その際のリスクを考慮しています。minneではプライベートクラウド側だけにしかないリソースは基本存在せず、万が一の時には前述の通りAWS側だけでサービス継続が可能になっています。 2つ目の理由としては、安価なプライベートクラウドのコンピューティングリソースを最大限に活かしつつ、部分的にマネージドサービスを利用することで運用負荷を軽減できるからです。運用負荷の高いDBやCacheなどはRDSやElastiCacheなどのAWSのマネージドサービスを利用して、ステートレスなリソースに関してはプライベートクラウドを活用しています。 3つ目の理由としては、先ほど述べたプライベートクラウドの短所であるスケーリングの制約をカバーするためです。プライベートクラウド内のスケーリングで間に合わない場合は、Route53の加重レコードでAWS環境へ向くトラフィックの割合を調整し、プライベートクラウドで受けるリクエスト数を抑えます。 Section2│運用上の課題 続いてminneにあった運用上の課題について説明します。先ほど述べたプライベートクラウド内のリソースで間に合わない時にAWSへリクエストをオフロードする運用は、実は都度人力で行っていました。具体的には、割引クーポンやテレビ放映などのリクエストが急増するようなイベントがある度に、次のような作業を行っていました。まず、過去の実績の中から似たような事例を探し、ピーク時のリクエスト数を予測します。次に、過去のキャンペーンやテレビ放映時のレスポンスタイムや負荷状況と照らし合わせて、プライベートクラウド内のリソースだけで間に合うかどうかを試算し、リクエストをオフロードするかを判断します。そして、ピーク時にプライベートクラウド環境のキャパシティオーバーとならないよう、AWS側へオフロードする最適な加重を計算して事前に設定しておきます。ピークが過ぎリクエストが落ち着いたら加重設定を通常の割合に戻します。右のグラフはこの操作を行った際のそれぞれのクラウド環境で処理するリクエスト数の変化のイメージです。プライベートクラウドNyahで2,000リクエストまで許容できるとした時、最大3,000リクエストが予測された場合には、Nyah側へのリクエスト数が2,000リクエスト以下に収まるよう、AWS側で4割のリクエストを処理するよう加重を調整しています。ピークが過ぎた後加重設定を戻しています。 この運用の問題点としては、専門性が高く限られたメンバーしか実施が難しいため、運用作業がスケールしないことが挙げられます。また、実際より需要を多く見積もってしまった場合や、翌日や休み明けに加重設定を戻すまでのアイドルタイムの間、無駄にパブリッククラウドのリソースを利用している状態になっており、クラウドのコスト的に最適な状態であるといえません。さらには、誤って需要を少なく見積もってしまった場合、リソースが足りずレスポンスの遅延などが発生し、サービス障害となってしまう可能性があります。 この運用課題を解決するため、理想状態として自動でリクエスト数に応じた最適な加重が設定されることを目指し取り組みました。実は弊社サービスのSUZURIもminne同様ハイブリッドクラウドで動作して同様の課題を抱えており、LambdaやCloudWatch等のAWSのサービスを活用した先行事例がありました。これと同じ仕組みをminneでも構築することが考えられましたが、minneやSUZURI以外のハイブリッドクラウド構成をとる社内の他のサービスで個別にこれらの仕組みを構築運用していくのは非効率になると考え、全社統一での汎用的な仕組みで解決する道を探りました。 Section3│k8s Operatorによる自動リクエストオフロードの実現 そんな時に思いついたのが、k8s Operatorでこの課題を解決する方法でした。k8s Operatorとは、カスタムリソースを用いてk8sを拡張するコンセプトのことです。例えばDeployment Resourceに対するDeployment ControllerがReplicaSetを管理するように、独自に定義したカスタムリソースに対してCustom Controllerとして任意の動作を行います。有名なOperatorの例としてはカスタムリソースでPrometheusを管理するPrometheus Operatorや、AWSの各種リソースをカスタムリソースで管理できる AWS Controllers for Kubernetesなどがあります。またOperatorはk8sのコア・コンセプトのReconciliation Loopの仕組みに準拠して動作しています。 Reconciliation Loopとは、システムの現在の状態を観察比較して、現在の状態が理想の状態に一致するように変更するということを繰り返し行うループ処理のことです。ReplicaSet Controllerを例にとると、Replica数が3に設定されている時、管理するPodが何かしらの理由によって1つ減ったとしても、Replica数=3を維持するために新しく1つPodを追加するといったような具合です。k8sの様々なControllerはこのReconciliation Loopをもとに設計され動作しており、k8sの特徴である宣言的な設定はこの考えのもとに実現されています。 今回、リクエストオフロードの運用課題解決をOperatorで実装した理由の1つは、プライベートクラウドのキャパシティ不足に陥らないようにプライベートクラウドのリクエスト数を一定以下に抑えるために行うリクエスト数の確認、最適な加重の計算、加重設定の更新の操作の自動化を考えた際、まさに定義された理想状態に収束させるReconciliation Loopのパターンにマッチしそうと考えたからです。また、先ほど紹介した先行事例のSUZURIの件では、AWSのサービスをフル活用していましたが、Operatorとして実装できれば動作プラットフォームがk8sとなるため、クラウドベンダーなどの依存を減らすことができ、その他サービス事業部での活用の幅が広がりそうとも考えました。  Operatorの開発にはkubebuilderというフレームワークが提供されており、実装の型がある程度決まっています。kubebuilderによるOperatorの実装はカスタムリソースの設計とReconcile処理実装に大きく分かれています。カスタムリソースの設計について私はまず前述のプライベートクラウドのキャパシティ不足に陥らないように、プライベートクラウドのリクエスト数を一定以下に抑えるリクエスト数の確認、最適な加重の計算、加重設定の更新の操作を細かく分解しReconcile処理に必要な要素の整理をしてカスタムリソースの型を決定しました。例えば、リクエスト数を知るため、Prometheusからメトリクスを取得する必要があるので、 Prometheusの接続先と認証情報とクエリのフィールドが必要といったような具合です。次に、定義したカスタムリソースの状態を維持するようなReconcile処理を実装していきました。この実装に関しては、既存の多種多様なカスタムコントローラーを参考にしました。例えばPrometheusからメトリクスを取得するような処理はプログレッシブデリバリーコントローラーのArgo Rolloutsに似たような実装があるため参考にしました。 そして完成したのが、Rebalancerと名付けたOperatorです。これは、指定したポリシーに基づいて外部のメトリクスを参照してターゲットの加重を自動で調整します。現在はターゲットとしてRoute53、メトリクスとしてPrometheus、ポリシーはメトリクスが指定した値を維持するように最適値を算出するターゲット追従ポリシーのみに対応しています。弊社内の他のサービス事業部での活用を広げられるよう、ターゲットとしてPowerDNSやAWS ALBの加重ターゲットグループ、メトリクスとしてCloudWatch、Mackerel等への対応を考えています。 こちらが、Rebalanceカスタムリソースのサンプルです。プライベートクラウドでのリクエスト数が一定以下になるよう、AWS環境へ向く加重レコードのweight数を調整する場合の設定です。 簡単に説明するとmetricsフィールドに定義したPrometheusに定期的にクエリを発行して、現在のプライベートクラウド側のリクエスト数を取得しています。policyフィールドで選択した戦略がメトリクスとプライベートクラウド側のレコードのweight数をもとに最適な加重設定を計算します。得られた最適な加重設定を、targetに指定したレコードに設定します。例えばプライベートクラウド側の加重設定が10で、リクエスト数を1,000以下に抑えたい設定の場合、2,000リクエストが来ていたら10:10、3,000リクエストが来ていたら10:20といったように最適なweightを調整します。 このOperatorを作成したことで、月に複数回あった人力でのリクエストオフロード運用が0件になりました。基本的には、Operatorによる自動調整に任せておけば適切にオフロードされています。また、オフロード設定が最適化され、必要ない時にはAWS側へのオフロードが自動で無効に再設定されるため、アイドルタイムに無駄に利用していたAWS側のリソースが約20%削減されました。さらに、汎用的な設計でOperatorとして実装したことで、全社統一の仕組みで自動オフロード機能を提供可能になりました。GMOペパボでは便利ツールが動作する社内共通のk8sクラスタがあり、そこでマネージドで提供することで、カスタムリソースを書けばすぐ利用できるようになります。また、セキュリティ的な要件で、外部からのAPIの操作が難しいような場合でも、サービス事業部管理のクラスタにOperatorをインストールすることでも利用できます。 今回、Operatorによる運用課題解決を実施した結果、複数のメリットがあることが分かりました。1つは、当初の目論見通りクラウドベンダー依存が少なく可搬性が高いことです。システムの設計をする際に、この仕組みによって設計の制約が生まれる可能性が低くなると考えます。また、カスタムリソースのバリデーションはkubebuilderを用いることで簡単に実装できたため、コアなロジックの実装に集中できました。バリデーションがあると利用者は安心して利用することができ、運用者目線からすると設定の説明等に関するコミュニケーションコストも減らせるといったメリットを、低コストで享受できました。さらに、自動化の設定はカスタムリソースとなりk8sのmanifestとして管理されるため、その管理やデプロイ方法は既存のk8sの管理と同じ方法をとることができるのもメリットでした。新たなツールを導入した時に考えないといけない設定の管理回りの考慮を減らすことができました。また、kubebuilderを用いることで実装の型がある程度決まるので、チームメンバーがコードの内容をキャッチアップしやすいといったメリットもありました。 Section4│まとめ 最後にまとめです。この発表では、まずminneにおいて繰り返し発生する運用作業の削減とプライベートクラウドのコストメリットを生かすため、自動でAWSにトラフィックをオフロードしたい課題があったことを説明しました。その実現のため、汎用的でベンダー依存が少なそうなk8s Operatorを作成する方法を選びました。これによって、月数回発生していた運用作業を0件にすることと、アイドルタイムに無駄に利用していたAWS側のリソースを20%削減する効果が得られました。また、これを通して分かった、k8s Operatorで運用作業の自動化を実現する様々なメリットがあったことをご紹介しました。今後、運用課題解決の方法の選択肢の1つとして、Operatorを開発する選択肢をぜひ加えてみてください。 発表は以上となります。ありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/U0_hbrJ44wk

2022年11月21日（月）～22日（火）に「CloudNative Days Tokyo 2022」がハイブリッド開催されました。GMOインターネットグループはダイヤモンドスポンサーとして協賛・登壇しました！今回は、スポンサーセッション「Dynamic VM Scheduling in OpenStack」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/25932/ 登壇者（敬称略） GMOペパボ株式会社　技術基盤チーム シニア・プリンシパル山下 和彦（＠pyama86） 「Dynamic VM Scheduling in OpenStack」 はじめに https://speakerdeck.com/pyama86/dynamic-vm-scheduling-in-openstack GMOインターネットグループのスポンサーセッションで、GMOペパボの山下から、「Dynamic VM Scheduling in OpenStack」というテーマでお話しさせていただきます。 最初に軽く自己紹介をいたしますと、私はGMOペパボの技術基盤チームというところで、シニア・プリンシパルとして活動している山下と申します。TwitterやGitHubは「＠pyama86」というアカウントでやっております。個人でずっと面倒を見ているプロダクトがありまして、STNSというものをやっていて、これは何かというと、旧来LDAPとかMySQL、もしくは/etc/passwdなどで管理されていたLinuxのユーザーやグループを、HTTPベースのJSON APIで名前解決できるというプロダクトです。 続いて、我々GMOペパボの紹介を簡単にさせていただきます。GMOペパボは、ホスティングやハンドメイド、あとはECとか、いろいろな事業領域にわたってサービスを提供している会社です。もともと画面左上にあります「LOLIPOP!」というレンタルサーバーサービスから始まった会社で、そこから派生してECやハンドメイド、最近だとCMをご覧になった方もいらっしゃるかもしれませんが、「SUZURI」という好きなアイテムを自分の画像で作れるサービスもやっております。 CNDTは私も何度か参加したことがありますが、久しぶりにオフライン開催で最高だなと思っている次第です。ただ、これは録画で、今日は10月19日水曜日の14:15で、GMOインターネットグループのパートナーの皆さんと一緒に楽しくお喋りしたり、掛け合いしたりしているのは私だけで、なんか恥ずかしい感じで録画をしています。 今日話すことは、最初に我々のインフラ構成をご説明して、そのあとに発生した問題に触れて、それを解決した話と、あと最後にまとめていくのと時間が余れば結婚における大事なこと42選についてもお話ししていこうと思っています。 ペパボのインフラ構成 ペパボのインフラ構成をざっくり紹介します。我々は大きく4つのインフラがありまして、1つはOpenStack、これはオンプレミスのデータセンターで、物理サーバー80台、その上でVMが1,000台ほど動いています。ここは先ほどご紹介した会社のあらゆるサービスが共用して使っている環境になります。続いてBaremetalサーバー、これはホスティング系のサービスを中心に、物理サーバーの上へそのままOSをインストールして使っています。AWSはOpenStackの待機系としてEKSを使っているほか、データストアのRDSとかElasticxxx系とかのサービスを中心に利用しています。GCPは、一番はBigQuaryでデータ解析に使っていますが、あとは一部の事業においてはOpenStackの待機系としてGKEを使っていたりします。OpenStackの上でKubarnetesを最近動かしているのが主にあって、OpenStackについては右の図で説明すると、Baremetalサーバーが並んでいて、その上にOpenStackを構築してあげて、そのOpenStackで作成したVMの上にKubarnetesを構築してその上にContainerを置く、という感じです。Kubarnetesについても自社でエンジンを開発していて、そのエンジンを用いてKubarnetesを構築したりとか、保守運用をしたりとか、そんな感じで運用しています。 CPU Stealに起因した隣人問題 今回の主題となるノイジーネイバー問題についてご紹介していこうと思います。今回発生したノイジーネイバー問題は、CPU Stealに起因したものでした。これがなぜ起きるかというと、最初に紹介した我々のいくつかのサービス、基本的には国内で事業を展開しておりまして、国内で事業を展開しているとだいたいインターネットサービスはピークタイムが似通ってきます。お昼休みの時間とか帰宅したあとの夕食の時間帯といった感じで、ECサービスやハンドメイドサービスのピークタイムがめちゃめちゃかぶってしまう。我々のサービスはOpenStackの上でインフラを共有しているので、ピークタイムが重なるとどうしてもリソースの奪い合いになってしまう状態があります。 今回、テーマにしているCPU Stealについても、グラフを持ってきています。グラフを見ると、12時過ぎから1つ目のピークがあって、15時頃、22時頃にもピークがあります。先ほどから言っているCPU Stealとはなんぞやというと、今回の例でいうと、あるHypervisorの上でVMが2台（VM1、VM2）動いている時に、それぞれのVMが10秒ずつCPUを使いたいとHypervisorに要求を出すとします。この場合、Hypervisorとしては各VMに10秒あげるというスケジューリングをしますが、リソースの状況などで必ずしもVMが10秒使えないというケースが起こります。この場合、VM1が実際には8秒しか使えなかったとすると、差分の2秒がCPU Stealとなります。 CPU Stealが起きると何が発生するかというと、ひとつはサーバー処理能力が低下します。HTTPサーバーであればレイテンシが落ちたり、データベースであってもクエリのレイテンシが落ちるとか、レイテンシが落ちていくとどんどん接続がスタックしていくので、接続数が増加して、場合によってはMax Connectionsに到達してサービスが提供できなくなるということが起こります。あとは、ロードアベレージをはじめとする各種サーバメトリクスが悪化していきます。 このような、リソースの奪い合いによって発生するCPU Stealに関する問題を解決するための手段が、我々が作った「スーパー☆ライブマイグレーション」です。 スーパー☆ライブマイグレーション 最初に、「スーパー☆ライブマイグレーション」の前提となる、ライブマイグレーションについて簡単に説明します。ライブマイグレーションとは、簡単にいうとVMを停止することなくHypervisor間を移動させるという技術です。ここでは、VM1を左から右のHypervisorへ持っていく例を紹介します。 まずライブマイグレーションを実行しようと思うと、共有ディスクがない場合ですが、まず左のHypervisorから右のHypervisorに対してVMのDiskをコピーしてあげます。続いて、Diskのコピーが終わったら、Memoryを転送します。ここでMemoryとDiskの静止点を待ってHypervisorを切り替えていくのですが、静止点を待つのにKVMとかOpenStackとかではパラメーターがあって、どのくらいダウンタイムを許容するかのパラメーターを持っています。こういったパラメーターをチューニングして、許容できるダウンタイムの中で静止点を取って、静止点が取れたら左側のHypervisorから右側のHypervisorにVMが動いて、ネットワークが切り替わって、右のHypervisorでVM1が動き始める、というのがライブマイグレーションです。 では「スーパー☆ライブマイグレーション」は何をするのかというと、ライブマイグレーションをするだけでなく、ある種スケジューリングまでをやってくれるマイグレーションを呼んでいます。 まず、VMのStealの発生を検知したい。Stealが発生してパフォーマンスが低下しているのを検知したらスケジューリングしたいという感じです。スケジューリングについては、Stealの発生していない、より空きがあるHypervisorにスケジューリングしたい。そして、ダウンタイムを発生させたくない。先ほどパラメーターをご紹介しましたが、ライブマイグレーションで静止点を取るにあたり、どのくらいダウンタイムを許容するかというパラメーターを先ほどご紹介しました。ということは、ライブマイグレーションは”ライブ”とはいいつつある程度はダウンタイムを許容するような仕組みです。それをなるべく発生させないようにしたい、あとはこれらが自動ですべていい感じに動いて欲しい。 今回我々はRubyで実装しました。VMのSteal発生検知については、Stealが発生している、かつ、Loadアベレージがしきい値以上という条件で検知するようにしています。これはなぜかというと、Stealが発生していたとしても、処理が詰まっていなければ別に問題ないので、処理が詰まっているかつStealが発生している場合にライブマイグレーションをするようにしています。 続いて、Hypervisorのスケジューリングです。これは、メトリクスのStealがしきい値以下、かつStealがなるべく少ないものを優先して選んで、かつ、同じロールのVMが移転先のHypervisorになるべくいないというのを条件にしています。なぜかというと、同じHypervisorに同じロールのVMがいっぱい乗っていて、Hypervisorが物理障害などで落ちてしまった場合、その上に乗っているVMが全部ダウンすることになるので、なるべく同じロールのVMが、いろんなHypervisorに分散されるようにスケジューリングしています。最後に同じAZのサーバーであるということも条件にしています。AZというのはAvailability Zoneの略で、Hypervisorの群のような感じで、例えば5台のHypervisorを「AZ-1」、別の5台のHypervisorを「AZ-2」といった感じで、そのサーバーグループのような感じでAvailability Zoneを組んでいくことができます。これはが例えば別のデータセンターにAZを置いたりするのが主だった使い方になります。 必ず同じAZにスケジューリングするようにしていますが、なぜかというと、図でVM1をどこかにライブマイグレーションしたいという時に、AZ-2にライブマイグレーションしてしまうと、AZ-2が障害になった時にAZ-2がまるっと落ちてしまうので、両系が落ちてしまうことで冗長がとれないことを防ぐ、なるべく同じAZの中でサーバーを動かすということをやっています。 ダウンタイムを発生させないということについては、オーケストレーターで対応しています。我々はオーケストレーターを大きく2つ使っていて、1つはKubernetes、1つはConsulです。Kubernetesについては、いわゆるkubectl drainでpodを追い出してあげて、スケジュールしないようにする。ConsulはKubernetesを使っていないVMのところでサービスディスカバリに使っていまして、Consulについても似たような機能で、consul maint -enableとか、consul maint -disableでクラスタから切り離すことで対応しています。 Kubernetesになじみのない方にご説明しますが、kubectl drainというのは何をするコマンドかというと、node-1に対してkubectl drainと打つと、node-1で動いているpod、containerを別のnode-2に動かすことができます。かつ、以降はコンテンをスケジュールをしない、podをそれ以上置かないということができます。こうすることで、node-1からpodもしくはcontainerを追い出すことができるので、この状態でライブマイグレーションをすることで、基本的にはサービスのダウンを避けることができます。 続いてconsulについては、いわゆるヘルスチェックなどを利用して、サービスをディスカバリしてグルーピングできる機能があります。この例でいくと、node-1からnode-3まであって、かつそれぞれnginx、Webサーバーを置いている状態です。この状態でnginxmあるいはHTTPのポートがリッスンできるというヘルスチェックを書いてあげると、dig web.service.consul aでAレコードを引くと、3つのAレコードが返ってきます。こういった形で、名前解決やConsul Templateなどを利用して、構成ファイルを替えたいとかという用途でconsulを使うことが多いです。 この時に、node-3に対してconsul maint -enableを打つと、node-3がメンテナンス状態になるので、この状態でDNSの問い合わせを投げると10.0.0.1と10.0.0.2だけが返ってきて、node-3である10.0.0.3は返ってこないという状態になります。こうなると、クラスタからnode-3が切り離されているので、この状態でnode-3を安全に無停止でマイグレーションできるようになります。 処理系まとめ ここまでお話しした内容を簡単にまとめると、まずStealの発生かつロードアベレージの上昇で、ライブマイグレーション開始の判定をします。その上で最適な母艦（Hypervisor）を決定して、その状態でVMをクラスタから切り離し、ライブマイグレーションをかけて、再びクラスタへ組み込む。これを一連の流れとしています。 我々が作ったプログラムはOpenStackの上で動くKubernetesで1つのpodとして動いていて、状態を観測して、期待とずれている場合に、VMを動かして、なるべく元に戻してあげるということをやっています。 本当にあった怖い話 こんな形で実装していますが、簡単に行かなかった話もあります。一例を持ってきました。 サービスの方で運用しているSREのメンバーから「『スーパー☆ライブマイグレーション』が動いているけど、レイテンシが改善しない」という話が私のところに飛び込んできました。実際に調査してみると、ネットワークトラフィックのメトリクスで、13時ぐらいから16時前ぐらいまで、明らかにネットワークトラフィックが高くなっている。何をやっているかというと、先ほどライブマイグレーションの動きを紹介した時にDiskを最初にコピーするというお話をしましたが、VMのDiskの中にはサイズが大きいものもあって、500GBとか1TBとかを普通にライブマイグレーションして転送するとトラフィックが輻輳して破滅してしまう。対策しないとフルに帯域を使ってしまうということで、同僚が対策してくれたのは、ライブマイグレーションに使うVLANを分けておいて、そのVLANに対してrate limitを入れることでトラフィックを使い過ぎないようにするという対応をしました。同僚に感謝です。 まとめ 今日お話ししたことのまとめです。 我々がやったのは、ノイジーネイバー問題を、スケジューラーを書くことで解決しました。 最初はOSSにしようかとも思いましたが、Kubernetes のdescheduleのような感じで抽象度の高い定義はできますが、オーケストレーターの切り離しのところなどが使いやすくない感じになるので、今回はオープンソースにしない形で実装しました。 我々もやってみて分かりましたが、ライブマイグレーションはピークタイムに動くようなこともあるので、いろいろなところで同時多発的に動くとネットワーク帯域を結構食ってしまうことが分かりました。ライブマイグレーションもある程度の頻度で打つ時はrate limitを検討した方がよいと思います。 当日、私は会場にいると思うので、ぜひ食事したり飲みにいったりできるかなと思っています。 お知らせ 最後にお知らせです。 我々GMOインターネットグループのテックイベントを計画しております。GMO Developers Dayということで12/6、12/7に開催します。会場は渋谷フクラスの16階と、あとはオンラインのイベントとなります。 GMOインターネットグループは、我々の会社だけでもいろいろな領域においてサービスを提供していますが、グループだと金融や仮想通貨、あとはペイメントなど非常に広い事業領域をやっています。それぞれの事業領域のスペシャリストを集めてトークイベントをしたいと思っていますので、ぜひご都合の付く方はご参加いただければと思います。 以上で私のセッションは終わりですが、我々はいま非常に採用に力を入れております。鹿児島、東京、福岡でいろいろ採用しております。せひGMOペパボで働いてみたいという方がいらっしゃいましたら、ご応募いただければ幸いです。 採用ページ：https://recruit.pepabo.com/ 本日はご清聴いただきありがとうございました。 アーカイブ映像 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/jaAff02Dl-o

CloudNative Days Tokyo 2022にダイヤモンドスポンサーとして協賛いたします！GMOインターネットグループから5セッション登壇いたします。今年はハイブリッド開催ですので、是非ご参加お待ちしております。 CloudNative Days Tokyo 2022とは "CloudNative Days" は最新の活用事例や先進的なアーキテクチャを学べるのはもちろん、ナレッジの共有やディスカッションの場を通じて登壇者と参加者、参加者同士の繋がりを深め、初心者から熟練者までが共に成長できる機会を提供するテックカンファレンスです。 イベント概要 開 催 日：11月21日（月）22日（火）10:00～18:00会　　場：ハイブリッド開催　　　　　有明セントラルタワーホール&カンファレンス＋オンライン運　　営：CloudNative Days Tokyo 2022 Committee参加費用：無料（事前登録制）公式ＨＰ：https://event.cloudnativedays.jp/cndt2022 事前申し込みはこちら GMOインターネットグループからの登壇 スポンサーセッション（Keynote） 11/21（月）11:35-11:55 @ TrackA Dynamic VM Scheduling in OpenStackKazuhiko YamashitaGMOペパボ株式会社　シニア・プリンシパルエンジニア＠pyama86話し手が所属するGMOペパボにおいては、OpenStackを用いたプライベートクラウドを運用しています。その中で発生したKubernetesのデータプレーンを含むVMのリソース競合の問題について紹介し、それをどのように解決したのかを紹介します。 CfPセッション 11/21（月）17:20-17:40 @ TrackF k8s Operatorで運用負担減&ハイブリッドクラウドのコスト最適化をした話Chiaki Sugawara  GMOペパボ株式会社　SRE @ch11aki GMOペパボが提供する多くのサービスはハイブリッドクラウドで動作しています。プライベートクラウドは安価であるメリットがある一方でスケーリングに制約があり、それを補うためにパブリッククラウドへリクエストをオフロードする運用を行っていました。これまで職人技で調整していたパブリッククラウドへのリクエストのオフロード操作をk8s operatorを開発し自動で行うようにしました。この経験から得られたoperatorで運用自動化を行うメリットについて解説します。 11/21（月）17:40-18:00 @ TrackF 実例から学ぶ Kubernetes Custom Controller のステータス管理Takuya Takahashi  GMO ペパボ株式会社　プリンシパルエンジニア@takutaka1220Kubernetes の強力な機能のひとつに、Custom Resource と Controller による機能の拡張が挙げられます。しかし、その実装は容易ではありません。実装が困難なポイントのひとつに、Controller が処理を実施する際のステータスの適切な管理があります。この講演では、講演者が実装した Controller や有名 OSS の実装をもとに、複数のステータス管理手法の実装とそれぞれの特徴について解説します。まだ Controller を実装したことがない方でも、実装のイメージが掴める内容とする予定です。 11/22（火）13:20-13:40 @ TrackF ペパボのSREが生産性の向上を目指しCloud Nativeなチーム作り実践した話 Ryuichi Watanabe  GMOペパボ株式会社　SRE@ryuichi_1208このセッションではチーム開発を行っている方を対象に、GMOペパボのSREがCNCFが定義しているCloud Nativeから得たノウハウをチーム運用に適用し生産性の向上を目指した話をします。「Cloud Nativeなチームとは」から始まり、「属人化や暗黙知前提の開発、スケールのしにくさ」といった実際に我々のチームで発生した課題を回復性、管理力、および可観測性と言った視点からのアプローチで分析し、具体的にどのように解決していったのかを明日から使えるTipsとしてご紹介します。 11/22（火）13:40-14:00 @ TrackF しきい値監視からの卒業！ Prometheus による機械学習を用いた異常検知アラートの実装Takuya TakahashiGMO ペパボ株式会社　プリンシパルエンジニア @takutaka1220 システムの安定運用において、メトリクスの収集とアラートの設定は欠かせません。今までのプラクティスでは、人間が予め定めた一定の条件において、しきい値を超える、あるいは下回る場合にアラートを発泡するしきい値監視が一般的でした。しかし近年、監視ツールを提供するベンダーでは、機械学習による時系列データ予測モデルを用いた異常検知アラートが提供されています。同様の手法を、OSS である Prometheus のメトリクスを用いて実装します。 事前申し込みはこちら さいごに ハイブリッド開催とのことで、リアルでお会いできますこと楽しみにしております！オンラインの方も配信を通してお会いしましょう！ 皆さまのご参加をお待ちしております。

30回目のGMO Developers NightはGMOインターネットグループ５社から開発者が登壇します！「CloudNative」をテーマにLTと座談会を行います。さまざまな領域の話が聞けるのはGMOインターネットグループならでは！皆様のご参加、お待ちしております！ イベント概要 開催日　：11月26日（金）時間　　：18:00-19:30開催方法：オンライン登壇企業：GMOインターネット　　　　　GMOペパボ　　　　　GMOペイメントゲートウェイ　　　　　GMOあおぞらネット銀行　　　　　GMOグローバルサイン・ホールディングス 参加申し込みはこちら こんな方のご参加大歓迎 CloudNativeに興味のある方CloudNative Days Tokyo 2021に参加された方他社のCloudNative状況・課題/解決策を知りたい方GMOインターネットグループに興味のある方 セッション内容 ライトニングトーク 『構築自動化で一歩上の業務効率化』 GMOインターネット株式会社クラウドサービス開発部コンピュートプロダクトチーム サーバエンジニア長谷川泰斗 『fargateのバッチ処理』 GMOペイメントゲートウェイ株式会社システム本部　関連事業サービス統括本部　関連事業サービス部　後払いGr河合春樹 『GMOカレーCMが美味しく出来るまで』 新作CM：「まじめにベンチャー。まじめにギーク。」～カレーを食べながら語る人編～ を解説します！GMOペパボ株式会社技術部 シニアエンジニアリングリード常松伸哉 『クラウド環境で育った私が「CPU steal」という指標を知った話』 GMOペパボ株式会社技術部プラットフォームグループ インフラエンジニア渡部龍一 coming soon GMOグローバルサイン・ホールディングス株式会社 座談会 CloudNative Days Tokyo2021に登壇したメンバーをはじめ、ホスティング・銀行・決済と多分野のエンジニアが登壇し、「CloudNative」をテーマにトークを展開します！＜登壇者＞ GMOペパボ株式会社技術部 シニアエンジニアリングリード常松伸哉GMOペパボ株式会社技術部技術基盤チーム シニア・プリンシパル山下和彦GMOペパボ株式会社セキュリティ対策チーム プリンシパル伊藤洋也GMOペイメントゲートウェイ株式会社システム本部 ITサービス統括部 サービス運用Gr 課長佐久間洋明GMOあおぞらネット銀行テクノロジー＆プロセシンググループ 副グループ長 兼 CloudCoEリーダー　田中豪一 さいごに 皆様のご参加お待ちしております！ 参加申し込みはこちら

CloudNative Days Tokyo 2021にダイヤモンドスポンサーとして協賛いたします！GMOインターネットグループから４セッション登壇いたしますのでぜひご覧ください。 CloudNative Days Tokyo 2021とは "CloudNative Days" は最新の活用事例や先進的なアーキテクチャを学べるのはもちろん、ナレッジの共有やディスカッションの場を通じて登壇者と参加者、参加者同士の繋がりを深め、初心者から熟練者までが共に成長できるテックカンファレンスです。 イベント概要 開 催 日：11月4日（木）12:00～19:00 / 11月5日（金）12:00～19:00会　　場：オンライン運　　営：CloudNative Days Tokyo Committee参加費用：無料（事前登録制）公式ＨＰ：https://event.cloudnativedays.jp/cndt2021 GMOインターネットグループからの登壇 スポンサーセッション（Keynote） 11/5（金） 13:20-13:40 @ TrackA 「Kubernetes On-premises is Hardway?」Kazuhiko YamashitaGMOペパボ株式会社　シニア・プリンシパルエンジニア 話し手は所属する企業において、Kubernetesクラスタの構築、保守を行うコマンドの開発を行っています。その内容は初期構築だけにとどまらず、アップデートや、セキュリティ面の担保まで多岐にわたります。バージョンアップの頻度が高いKubernetesにおいて、どのように日々の運用を行っているかを紹介します。 CfPセッション 11/4(木) 17:20-18:00 @ TrackB 「インシデントレスポンスを自動化で支援する - Slack Bot で人機一体なセキュリティ対策を実現する」Hiroya Ito  GMOペパボ株式会社 インシデント支援自動化エンジニア「障害対応で同僚とのコミュニケーションがごちゃごちゃして混乱することがる」「緊急対応のフローやマニュアルが、あるがうまく活用されていない」こんな心当たりはありませんか?GMOペパボではクラウドネイティブ化の取り組むをすすめる側、インシデント対応の自動化にも取り組んでいます。障害やセキュリティインシデント対応の初動で sssbot (内製の Slack Bot ) を呼び出し、インシデントの進行から解決、postmortem 実施までを自動でします。緊急時のコミュニケーションを支援する Slack Bot の設計・実装、インシデントレスポンスのベストプラクティス、DevSecOps を回す組織文化について ペパボの事例を紹介します。 11/4(木) 18:20-18:40 @ TrackB 「脅威モデリングで考える Kubernetes セキュリティ」Kohei Morita  GMOペパボ株式会社 セキュリティアーキテクトシステムがクラウドネイティブに移行すると、Attack Surface や攻撃手法も変化します。「どこを守るべきなのか」「どういうセキュリティ設定をすればいいのか」など、セキュリティについて悩まれた方は多いと思います。この問題へのアプローチとして、脅威モデリングを使った潜在的な脅威の特定が有効です。本セッションでは脅威モデリングへの取り組み方の紹介や、Kubernetes クラスタの脅威モデリングを通して、そのセキュリティについて俯瞰し、具体的な攻撃手法と対策について取り上げます。Kubernetes クラスタへの攻撃手法やその対策、新規・既存サービスでの脅威モデリングの取り組み方について知りたい方にご参考になれば幸いです。 11/5(金) 15:20-15:40 @ TrackA 「レガシーなバッチ処理をB/Gデプロイメントなk8sクラスタで実現する」Takeru Fukunaga GMOペパボ株式会社 SREKubernetesのCronJobで、冪等ではないレガシーなバッチ処理を実行していませんか？DNS Routingの切り替えによるB/Gデプロイメントを採用している場合、CronJobがブルー/グリーンのどちらのクラスタでも存在することになるため、冪等ではないバッチ処理が2回実行されることになってしまいます。本セッションでは、冪等ではないCronJobがある場合でもAdmission Webhookを用いてアクティブなクラスタでのみバッチ処理を行うようにすることで、簡単にB/Gデプロイメントを実現する手法についてお話します。 さいごに 新CMもCloudNative Days Tokyo 2021の幕間でお披露目予定ですのでお楽しみに！たくさんのみなさまのご参加お待ちしております。