みなさんこんにちは。SREチームの内田（@uchan_nos）です。
今年もサイボウズではエンジニア向けのサマーインターンを行いました。 今年から「SREコース」が新設されたので、その実施報告を行います。
インターンの概要
インターンの全体的な雰囲気は 報告その1～品質保証・セキュリティコース にあります。全体では3回に分けて実施されましたが、SREコースはもろもろの事情により第1回目（8月21日～8月25日）と第3回目（9月25日～9月29日）で実施しました。
SREコースでは、いくつかこちらでネタ案を提示し、学生さんに選んでもらうようにしました。 3人の学生さんに、この3ネタをやっていただきました。
- 初動調査システムに機能を追加する
- cybozu-go/kkokを使って、人間にやさしい通知システムを作る
- 各種メトリクスを利用してボリュームの枯渇時期を予測する
次に参加される方の参考になるかもしれないので、3つのネタを簡単に紹介します。
初動調査システムに機能を追加する
初動調査システムは、SREチームが自社DC向けに開発しているシステムです。 障害1が発生すると、障害発生個所に関連した機材の状態を自動的に観測し、人間に通知してくれます。
このシステムに、サーバ機のハードウェア状態を検査するコマンドを実行させる機能を追加するというネタをやってもらいました。 ついでに、少し前から発生していた「VMへのSSHがなぜか失敗する」というバグの修正もやってもらいました。
異常が無くても通知する
もともとのネタの内容は、初動調査システムがハードウェア状態の調査コマンドを実行し、その結果を通知内容に含める、というものでした。
ネタの設計をするために初動調査システムのソースコードを読んでもらうと、あることに気付きました。 それは 初動調査システムはハードウェア状態の調査コマンドを実行しているが、普段はエラーが無いので何も出力がない という事実です。
ということで、内容を急きょ「エラーが無いときでも検査した事実を載せる」と方針転換し、実装してもらうことに。 ここから得られる教訓は 異常が無くても、異常が無いことを明示的に出力すべし ということでしょう。 システムが自動でやってくれていることを、人間が再実行する無駄をなくすために大切なことですね。
kkokを使って、人間にやさしい通知システムを作る
cybozu-go/kkok2とは、SREチームが作っているOSSの1つで、メッセージをイイ感じに配送するサービスです。 障害発生時などに警告メッセージを送る需要があるのですが、そのメッセージングを制御したいという需要から生まれました。 例えば、今からメンテナンスするので警告が発生することが分かりきっている、というような場合に、手軽に警告メッセージを抑制したいです。
メッセージが3日連続したら通知する
cronで定期的に何らかの検査をして、エラーが見つかったら通知する、ということはよくあります。 本当はエラーを自動解決できるのが理想的ですが、そうなっていない場合も多々あります。
エラーがクリティカルなものであれば、エラーが発見されたときに通知を飛ばせば良いでしょう。 しかし、1回だけエラーになってもクリティカルではないが、エラーが一定以上続いたら気づきたい、というケースもままあります。
そういうケースで人間が通知を受け取ったときに「ええと、昨日も来てたっけ？」と、過去の通知を探すのは割とつらい作業です。 kkokを使って、N日間連続で同じ警告が来た時に人間に通知を飛ばす、というフィルタを試作していただきました。
ボリュームの枯渇時期を予測する
サイボウズクラウドには、毎日お客様のデータが溜まっていきます。 当然、ボリューム3の空き容量はどんどん減っていくので、ある閾値以下になったらボリュームを自動的に拡張するシステムが動いています。
ボリューム拡張をお客様のアクセスが多い時間帯に行うと性能が劣化する場合があるので、 自動拡張システムはアクセスが多くなる日中帯は避けて拡張を行います。 また、負荷が高い作業が行われているときは拡張しないなどの配慮がなされています。
自動拡張システムを監視する
まれに、それらの配慮が何日も発生してしまい、ボリューム拡張がされないことがあるかもしれません。 また、実は自動拡張システムにバグがあって全然拡張されない、という事態が発生する可能性もあります。 自動拡張が間に合わないペースでボリュームが消費されることもあり得ます。
ということで、ボリュームの空き容量の時系列データを利用し、向こう1カ月以内にボリュームが枯渇するかどうかを予測するプログラムを作成していただきました。 Jupyter Notebookで試作品を作ってもらい、良い感じに予測するプログラムが出来上がりました。
インターンの感想
どのネタもコーディングを含むもので、一部は我々のコードベースを読む必要があるものでした。 それを実質3日間でやり遂げる必要がありましたが、3人の学生さんはちゃんと成果を残していただけました。素晴らしい！ しかも、一部の成果物は実際に本番環境に取り込まれ、現在も元気に動いております。
たくさんの学生さんと触れ合うことができ、メンターとしても非常に楽しいインターンでした。 3日間で何らかの成果を出してもらうためのマネジメント方法を探求したりだとか、いろいろ学ばせていただきました。
3人の写真を見てみるとペンギンが高確率で出てきますね。 エンジニアはペンギンと触れ合いたくなるものだということでしょうか？
