GMOペパボのインフラ担当が感じた“Kubernetes”化の不安　“GitOps”でアプリケーション稼働は快適になる

SREを取り入れて事業成果の最大化に貢献する

菅原千晶氏：「SREが取り組むカラーミーショップへのk8s（Kubernetes）導入」というタイトルで発表します。

まず自己紹介です。菅原千晶といいます。社内では「アキちゃん」というあだ名で呼ばれています。現在は技術部プラットフォームグループに所属しています。新卒で入社したシステム運用系の会社を経て、2018年3月からペパボカレッジ（未経験者向けの研修付きの採用）の6期生として中途入社しました。

業務内容は、現在は「カラーミーショップ」のインフラ運用を主に担当しています。運用の効率化や可用性の改善を行っています。プライベートの趣味は、自作キーボードやネコの撮影です。

今日発表する内容はこのような感じになっています。GMOペパボ株式会社におけるSREの取り組みの実例を紹介したあとに、特に力を入れているカラーミーショップへのKubernetes導入と、最後に今後やっていくことを紹介します。

まず、GMOペパボにおけるSREの取り組みについて紹介します。そもそも技術部が、なぜSREに取り組むかというと、技術部は「全社統合的なアプローチで、技術による効率化と事業成果の最大化を図る」をミッションとしています。

具体的には、セキュリティ対策やプロダクトが動く基盤などのサービス共通の問題を解決するソリューションを各事業部に提供しています。この実現のために、IT運用に対するソフトウェアエンジニアリングアプローチであるSite Reliability Engineering（SRE）を取り入れて、事業成果の最大化に貢献しています。

SLO設定とポストモーテムが可用性向上の取り組みにつながる

これまでやってきたSRE活動の実例について紹介します。

まずカラーミーショップへのSLO（Service Level Objective）設定です。開発スピードと可用性のバランスを取りながらサービスを改善していくためには、SLOの計測と設定が必要不可欠です。カラーミーショップでは、ショップの売上に対する影響が大きいところから計測を開始しています。例えば、決済関連やショップの管理画面、ショップページそのものから始めています。

計測した数値は、週次で振り返る会を実施していて、アプリケーション開発者を交えて毎週、可用性に影響する可能性のあるリリースや、SLIのトレンドの変化や、直近で発生したインシデントやオンコールなどの確認を行っています。この活動の結果、SLOを維持するために、需要増の傾向に対する事前のスケールアウトなどの対策ができました。

続いてポストモーテムです。ポストモーテムとは、失敗から学ぶための振り返りで、SREのプラクティスとして有名かと思います。2018年からポストモーテムを作成するという活動を開始していて、これまでに全サービス合計で200件以上のポストモーテムが作成されました。

これは障害対応チャンネルの作成や、関係者の招集や、障害ステータスの共有などを自動で行ってくれるSlack Botを活用しているのですが、その中にポストモーテム作成の支援があるのが大きいと考えています。ポストモーテムが作成された結果、システムアーキテクチャの変更などによる可用性向上の取り組みが複数回行われました。

ソフトウェアエンジニアリングでスピーディな異常検知と障害影響範囲の特定を実現

続いて、ソフトウェアエンジニアリングによる問題解決でモニタリングの改善について紹介します。

あるとき、外部のメールリレーサービスで送信障害が発生しましたが、障害発生後、しばらく気づくことができませんでした。原因は監視の設定が不十分だったからです。管理画面からはメトリクスの変化が追跡しづらく、異常の判断が困難であったこと、また、そもそも監視サービスに対応していなかったことなどが原因としてありました。

これらを解決するために、定期的に外部のメールリレーサービスのAPIにリクエストを投げて、Mackerelのメトリクスとして扱えるプラグインを開発しました。その結果、メトリクスの傾向の変化から、従来よりも早い異常の検知が可能になりました。

続いて、監視設定のトレーサービリティと属人化の排除の実例について紹介します。これまでは、基本的にSREが依頼をもとにMackerelなどのアラートの設定変更を行っていました。しかし、そもそもの設定依頼の漏れだったり、手作業で行っていたために発生するミスだったり、メンテナンスの際に一時的に変更したものがそのままになっていたりということが重なって、障害発生時に障害影響範囲の特定が遅れることがありました。

これらの改善のため、監視設定のコード化、デプロイの自動化を試みました。具体的には、Mackerelの設定をTerraform化して、PRマージでTerraformが自動適用される、「tfnotify」というツールによって、PR上でplan結果の確認をしたり、適用後にSlackで通知したりが自動でできました。

これらの結果、開発者自身が監視設定を変更できる監視設定変更のセルフサービス化が実現されました。また、Gitで管理されるので変更履歴の追跡が可能になりました。

インフラの課題解決を模索した結果たどり着いたコンテナプラットフォームへの移行

続いて、アプリケーションのコンテナ化。コンテナプラットフォームへの移行も、技術部が力を入れている施策の1つです。カラーミーショップへのKubernetes導入についてお話しします。

カラーミーショップでは、OS・ミドルウェアのバージョンアップにかかる時間的なコストが多い、検証環境の構築やそこでの検証手順が手間、という課題があります。

また、スケーリングに数十分程度の時間がかかり、急なアクセス増に対応しきれないという問題もありました。これに対応するために、あらかじめ余裕を持ったリソースを用意していることで、コスト増という問題もありました。

さらに、サービスの設計や設定がNyahにロックインしているため、マルチクラウド化による可用性向上を行う際に、支障になることがあります。

これらの課題の解決を模索した結果、コンテナプラットフォームへの移行によって改善できそうという結論に至りました。

OS・ミドルウェアのバージョンアップをして、コンテナプラットフォームに移行すると、検証環境の用意が楽になって、検証作業が効率化することが考えられます。また、従来のアップデート作業はイメージの入れ替えになるので、作業が減り、万が一のロールバックも簡単です。

スケールアウトの時間の問題は、プロビジョニング作業を伴うインスタンス作成の代わりに、数秒で起動するコンテナを増やす作業になるので、数分で対応が可能になります。

また、ロックインからの解放ですが、クラウド環境ごとの差異がコンテナプラットフォームレイヤーによって抽象化されるため、共通の設定でのデプロイが可能となります。これによってサービスのポータビリティが向上し、マルチクラウド化を効率的に進められると考えています。

2020年も加速するKubernetes移行で予想できる懸念点と解決法

ここで、GMOペパボのKubernetesを取り巻く環境について紹介します。コンテナプラットフォームとして、カラーミーショップではデファクトスタンダードなKubernetesを選択しています。GMOペパボではOpenStackベースのプライベートクラウド「Nyah」を運営していて、その上でKubernetesクラスタを構築することに特化した内製のクラスタ管理ツール「NKE」を開発しています。カラーミーショップでもこのNKEを使って、クラスタの構築と管理をしています。

2019年にNKEでクラスタを構築後、既存アプリケーションのコンテナ化と本番リリースが行われました。その後、新規開発のアプリケーションもKubernetesの上で稼働しました。この調子でいくと、2020年はKubernetes移行がさらに加速すると予想されました。

しかし、この調子ですべてのアプリケーションがKubernetesに移行したとき、どうなるでしょうか？

次の懸念点が考えられました。導入当初はマニフェストの適用はすべて手動オペレーションで行っていました。この結果、オペレーションミスの増加、クラスタやネームスペースの選択ミスによる障害が発生することによる可用性の低下、いつ誰が変更を加えたのかが追跡できないために障害発生時に原因となるリリースの特定の遅延、復旧時間が伸びる問題、デプロイ作業が慣れている人に集中するためにリリース頻度が低下などの問題……などが考えられました。

そこで、Kubernetesへの移行を効率的に進めるために、まずはデプロイの改善が必要と思い、これら懸念点のアプローチを考えた結果、「GitOps」という手法を用いることで、解決できそうなことがわかりました。

Kubernetes運用のベストプラクティス「GitOps」を採用

GitOpsとは、Weaveworks社が提唱したKubernetes運用のベストプラクティスです。Git管理のmanifestを信頼できる唯一の情報源として扱い、それらをクラスタへ継続的にデプロイします。効果として、Kubernetesのリソースに対する変更がコミット履歴として追跡可能になり、構成ドリフトも自動で修正されます。

カラーミーショップでこのGitOpsを実現するにあたり、次のポイントを考えて設計を行いました。ヒューマンエラーの介入防止のために、イメージタグの更新やstagingの内容をproductionにも反映する作業の自動化です。

変更の追跡のために、イメージの更新時に現時点でのアプリケーションバージョンの差分を比較するリンクを追加しました。リリース完了時にはSlackで通知するようにもしました。

また、デプロイ属人化排除は、リポジトリの構成などを極力シンプルに設計しました。CDツールにはわかりやすいWebインターフェイスを持つArgo CDを採用しました。

この結果、実現されたカラーミーショップのKubernetesのCDパイプラインはこのようになりました。

まず、一番左端の各アプリケーションリポジトリでのマスターマージ、リリースをトリガーにして、CIでDockerイメージがビルドされます。それと同時に、作成された新しいイメージタグを使うようにイメージタグの更新PRを作成します。

stagingクラスタとproductionクラスタのそれぞれにArgo CDが動作しています。マスターブランチの状態がstagingクラスタへ、リリースブランチの状態がproductionクラスタへ継続的にデプロイされるようになっています。

sample-appのマスターマージによって作成されるイメージ更新PRは、最初にマスターブランチに対して変更のPRができます。このPRをマージすると、stagingの状態が更新されて新しいイメージが使われるようになります。

その後、動作確認を行って問題なければ、ユーザーが自動で作成されるmasterブランチとreleaseブランチの差分を埋めるPRをマージします。最終的にリポジトリの状態にKubernetesクラスタの状態が合わさると、Slackへ通知が行われます。

この仕組みを構築した結果、Kubernetesで順調に稼働するアプリケーションが増加しました。デプロイミスなど、リリース起因の障害は発生していません。Kubernetesに慣れていない開発者でもデプロイができるようになりました。構成ドリフトを検出して自動で修正できるようになったのです。

最後に、今後やっていくことを紹介します。

実は2019年にクラスタを構築して以降、これまでに2度クラスタマイグレーションを実施しています。クラスタのアップグレードで、ダウンタイムが発生することがわかったためです。毎回のこれらの作業には手間と時間がかかっています。なので、マルチクラウドでマルチクラスタ構成にして、クラスタ障害やクラウド環境の障害を低減して、効率的なプラットフォーム運用を実現したいと考えています。

もう1つはカラーミーショップのリアーキテクチャです。アーキテクチャに起因する問題は、プラットフォームの移行やコンテナ化などでは解決できません。例えばカラーミーショップでは、人気商品の販売で特定ショップに負荷が集中して、サービス全体に影響が出ることがありますが、それはアーキテクチャ起因の問題です。

マルチクラスタやリソースの論理的分割などでこれらの可用性を向上させていきたいと考えています。現在、既存アプリのコンテナ化に並行して、リアーキテクチャのプロジェクトも進行しています。

まとめです。今回はGMOペパボのSREがふだんやっていることについて紹介しました。SLO、ポストモーテム、ソフトウェア的なさまざまなアプローチでの改善活動です。また、カラーミーショップへのKubernetes導入とGitOpsへの取り組みを紹介しました。そして最後に、今後やっていくKubernetesマルチクラスタ化による可用性向上とカラーミーショップのリアーキテクチャについて紹介しました。

私の発表は以上です。ありがとうございました。