SRE の記事一覧

SREにおけるポストモーテムとは 近年、システムの複雑化と規模拡大に伴い、システム障害やインシデントの発生リスクが高まっています。こうした問題を未然に防ぎ、システムの信頼性を向上させるために、SRE（Site Reliability Engineering）では、ポストモーテムと呼ばれる取り組みが重要視されています。ポストモーテムとは、システム障害やインシデントが発生した後に、その原因を徹底的に調査し、再発防止策を立案することで、システムの信頼性を向上させるための活動です。失敗を非難するのではなく、失敗から学び、組織全体の学習と成長を促進することを目的としています。 リリース管理でポストモーテムを行う理由 ポストモーテムは、サービスインパクトのあったシステム障害について実施することが一般的です。私たちはこれに加えて、リリース時に発生した問題についてもポストモーテムを行うことにしました。その理由は以下のとおりです。 1. 問題の特定と可視化 リリースに起因したシステム障害が僅かながら発生していたことから、その裏側にはシステム障害に至らない小さなヒヤリハットが潜んでいるのではないかという推測がありました。見過ごされていた問題点や潜在的なリスクを明確化することで、リリースプロセスの各段階で発生する可能性のある問題を事前に特定し、対策を講じることができます。 2. 継続的な改善 ポストモーテムの結果をもとに、継続的にプロセスや手順を見直し、改善策を実施することでリリース品質が向上します。また、リリース失敗を減らすことで、再リリースに伴うリリース担当者の負荷軽減と作業効率化を図ることができます。 3. 組織全体の学習 失敗から得た教訓を共有することで、失敗から学ぶ文化を醸成し、組織全体の学習と成長を促進します。これにより、同じミスの繰り返しを防ぎ、組織全体の知識とスキルを向上させることができます。 どのようにリリース管理のポストモーテムを実施しているか 具体的には、リリース時に発生した問題を「一部未完了」「切り戻し」「障害発生」に分類し、「一部未完了」「切り戻し」についてポストモーテムを実施しています。 一部未完了: 予定していたリリースの一部が未完了。切り戻し: リリースを中断して切り戻した。障害発生: リリースでシステム障害が発生した。障害管理で対策する 参加者の負荷という点でポストモーテムの範囲や規模は悩ましい点ではありますが、サービスインパクトは無い前提のため、障害管理と比較してコンパクトな体制としています。リリースを担当したチーム、SREチーム、有識者で「なぜなぜ分析」を行い、真因分析と再発防止策を検討します。ポストモーテムの結果については運用定例会議で報告を行い、対策妥当性についてチェックを受けます。報告書は社内ポータルに保管していつでも参照できる形にしています。 リリースポストモーテムの一例（架空の事例です） まとめ リリース管理にポストモーテムを導入することで、これまで顕在化していなかった以下のような問題点を可視化することができました。 構築時期が古い一部のサービスにおけるドキュメントや構成管理の不備本番環境と検証環境に差異が生じているケース リソース配分やスケジュール管理に問題のあるリリース計画 問題の解消には中長期的な対策が必要な事が多く、現時点ではリリース問題発生率の減少には至っていません。今後もポストモーテムを継続することで、持続的な改善プロセスを根付かせ、リリース品質の向上を目指していきます。

CI/CDに特化したテックカンファレンス「CI/CD Conference 2023 by CloudNative Days」が、2023年3月20日に開催されました。東京都内のリアル会場とオンラインの双方で参加でき、全部で18のセッションが行われました。GMOインターネットグループではCMスポンサーとして協賛し、自社のインフラCI/CDの実装やその課題と解決に関して情報を提供するセッションをお届けしました。今回はその内容をご紹介します。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームグループ SRE アーカイブ動画：https://event.cloudnativedays.jp/cicd2023/talks/1755 https://speakerdeck.com/ryuichi1208/inhuraci-cdji-sok-de-gai-shan-nodao-nori GMOペパボの古参サービス・カラーミーショップの歴史 GMOインターネットグループのGMOペパボでは複数のサービスを運用しています。例えばカラーミーショップは2005年にサービスを開始しており、GMOペパボの中でも歴史あるサービスのひとつで、このサービスを利用して作成されたECサイトの流通総額は1兆円を超え、トラフィック量の大きなサービスとなっています。 GMOペパボが運用しているサービス一覧 構成は複数のユーザーで1つのリソースを共有するというマルチテナント型。開発体制は、人の流動性が結構激しいものの、アプリケーションエンジニアが数人から30人、SREは6人ぐらいというイメージだと渡部は説明します。 歴史の長いサービスだけあってカラーミーショップではインフラも随時変更されてきました。「オンプレ期」から始まり、OpenStack上のKubernetesでアプリケーションを運用していた時期を経て、現在は「ハイブリッドクラウド期」です。プライベートクラウドとパブリッククラウドに同じ環境を用意して接続し、アプリケーションやサービスを提供するという構成です。 ちなみに、このあたりの情報に関しては、別のイベントでカラーミーショップのエンジニアが解説したスライドがありますので、興味のある方はそちらもご覧ください。 https://speakerdeck.com/ch1aki/onpurek8stoeksnobing-xing-yun-yong-noshi-ji カラーミーショップがたどったインフラの歴史。プライベートクラウド、プライベートクラウド上のKubernetesで稼働していたKubernetes on プライベートクラウド期が現在主流で、ハイブリッドクラウドに移行しているところだといいます。 カラーミーショップのサービス構成 カラーミーショップは3層構造のサービス構成。ロードバランサーはプライベートクラウド、パブリッククラウド上にそれぞれに実装されていて、アプリケーションはVM（仮想マシン）またはKubernetes上に、データベースはAWS上に存在しています。 アプリケーションは80以上のロールで構成されています。基本的にはKubernetesへの移行を進めているそうですが、全てをVMから移行できるわけではなく、現時点ではVMの方がロールの数は多く、しかも一部のロールはコンテナ化しない予定であり、混在環境が継続することになります。 こうしたインフラ周りで使われている技術スタックは以下のようになっています。 プラットフォーム OpenStack、AWS、Kubernetes開発言語Ruby、mruby、GoミドルウェアNginx、MySQL、Redis、memcachedCI/CDGitHub Actions、ArgoCD監視Mackerel、Prometheus、Grafana、ElasticAPM、DataDogIaCPuppet、Ansible、Chef、Terraform ロールのほぼ全てはPuppetで管理されていますが、デプロイパイプラインとしてVMとKubernetesに分かれており、それぞれでCI/CDが異なっています。 VMの場合はOpenStackのレイヤをTerraformで管理。ミドルウェアの管理がPuppetで、ローカルでは各自でVMを用意してPuppetをアプライ。コードが完成したらGitHubにプッシュし、Puppetをアプライしたコンテナに対してServerspecでテストを実施。問題なければインテグレーション、ステージング、プロダクションなど、環境ごとにデプロイして動作確認するというフローになっているとのこと。 Kubernetesの場合は、「kubectlのデプロイは原則禁止で、いわゆるGitOpsのフローを取っている」と渡部。フローとしては、main branchがステージング環境に適用され、release branchがプロダクション環境へ適用されます。 開発ではmanifestの修正をGitHubにプッシュし、Dockerfileのテスト、DockerImageのビルドやプッシュを行い、ArgoCDを用いて実際のクラスターに適用するという流れです。 カラーミーショップが抱える6つの課題 こうしたカラーミーショップの環境には、以下の6つの課題を抱えていると渡部は説明します。 インフラテストへの課題コードとサーバーで差分が発生している問題暗黙知前提の運用問題VMとコンテナ混在問題セキュリティ対応問題使用しているツールが多く、学習に時間がかかる問題 インフラテストへの課題は、端的に「時間がかかりすぎる」というものです。例えばただnginxでパラメーターをひとつ変えるためのプルリクエストを出すだけでも、ローカルのVMにコードを適用するだけで15分、CIでコンテナを起動してコードが適用されるまで20分、合計35分がかかっていました。 デプロイまでのフローには複数の段階があり、些細な修正でも毎回35分程度の時間がかかっていました これだけ時間がかかるのは、CIが毎回プレーンな環境で実行されるという点にありました。プレーンになってしまうので修正以外の部分もやり直しになってしまいますし、「末尾のセミコロンを忘れた」というだけの修正確認でも20分かかってしまうのだそうです。 他にも様々な問題が発生しえます。最終的には「何もしなくても時間の経過とともにシステムは壊れていく」と渡部。 2番目のコードとサーバーの差分については、VMがミュータブルな点、障害対応時のアドホックな対応などが残っている点、ロールが80以上と多数になるため半年近くデプロイされていないものも存在する点などで差分が出てしまうことがあるとのこと。サービス開始当初のコード管理せずに構築されたロールなどもあって、属人化が進んでいるということもあったそうです。 似たような課題が暗黙知前提の運用で、インフラのコードに触れるメンバーがある程度固定化されてしまったため、セットアップする人がおらずに以前のセットアップ手順書が使えなくなってしまったり、メンテナンスがされていなかったり、コード変更作業がSREチームに依頼されるためチーム本来の作業ができないという問題がありました。 3番目のVMとコンテナ混在問題は、積極的なコンテナ化を進めつつもVMが混在する状況で、ミドルウェアの設定変更でVMとコンテナ双方で対応が必要になり、VMに最適化されたnginxなどのミドルウェアの設定も問題が発生することがあります。 セキュリティ対応問題では、パッケージなどの脆弱性をチェックするツールを使っても報告される数が膨大で対応しきれないという点があります。深刻度の高いもの以外は優先度を挙げられないという問題もありました。 学習コストの問題は、使用しているツールの数が多いために発生しています。IaCだけでも複数のツールがあり、運用ツールも多数の言語で実装されていて、現在メインのRubyとGo以外にも複数の言語が存在しています。 そもそも2005年からスタートしているサービスのため、当時の開発者の得意言語で作られたツールがシェルスクリプト、Perl、Pythonなどとバラバラにあり、しかもプロダクションで運用されて使われていることもあるため、メンテナンスのために言語習得が必要になることもありました。 課題をいかに解消するか こうした課題に対しては、まず「課題をどうしたいのか」という定義から始めました。 暗黙知前提の運用のためにインフラに触れるメンバーがスケールせず、「触るのも恐い」という状況で、SREチームがインフラ作業に従事せざるをえないという課題に、「アプリケーションエンジニアも安心して触れる、インフラCI/CDを目指す」ことを目標に改善を目指しました。 解決へのアプローチは以下の通り。 CIの高速化暗黙知の徹底排除テストの拡充開発環境の整備構成ドリフト検出のための仕組みの実装コンテナ on VM監視の見直しデイリーでコンテナイメージをビルドする仕組みの実装権限委譲 インフラテストで1回30分の時間を要していたCIは、GitHub Actionsの設定方法のチューニング、ライブラリやPuppetでのキャッシュや並列化などによって1割程度、2～3分程度は削減。 さらにパイプライン自体の最適化としてキャッシュを有効活用。kernelヘッダーやgccのアップデートなど、変更と関係ない部分をキャッシュしておき、毎日朝に適用済みコンテナイメージをプッシュしておき、当日はそのイメージを利用することで、10～15分の削減に繋がりました。 さらに誰でも簡単に使えるようにすることを目指し、暗黙知前提の運用排除を目指しました。まずはドキュメントの執筆と勉強会、ワークショップの実施もしつつ、CIに関する作業の自動化を進めました。 これはプルリクエストに対して必要なラベル付け、開発環境のセットアップコマンドによる必要なツール類のインストール、テストの拡充など多岐に渡り、テストのたびにGitHubにプッシュする必要がなくなるなど効率化。 コードとサーバーの差分で発生している問題については、定期的に差分検出やコード適用する仕組みを実装。毎朝1回、Terraformのplanをチェックしたり、Puppetの差分確認コマンドも時間を決めて実行し、差分の有無を確認したりしているといいます。 デプロイフローも整理して、GitHub Actionsからしか実行できないように整備しました。変更履歴の管理が容易になって、いつ、誰が変更したかを追跡しやすくなったことがメリットです。 VMとKubernetesの混在問題は、移行期間ということもあって同時に同じアプリケーションが動いていることがあります。これに対してDockerをVMで動かし、1コンテナを1つのVMで動かすことにしました。VMの修正はDockerファイルにコンフィグレーションを含めてビルド。そのイメージをプッシュすることにして、1つの修正でVM、Kubernetes双方に反映される仕組みを実装しました。 セキュリティの課題について、パッケージの脆弱性は最新版で改善されているケースが多いので、Dockerファイルのパッケージバージョンではlatest指定し、ステージングなどで動作確認を毎日行います。latest指定で壊れてしまっても、本番環境には影響が出なくなるわけです。 こうした取り組みによってインフラCI/CDが改善され、エンジニアが触りやすい環境にはなってきました。結果として、SREチームのレビューが必須だったブランチ運用ルールを不要にできたと渡部は説明。 とはいえ、CI/CDの改善による生産性の向上が実現したかは難しい問題だと渡部は指摘します。アプリケーションエンジニアの作業量が増えただけで組織全体では生産性が下がっているのではという懸念もあり、可視化ができていない点が課題なのだとしています。 それでも、SREチーム以外が触りづらかったインフラにおけるCI/CDの改善活動を続けて、状況は良くなってきました。現在も試行錯誤中ですが、GMOペパボにおける「コンテナとVMの混在環境」というのは、一般的に起こりえる状況なので、解決するための知見を今後もアウトプットしていきたいと渡部は話していました。

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セッション「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年9月24日（土）～25日（日）に「PHPカンファレンス2022」が大田区産業プラザにて開催されました。GMOインターネットグループはスペシャルスポンサーとして協賛・登壇しました！今回は、スポンサーセッション「17年続くWebサービスを改善する　～新卒2年目からみるカラーミーショップ～」の書き起こし記事となります。ぜひご覧ください。イベント告知：https://developers.gmo.jp/23482/ 登壇者（敬称略） GMOペパボ株式会社　EC事業部ECグループCCXチーム中山 慶祐（やんまー）GMOペパボ株式会社　技術部プラットフォームグループ新宮 隆太（ほみるん） 前半「切り取り方を工夫してアプリケーションを漸進的に改善する」 https://developers.gmo.jp/24741/ 後半「カラーミーショップの改善におけるSRE活動について」 https://speakerdeck.com/homirun/karamisiyotupunogai-shan-niokerusrehuo-dong-nituite GMOペパボ株式会社技術部プラットフォームグループでサイトリライアビリティエンジニアをやっております、新宮隆太と申します。弊社ではあだ名で呼び合う文化があり、社内では"ほみるん"と呼ばれています。このあだ名は、むかし乱数で生成したものを使っています。 社内では、写真のようなサーバーを担ぐSlackアイコンを使っていることから、他のチームからはとりあえず「サーバーを担ぐやつ」として認知され始めました。最近のトピックは、曲がりなりにもサイトリライアビリティエンジニアをやっているわけですが、自宅サーバーで運用しているブログを落としてしまいました。非常に反省しております。Twitterは @h0mirun_deux のIDでやっておりますのでよければフォローよろしくお願いいたします。 本日のアジェンダです。 まず、一般的なSREについてのお話をさせていただき、その後カラーミーショップのSREチームの紹介をさせていただきます。そして、SREチームが行っているSRE活動と、その改善活動について実例を踏まえつつお話しさせていただければと思います。 SREとは まずSREとは何なのかという話をします。SREとはSite Reliability Engineeringの略です。日本語にするとサイト信頼性エンジニアリングですね。実はですね、このSREという略はもうひとつの意味でも使われています。それはSite Reliability Engineerです。先ほどはエンジニアリング、今回はエンジニア、どっちもSREなので困りましたね…。スライドや口頭とかでもSREというとエンジニアリングかエンジニアどっちを指すのか分からなくなりそうです。でも、リライアビリティという言葉はもうさっきからずっと言っているのですけどめちゃくちゃ言いにくいですよね。なので、できればSREと略して喋りたいわけです。 そういうことで今回はSREという略語に関しては、Site Reliability Engineering、つまり手法を指すということにしたいと思います。エンジニアの方は略さずサイトリライアビリティエンジニアと書いたり言ったりしたいと思います。 ということで、本題に戻りまして、SREの話をしていきたいと思います。 SREとは、サービスの信頼性を維持向上することを目的としたアプローチのひとつで、信頼性に関する指標などをもとにファクトベースで意思決定を行います。 今度はエンジニアの方、サイトリライアビリティエンジニアは、その名の通りサイトリライアビリティエンジニアリングを実践する人たちのことを指しています。この人たちはサービスの信頼性に関するすべてのことに関わります。 さて、SREの簡単な説明が終わったところで、先ほどから信頼性、信頼性と言っていたわけですが、信頼性とは何なんだという話について軽く触れていきたいと思います。 信頼性は、サービスがどれだけユーザーの期待どおりに利用できる状態かどうかを示す言葉です。よく信頼性が高いという言葉を耳にすると思います。これは、ユーザーが期待どおりに利用できる時間が長いということになります。例えば満足な速度でレスポンスが返ってくるだとか、サービスが障害で止まって使えなくなることが少ないだとか、そういうことが組み合わさって信頼性が高くなるわけです。 さて、ではその信頼性を維持向上することで何が嬉しいのか見ていきたいと思います。 一番大きいのは、ユーザー体験の維持・向上だと思います。極端な例ですが、リリースのためにサービスが不安定になったり、レイテンシが悪化するといった状態だったとします。するとユーザーはより快適な別のサービスに乗り換えてしまうなど、ユーザーが離れていってしまい、せっかく素晴らしい機能をリリースしたのにそもそも使ってくれるユーザーがいなくなってしまうわけです。こういった機会損失を防ぐことができるのが信頼性の維持・向上です。 信頼性の維持・向上のためには、まず現状のサービスの状態を知ることと、目標の設定が不可欠です。ということで、次は信頼性の指標となるSLI/SLOについて簡単に説明していこうと思います。 まずSLIから。SLIは、Service Level Indicatorの略で、サービスの稼働状況を示したものです。具体例を出すと、可用性であればリクエストの成功と失敗の割合であるエラーレートであったり、決済の成功率、レスポンスの応答速度であればn秒以内に処理を完了したリクエストの割合とかがSLIとして設定できます。 SLOは、Service Level Objectiveの略で、サービスの稼働目標を数値化したものです。先ほど説明したSLIがどのような状態になっているとよいのかを定義します。先ほどと同じような例を出していくと、可用性では30日間で正常に処理されたリクエストが99.9％だとか、30日間で決済成功率が99.99％、いわゆるフォーナインといわれるものですね、レスポンスの速度では、30日間でn秒以内に処理が完了したリクエストが99.95％というものがSLOとして設定できます。 では、具体的に信頼性の維持向上のためにサイトリライアビリティエンジニアは何をやるのでしょうか。 実際には、以下のようなことをやっております。先ほど話したSLI/SLOの運用であったり、メトリクスをもとにしたパフォーマンスチューニング、運用の手順化・構造化、構造化したものをソフトウェア・エンジニアリングを用いて自動化し効率を図る、など様々なことをやっております。 今回の発表では、上記の2つについて、より焦点を当てて話しさせていただければなと思っています。 カラーミーショップのSREチーム カラーミーショップでSRE活動を行っているチームについて簡単にお話しさせていただきます。 GMOペパボでは、サービスごとに事業部という形で分かれています。カラーミーショップは赤枠で囲んだEC事業部というところで開発されています。ですが、カラーミーショップのSREチームはEC事業部ではなく、サービス横断の横串組織である技術部の中にあるプラットフォームグループというところで主に担当しています。 カラーミーショップのSREチームを担当しているプラットフォームグループは、サービスから独立したSREチームとなっており、以下のようなことを行っております。SLI/SLOの運用、ソフトウェア・エンジニアリングを用いたサービス運用効率化、メトリクスをもとにしたパフォーマンスチューニング、といった先ほどのサイトリライアビリティエンジニアのやることで紹介したことはもちろん、インフラまわりの整備、オンコール対応なども行っています。 カラーミーショップにおけるSRE活動 ではここから、本題である実際にカラーミーショップで行っているSRE活動について説明していきたいと思います。 先ほど説明したSLI/SLOは、設定するだけでは意味をなしません。SLI/SLOを観測することが信頼性維持・向上に向けての第一歩となります。カラーミーショップではSLI/SLOを観測するために、以下のような取り組みを実施しています。 ではひとつずつ説明していきたいと思います。 まず1つ目がSLIの監視と通知です。 カラーミーショップではエンドポイントのレイテンシをSLIの1つとして設定しています。そこで我々はSLIを監視ツールで監視をし、直近の数分のレイテンシが閾値を超えていたことを通知できるようにしました。これにより、いま自分たちのサービスの信頼性が低下しているかもしれないということに即刻気が付くことができるようになります。 次にダッシュボードについてです。 ダッシュボードはグラフ化されることで視覚的に分かりやすくなり、SLIの傾向をつかむのに最適です。全体的に少しずつSLIが悪化もしくは改善している傾向が分かったり、特定のタイミング、特定の時刻にSLIが悪化していることが分かったりします。この下に貼ってある画像の緑と赤の境界線が設定されている閾値で、ここを超えないように日々SRE活動を実施しています。 SLI/SLOレビュー会では、カラーミーショップ担当エンジニアとSREチームが参加し、現在のサービスの状態の認識共有を行う場として設定されています。具体的にこの会では、次のようなことをします。まず直近1週間のSLIを確認し、SREチームとカラーミーショップ担当エンジニアとの間で、現状のサービスの信頼性の状態を確認します。その後、SREチームが事前にこのままではSLIを違反してしまいそうな項目について調査をしておき、この場で共有します。最後に、次のSLI/SLOレビュー会までに実施する改善策、いわゆるアクションアイテムを設定します。この会を毎週毎週繰り返すことで、サービスの信頼性をより向上させていっています。 次に、エラーバジェットについてお話しします。 エラーバジェットは、サービスの信頼性がどの程度損なわれていても許容されるかを示す値です。例えば、SLOで30日間に来るリクエストのうち、99.99％は正しいリクエストを返すというものを設定した場合、30日間で約4.3分間はエラーを返してもよいということになります。 さて、エラーバジェットがだいたいどんなものか分かったところで、これをどう信頼性の維持・向上の活動に含めていくかです。カラーミーショップでは、エラーバジェットをすべて使い切った時に、カラーミーショップ担当エンジニアと、サイトリライアビリティエンジニアがとる行動についてルールを定めています。それが、エラーバジェットポリシーです。カラーミーショップでは、ちょうど運用を始める段階です。エラーバジェットポリシーは、サービスの機能開発と信頼性のバランスをとるという目的で設定されています。また、ここにはエラーバジェットポリシーはSLOの未達に対する罰としては運用しないということも明記されています。これは、このポリシーが信頼性回復を目的としてカラーミーショップ担当エンジニアとサイトリライアビリティエンジニアが協力するために設定されているのであって、対立するためには設定されていないことを重要視しているからです。 もう少し具体的にカラーミーショップのエラーバジェットポリシーについて見ていきます。 もし、エラーバジェットを使い切ってしまったら、まず信頼性回復のためのタスクが最優先になります。そのうえで、もしアプリケーションが起因でエラーバジェットを使い切ってしまった場合は、SREチームとカラーミーショップ担当エンジニアそれぞれ1人ずつ、信頼性回復のためのタスクに専任でアサインします。もしインフラ起因でエラーバジェットを使い切ってしまった場合は、SREチームから1人を専任でアサインします。 次に改善もくもく会についてお話しします。 改善もくもく会は、カラーミーショップ担当エンジニアとSREチーム合同で一緒にサービス改善を実施する会です。 もう少し具体的に話すと、この会では主に3つのことを行っています。まず、SREチームが改善できそうなエンドポイントの洗い出しを実施してカラーミーショップ担当エンジニアに共有します。カラーミーショップ担当エンジニアはSREチームが洗い出したエンドポイントに関する実装についてSREチームに説明をします。ここまでで出た情報をもとに、実際に手を動かしてサービス改善を実施していきます。 ここまでSLI/SLOの観測や改善もくもく会などのお話をしてきました。それらから生まれた改善活動として、実際に次のようなことを実施しています。 インフラの最適化としては、需要の予測とキャパシティプランニングや、Webサーバーの設定値の変更などのチューニング等、アプリケーションの改修としては、クエリチューニング等を実施しています。 SLI/SLOを用いた改善活動の事例紹介 それでは、先ほどの話を踏まえて実際に行った改善活動の事例を紹介します。 具体的な例の前に、アーキテクチャの話を少しだけ前提知識としてさせてください。 カラーミーショップの一部はGMOペパボのプライベートクラウド基盤であるNyah上でVMとして稼働しています。もちろんコンテナ化されている部分もあります。また先ほど言ったNyahにはGMOペパボが提供している別のサービスも含めて共存しています。これらを頭の片隅に置いた状態でこれから話す事例を聞いていただければと思います。 はじめに、インフラ最適化による改善活動を2例紹介します。 インフラの最適化による改善活動の例　～その１～ 1つ目は、エンドポイントレイテンシが悪化して閾値を超えてしまった例についてお話しします。 我々SREチームは、以下のような手順でこの問題を改善しました。 まず1つ目、まず我々はSLIダッシュボードから何か問題がありそうだぞとなったあと、もともと収集しているメトリクスを確認し、一部のインスタンスのみのレスポンスが悪化していることが分かりました。さらに、別のメトリクスを見ていくと、CPUstealの値が増加していることが判明しました。ここで出てきたCPUstealとは、ハイパーバイザー型VMにおいて仮想CPUが実CPUを待っている時間のことで、同じホストにいる別VMと実CPUのCPU 時間を奪い合うことで発生します。カラーミーショップは先ほど説明した通りVM上で動いているため、このような問題が発生していました。 さて、CPUstealの値が増えていることから我々はノイジーネイバー問題を疑い、インスタンスのライブマイグレーションを実施しました。ノイジーネイバーとは、日本語だと「うるさい隣人」という意味です。同じホストに存在する他のVMがホストのマシンリソースを大量に利用することで十分なリソースが利用できない状態のことです。なので、うるさい隣人のいないホストへ移動すべく、ライブマイグレーションという、仮想マシンを別のホストに移動するという対応をとりました。さらに、再度同じような問題が起こった時に、毎回手動で同じような対応をするのは大変なので、それらを自動化する仕組みを用意しました。こちらに関しては、テックブログに詳しく書いておりますのでぜひ見てみてください。 Pepabo Tech Portal「クラウドのノイジーネイバー問題を解決する動的スケジューラー」https://tech.pepabo.com/2022/04/18/instance-migrator/ インフラの最適化による改善活動の例　～その２～ 2つ目はアプリケーションのデプロイを行うためにエラーレートが上がっていた例を紹介します。 この例では、以下のような手順でこの問題を改善しました。まずAPMやログを調査したところ、デプロイ時のフローとして実施されているPHP-FPMのリスタートのタイミングで502エラーが頻発していることが判明しました。その後、開発環境で確認したところ、PHP-FPMはデフォルトでGraceful Restartをするのを期待していましたが、実はそうではないことが判明しました。 ここで、期待していた動作であるGraceful Restartについて軽く説明します。Graceful Restartとは、プロセスを再起動する際に古い子プロセスへ新しいリクエストを受け付けない状態にして、すでに受け付けているリクエストを処理し、新しい子プロセスと入れ替わる動作のことをいいます。もしGracefulでないRestartをすると、すでに受け付けているリクエストの処理は終わらせずに、そのままバツンと切ってしまって新しい子プロセスと入れ替わります。そうすると今回のようにプロセス再起動のタイミングでエラーが出るようになってしまいます。我々はGraceful Restartを実現するために、PHP-FPMの設定のprocess _control_timeoutの値を、デフォルト値である0から直近のレスポンスタイムの95%タイルをもとに設定しました。このprocess_control_timeoutという値は、子プロセスがマスターからのシグナルを待つ最大時間を設定する値で、これを変更することによりGraceful Restartのようなことを実現することができました。これによって、デプロイのタイミングでエラーレートが上昇することがなくなりました。 先ほどまでの例は、インフラの最適化による改善活動のお話でしたが、次はアプリケーション開発による改善の例を紹介しようと思います。 アプリケーション改修による改善活動の例 この例ではSLO違反の調査から特定エンドポイントの処理が意図したよりも長かったことが判明した例を紹介します。 まずメトリクスより複数のインスタンスにおいてレイテンシが悪化していることが分かりました。複数のインスタンスで出ていることから、先ほどの例で出てきたノイジーネイバーが原因である線は薄くなりました。APMから特定エンドポイントの処理の中で投げられているクエリを確認したところ、N+1クエリが存在していることが分かりました。こちらはアプリケーション側の修正であることから、変更した部分の影響範囲の確認も含めて、カラーミーショップ担当エンジニアにレビューをもらったうえでクエリを修正しました。 これらの行動により、該当エンドポイントのレイテンシが改善されたことが確認されました。 おわりに まとめに入ると思いきや、タイトルにも「新卒2年目から見る」という言葉が付いているので、SREチームに配属されて丸1年経った今と配属当初で自分の中で変わったことを少しだけ喋らせていただこうかなと思います。 まず1つ目が、SLI/SLOをベースとして物事を考えられるようになりました。 自分はそもそも配属時はSREのことをよく理解していなかったので、最初はできなかった行動でした。今はSREの先にお客様がいるということを考えながら行動することで、すべての行動やタスクの優先順位付けに良い影響を及ぼしているのではないかというふうに考えています。 2つ目に、何事も手順化するようになりました。タスクをこなしていくうちによく分からないことが出てくると、とりあえずチャットツールの検索を使って過去に同じようなはまり方をしている人を探したり、GitHubで似たようなことを調べたりします。ただ何度も同じような検索、調べたりする行動をすると時間がもったいないので、二度とイチから調べなくてもよいように、ドキュメント化するようになりました。 自分で言うのもなんですが、1年前に比べるとできることが広がったなと感じています。 というわけで、自分の感想はここまでにしたいと思います。 最後に、今回お話ししたことは以下の通りです。 一般的なSREに関する話として、SREとはサービスの信頼性を維持・向上することを目的としたアプローチのことを指す、というお話をしました。 次に、カラーミーショップのSRE活動について、SLI/SLOの観測を監視ダッシュボード、レビュー会などの手段を用いて実施しているということ、またエラーバジェット運用を開始したことなどをお話ししました。 最後にカラーミーショップにおけるSLI/SLOを用いた改善活動についてインフラからのアプローチとアプリケーションからのアプローチ、合計3例をお話しさせていただきました。 以上で発表を終わらせていただきます。ご清聴ありがとうございました。 アーカイブ映像 https://www.youtube.com/embed/lz4IVcds9Fo PHP Conference Japan 2022: 17年続くWebサービ… / やんまー、ほみるん | GMOペパボ – YouTube

今回のイベントでは「Pepabo Tech Talk -入社1年以内のメンバーが語る、ペパボのSREチームの取り組み-」と題して、昨年入社したメンバー3名が登壇します。新卒・バックエンドエンジニア・インフラエンジニアだったメンバーが「なんでSREになったの？」「ペパボのSREチームってどんなことしているの？」「ペパボ入社後SREとして担当した仕事は？」「ペパボのSRE事例とノウハウを知りたい！」といった声に応えるお話をさせていただきます。現在SREとして働く方からこれからSREを目指す方まで、SREに関心のある方におすすめです。 ご参加お待ちしております！ イベント概要 開催日時：2022年4月26日（火）開催時間：19:00～20:00開催場所：オンライン（Zoom） こんな方にオススメ SREとして働く方SREに興味のある方大規模な自社サービスのエンジニアリングに興味のある方GMOペパボ、GMOインターネットグループに興味のある方 タイムテーブル 19:00オープニング19:10バックエンド志望だった新卒がSREになるまで(仮)@h0mirun_deux19:25SREとして働く@r_nakamine19:40ペパボのSREチームへジョインした私が取り組んできたこと@ryuichi_120819:55エンディング ※発表順については変動の可能性があります。 お申込みはこちら イベント詳細や、お申込みは以下URLよりよろしくお願いいたします。https://pepabo.connpass.com/event/245317/ 登壇者 新宮 隆太 E技術部 プラットフォームグループ 21卒 SRE。大学時代はバックエンド志望だったのですが、可用性に関する研究を境にインフラやクラウドに興味を強く持ち始めました。ちなみにあだ名は昔乱数で作りました。 Twitter:@h0mirun_deux 仲嶺 良 Web制作、飲食業等さまざまな業種を経てエンジニアに転職。 Sierや飲食店向けのスタートアップで働いた後、2021年7月ペパボに入社。 現在は技術部プラットフォームグループに所属し、主にSREとしてminneの運用に携わっている。 Twitter:@r_nakamine 渡部 龍一 技術部プラットフォームグループ。2020年入社。インフラレイヤをメインとした技術的問題の解決に取り組んでいます。マイブームはちいかわとvimrc弄りです。 Twitter:@ryuichi_1208 お申込みはこちら イベント詳細や、お申込みは以下URLよりよろしくお願いいたします。https://pepabo.connpass.com/event/245317/ みなさまのご参加お待ちしております！

GMOペパボでは「Pepabo Tech Conference」と題し、開発者に向けたイベントを定期開催しています。今回の「Pepabo Tech Conference #14」では、ペパボのプラットフォームテクノロジーをテーマに、技術基盤チーム・データ基盤チーム・プラットフォームグループ（SRE）・セキュリティ対策室のメンバーが登壇し、各チームの取り組みについてお話させていただきます。 Pepabo Tech Conferenceとは？ GMOペパボでは、「アウトプットすること」を大切にする企業文化があり、自社で培ってきた技術や知見を幅広く公開し、社内だけでなく社会全体に貢献する姿勢を大切にします。その一環として「Pepabo Tech Conference」と題し、様々なテーマで開発者に向けたイベントを定期開催しています。 イベント概要 日　　時 ：2021年2月25日（木）時　　間 ：19:00～21:00場　　所 ：オンライン タイムテーブル 19:00オープニング19:05ペパボサービスインフラのこれから常松伸哉19:25ペパボにおけるコンテナとハイブリッドクラウド活用による可用性向上への取り組み高橋拓也19:45SREが取り組むカラーミーショップへのK8導入菅原千晶20:05データ基盤チームの設立と直近の取り組み堤利史20:253Coで支えるペパボのセキュリティ対策～Communication Completely Continuous～熊野・伊藤・森田20:55クロージング※発表順については変動の可能性があります。 イベント詳細・お申込みはこちら https://pepabo.connpass.com/event/204392/ 登壇者 〇常松伸哉2009年入社、技術部シニアエンジニアリングリード。サービスのインフラエンジニアを経た後、プライベートクラウドの構築・運用に携わるほか、全社的な課題解決にインフラ面から取り組んでいる。2020年より現任。エンジニア組織の運営と並行して、SREやクラウドネイティブといったトピックを推進している。カレーが大好きだけど最近全然食べに外出できていなくてツラい。 〇高橋拓也技術部技術基盤チームに所属するインフラエンジニア。2019年10月にGMOペパボ入社。2020年10月よりプリンシパルエンジニアに就任。ペパボが運営するサービスにおけるクラウドの有効活用によるシステムの安定稼働に注力する。 〇菅原千晶2018年3月にペパボカレッジ6期生として入社。SREとしてカラーミーショップの運用に携わっている。 〇堤利史2020年12月にGMOペパボ株式会社へ入社。技術部 データ基盤チームに所属するデータエンジニア。 〇熊野多聞2007年 に入社、マネージャー。複数商材のインフラエンジニア、インフラ基盤を支えるプロットフォームのマネジメントをヘテセキュリティ対策の推進、マネジメントに従事している。 〇伊藤洋也2007年 に入社、プリンシパルエンジニア。ホスティングのWebサービス〜事業部を横断した技術基盤チームの経験を活かしてセキュリティ対策の仕組み作りプロダクトの開発に従事している。 〇森田浩平2018 年 に新卒入社、シニアエンジニア。セキュリティ対策室で事業部を横断したセキュリティ対策等の基盤づくりに従事している。 お申込みをおまちしております！