Lift ＆ Shiftで解決しないカスタマーサポートのシステムをCaaSで刷新している話

情報システム本部に所属している小林です。ヤフーのコーポレートエンジニアリング領域でエンジニアリングマネージャーとSRE（Site Reliability Engineering）を担当しています。

ヤフーが提供するサービスに対して、お客様から日々「困った」が寄せられています。「困った」を解決する業務オペレーションはIaaS上で動く100以上の顧客応対ツール（以下、CSツール）が支えています。

これらのツール群をビジネス部門のタイミングでリリースができるように、IaaSからCaaSにシフトして業務基盤を開発しています。CaaSシフトにチャレンジして得られたビジネスとDevOpsへのメリット、今後の課題といった知見について紹介します。

ヤフーのカスタマーサポートとは？

ヤフーにはサービスに関するお客様のお問い合わせの「困った」が寄せられています。この「困った」を、お客様との応対を担当するコミュニケーターが日々解決に導いています。

寄せられる「困った」

コミュニケーターが担当する「困った」は大きく二つの特徴に分類されます。

1. 日々答えが変わるお問い合わせ
   • 例） キャンペーン期間中に商品を購入したと思ったが、ポイントが付かなかった
2. 過去のナレッジが生かせるお問い合わせ
   • 例） ログインができない

1の日々答えが変わるお問い合わせで、CSツールが主に利用されます。2の過去のナレッジが生かせるお問い合わせは、上記のようなヘルプページなどを活用しながら解決に導きます。

カスタマーサポートを支えるシステム

コミュニケーターはCSツールを使い、解決への手ががりを探すための業務オペレーションを実行します。前章で述べた、日々答えが変わるお問い合わせは次の手順を実行して原因を探ります。

• キャンペーンでポイントが付かなかった商品購入の調査をする業務オペレーション
  • ログイン履歴を調べる
  • 購入履歴を調べる
  • 購入履歴がポイント付与に該当するかキャンペーン仕様と突き合わせる

原因が複雑な場合は複数のCSツールを組み合わせるため、解決までに必要な業務オペレーションの数も増えます。業務オペレーションで使うCSツールの総数は100以上あり、プロダクトオーナーはサービス部門やカスタマーサポート部門などさまざまです。

あるサービスでリリースがあった時は、開発内容に合わせて業務オペレーションを扱う複数のCSツールに変更が入ります。「キャンペーンでポイントが付かなかった商品購入の調査をする業務オペレーション」の場合では、各オペレーションを担当するCSツールに変更が入ることを意味します。この状況を図にまとめると、次のようにコミュニケーターが扱うCSツールが多数存在する状況でした。

以上の経緯があり、次章で述べる課題が生まれました。

Lift ＆ Shiftでは解決しない課題

DevOpsの側面からはクラウドへスムーズに移行するにはLift ＆ Shiftが望ましい状況でしたが、ビジネスとDevOpsの両輪が円滑になることが全体最適として取り組む課題でした。

ビジネスにおける業務オペレーションの目的の一つは、お客様の「困った」状況や背景を素早く読解することです。読解するために使う100以上のCSツールの存在を踏まえてビジネス、DevOps双方の課題を同時に解決する必要がありました。

ビジネス: 「困った」を読解するまでの業務オペレーションの手数が多い

前章で述べた通り読解が複雑な場合は、CSツールを組み合わせて原因を絞り込んでいきます。CSツールが出力する情報の粒度は、次の通りさまざまでした。

• APIのデータを単純に表示する粒度
• 原因をほぼ絞り込めるまでロジックが作り込まれた粒度

情報の粒度がバラバラなために読解に至る文脈は断片的になっていきます。この断片化した情報を、コミュニケーターの経験や別のCSツールで補う業務オペレーションになっていました。

ある業務オペレーションでは複数のCSツールを使用し、20以上の作業が必要でした。

DevOps: ビジネス要求からデプロイまでのリードタイムが長い

CSツールは100以上のアプリケーション群から成り立っているため、合計で100台以上のIaaS環境のサーバーが稼働しています。コードで構成管理を行うためにChefといったツールは導入されていましたが、サーバー単位の管理に留まっていました。

デプロイ頻度を上げるためには、システムを止めずに安全にメンテナンスをする可用性を保つ仕組みが必要です。既存のIaaS環境ではシステム全体で可用性を保ちながらImmutable Infrastructureを実現する技術の選択肢が限られており、少人数でインフラを含めてDevOpsをするチームでは導入・維持するコストが高いものでした。ぜい弱性のパッチ適用なども含めるとステートフルになっていき、維持管理コストが全体の半分以上を占めるツールも生まれました。

これらの維持管理コストに圧迫されて、CSツールで1機能をリリースするためのリードタイムが最長3カ月かかるプロダクトもありました。リードタイムが長くかかるために、キャンペーンに間に合わず手動の業務オペレーションで対応することがありました。

課題に対して設定したゴール

ビジネスとDevOps双方の課題を踏まえて、デプロイまでのリードタイムを短くして改善頻度を上げて、業務オペレーションの手数を減らすをゴールに設定しました。ビジネスとDevOpsのどちらにも共通するのはアジリティを高めることです。

ビジネス

• 読解までの業務オペレーションの手数が多い

• 読解を補う要約のビジネスロジックを作り、読解のオペレーションの手順を減らす
• 業務オペレーションで迷わないようにCSツールを集約する

DevOps

• ビジネス要求からデプロイまでのリードタイムが長い

• CSツールがアプリケーション開発に集中してデプロイ頻度を高く保てるように、インフラとCI/CDの自動化を提供する
• インフラはエコシステムが整っているコンテナ技術を中心としたマネージドのプラットフォームに移行して、少人数でインフラをコントロールできる範囲に絞る

アーキテクチャ

アーキテクチャはCSツールとプラットフォームの間に業務基盤層を入れた3層構造です。CSツールのリードタイムを短くするために、業務基盤層とプラットフォームで、どのCSツールでも必要になる共通的な機能を実装しています。

CSツール層

• コミュニケーターが使うCSツールを開発するアプリケーション部
• 業務オペレーションを業務プロセス単位に集約

業務基盤層

• CSツール層の高いデプロイ頻度を支えるアプリケーション基盤・インフラ部
• 要約のビジネスロジックを作り、コミュニケーターの業務オペレーションを補助
• ネットワークからミドルウェア、アプリケーションまでの統制を取るためにCaaSを選定

プラットフォーム層

• マネージドなプラットフォーム群
• SLAに関わる可用性・信頼性などの非機能はKubernetesの標準機能を活用
• CSツールと業務基盤の認証・認可にロールベースのアクセス制御を提供するAthenzを利用

CSツールはアプリケーションのDockerイメージの作成と、権限の設定、デプロイのカスタマイズを済ませればリリースできるように開発プロセスを簡略化をしています。今までのCSツールはさまざまなプロダクトオーナーで開発していた経緯からモニタリングや監視、ロギングは独自の実装となっていました。これに対して業務基盤層とプラットフォームが提供する、サポート用のサイドカーを組み込むことでアプリケーションへの影響を抑えています。読解を補う要約のビジネスロジックは、再利用性を高めるために業務基盤層に配置しています。要約のビジネスロジックの一例は、先に述べた「キャンペーンでポイントが付かなかった商品購入の調査をする業務オペレーション」をビジネスロジックがまとめて行います。

また、ミドルウェアより下のインフラは業務基盤層のエンジニアが統括して、ピザ2枚ルールの人数で業務基盤のDevOpsができる規模に収めています。

CaaSシフトで得られたメリット、大変なこと

従来のIaaSから、CaaSを中心としたプラットフォームにシフトしたことで得られたメリット、大変なことは次の通りです。

メリット

• 単一責任の原則に従いモジュールの分割が進み、機能追加や仕様変更がしやすくなった

コンテナを単一責任にすることでコンテナ・デザインパターンの恩恵を受けられました。例えば、サイドカー・パターンで業務アプリケーションと認証認可を分離しておくことで、認証認可のアップデートに業務アプリケーションが受ける影響を小さくできました。

• マネージドなプラットフォーム群を使うことで、可用性の維持をプラットフォームに任せられる

SLAに関わる可用性・性能はマネージドのKubernetesのオートスケール、オートヒーリング、ローリングアップデートに任せられます。他にもクラスタのアップグレードやスケールアウトもコマンド一つで行え、少ない工数でインフラのメンテナンスができています。

また、GrafanaとPrometheusで稼働率をダッシュボード化して稼働率を下げるバグや、インフラのオペミスにいち早く気付ける仕組みを導入しています。

これによりSLOに基づいたデプロイ速度と改善のバランスを取ろうとしています。

• クラウドプロバイダーより距離が近いプラットフォーム

これは余談ですが、ヤフーはマネージドなプラットフォームが社内で多数提供されているため、クラウドプロバイダーより近い距離で相談ができます。開発要望を上げたら数週間でリリースされることもありました。

大変なこと

• CI/CDをメンテナンスするコストを日々払う必要がある

IaaSはOSやアプリケーションのセキュリティアップデートを自ら行う必要があり、サーバー台数に比例してメンテナンスコストが増えていました。マネージドなCaaSと周辺のプラットフォームは、バージョンが各プロダクトオーナーによってコントロールされセキュリティアップデートが適用されるメリットを受けられています。

一方でバージョンがコントロールされるということは、外部要因によるアップデートへの対応が頻繁に起きることを意味します。CaaSにシフトするためには、開発・テスト・運用のCI/CDパイプラインを頻繁に動かしてアップデートに追従できるDevOpsの体制が必要です。

• Kubernetesの振る舞いが要件に適合するかを検証する

KubernetesはImmutable Infrastructureが実現でき、オートスケール、オートヒーリング、ローリングアップデートといった自動化された機能が利用できます。

期待通り機能させるにはプラットフォームが意図した通りの設計と実装が必要です。例えばダウンタイムなしでローリングアップデートするためには、Liveness Probe、Readiness ProbeおよびStartup Probeを使用する | Kubernetesにあるように、Readiness Probeの設定と、エンドポイントの実装が必要です。

その他にも、コンテナの再起動・停止時にはKubernetesのライフサイクルに従った適切なハンドリングが必要です。コンテナはThe Twelve-Factor App （日本語訳）にある廃棄容易性に従って、実装を進める必要がありました。

現段階の評価

業務基盤層に先行してリリースした、CSツール単体で応対業務の効率化を実現できました。

• ビジネスの成果

CSツールの集約と読解オペレーションの改善で、一人あたりの平均回答数が43％増加しました。

• DevOpsの成果

開発環境、検証環境、本番環境のCI/CDパイプラインが整備され、インフラ側の手動オペレーションを介在することなくリリースが可能になりました。また、先に述べた3カ月かかったリリースと比べて、1週間ごとに複数の機能をリリースできています。

今後に向けて

今後はビジネスの改善をより早めるために、次の課題に取り組んで行く予定です。

• 開発環境、検証環境をまたいだパイプラインの構築による、デプロイのさらなる自動化

現在は人間のチェックやテストが入るため開発・テスト・デプロイを開発環境、検証環境といった動作環境の単位に切り出しています。環境をまたいで安全にCI/CDを行うために、SLI/SLOベースのテストを組み込むことも検討しています。SLI/SLOベースのテストは高コストですが、繰り返し長く使えれば開発者に素早くフィードバックを与えるメリットが上回ると考えています。

• モブ作業の導入

業務基盤のインフラはオペミスで全体のサービス停止を招く要素が多い領域です。現在は一から設計・構築・テストをしたメンバーが在籍していますが、新しいメンバーも入ってきます。

一から構築したメンバは商用リリースの前に繰り返した設計・構築・テストの経験を通じて、何をしたらサービス停止につながるかの勘所を知っています。新しいメンバーへの勘所の継承は、チームで誰でも作業ができるレベルを目指すには避けられません。そこで、一つのバックログについて設計・構築・テストをチームで作業を行い、新しいメンバーと既存のメンバーで、相互のフィードバックで属人化を避ける仕組みを作りたいと考えています。

おわりに

ヤフーではこれからもCSツールに限らずカスタマーサポート領域全般で、エンジニアリングでビジネスの課題を解決していきます。カスタマーサポート領域を始めとしたBizDevOpsにご興味がある方はご応募いただけますと幸いです。

• IT戦略スペシャリスト（カスタマーサポート）