こんにちは。@matsusukeと申します。ホスティング事業部でWebアプリケーションエンジニアとしてプロダクト開発・運用保守業務を行っています。 先日、社内の有志で集まってフットサルを行いました。数年ぶりにボールを蹴ったので2日間筋肉痛が取れませんでした。 交代人数が少ないと運動量が増えてつらいので、次回はもっと大人数で開催したいです。
今回は、ホスティング事業部内で開催した「ops祭り 2days ~2023春~」の取り組みについて紹介したいと思います。
- ホスティング事業部における「ops」について
- 大量に飛んでくるアラートの根本解決＆バリデーションの修正をした
- サービスの料金計算周辺のテスト環境整備
- サービス仕様を共通認識するためのドキュメンテーション
- ムームードメインにおけるドメインAPI利用手続きの自動化
- リニュアルしたWEBメーラーアプリケーションの改修
- まとめ
ホスティング事業部における「ops」について
ホスティング事業部では、ロリポップ！やムームードメインといった、リリースから10年以上経過したサービスを複数運用しています。
お客様の満足度を向上させるためにも、日々改善点や要望などの問い合わせが寄せられています。
それらに対して、Webアプリケーションエンジニア達が交代制で改善活動を行なっています。
ホスティング事業部内ではこの取り組みを ops と呼んでいます。
日々のops活動を進める中で、以下のような課題が顕在化してきていました。
- 類似の問い合わせに対する運用負荷の増加
- 長年に渡る運用による調査コストの高まり
- ある問題を特定するために、過去の履歴や変更履歴を辿ることが求められるケースがあり、その結果、調査にかかるコストが増えています。
- 仕様変更に伴うレガシーコードの改修で品質が担保できているかどうかの懸念
- システムの要件が変更されることで、既存のコードも修正が必要になりますが、その際に品質が維持されるかどうかが懸念となるケースがありました。
日々の運用業務を行いながら上記の課題を解決するのは時間的にもマンパワー的にも難しい状況でした。 そこで、事業部のエンジニア全員が2日間集中して上記を解決するための取り組みを行おう！ ということで「ops祭り 2days ~2023春~」を開催しました。 各エンジニアが2日間で取り組んだ課題について、以下でそれぞれ紹介します。
大量に飛んでくるアラートの根本解決＆バリデーションの修正をした
ホスティング事業部の東京オフィス組の@harachanと@seiji、@yukyanです！ 自分達は3人1チームとして、日頃大量に飛んできて確認に多くの時間を要していたアラートの根本解決とバリデーションの修正を行いました。 ops祭り中は、チームメンバーでワイワイ話しながら問題の解決にあたりました。また、お昼はしぶちかでそれぞれ好きなお弁当とお惣菜を買って帰り、会議室で食べたりなど非日常感があり非常に楽しかったです。
大量に飛んでくるアラートの根本解決
ムームードメインでは、レコードの不整合が起きた際にアラートが飛ぶようにSlack botを作成しています。 なかなか根本的な対策を取る時間を確保できず、その都度対処をしていたのですが、ある日、特定の不整合のアラートがおよそ10分おきに発火し、運用タスクに支障が出てしまうことがありました。 そこで、今回の活動をきっかけに根本対処に取り組むことにしました。
まず修正にあたり、アラートを意図的に発生させることから始めました。 アラートが発火する条件は、コード内にあるのでもちろんわかるのですが、通常の操作では発生しえない条件となっています。 どういった操作をお客様が行った結果、アラートの条件にヒットするのかまったくわからない状況だったので、テスト環境を使い条件を変えながら操作を行いました。
なかなか再現ができずops祭りの1日目をほぼこの再現に費やしましたが、@yukyanが特定ページでタブを複製してそれぞれのページで操作を行いアラートの再現に成功しました。（本当に再現に苦労した） 事象の再現ができたので、それをもとに修正と対策を行いました。具体的には、以下のことを行いました。
- 事象の発生を防ぐ実装を追加
- テストの追加
- レコードの不整合の検知をアプリケーションのコードではなくRedashで行う
3 に関しては、この不整合が起こるのは今回対策したコードによるものだけではない可能性があるため、根本的に検知を行えるよう、@harachanがクエリを書いてSlackに通知するようにしました。 これらの対応の結果、同じ原因によるレコードの不整合は今のところ発生しておらず、運用タスクを行う際の負荷が大幅に削減されました。
バリデーションの修正
引き続き、3DS2.0APIのパラメータに渡す情報にバリデーションを設けた話をします。
1. 3DS2.0とは
3DS2.0は、クレジットカード番号、有効期限、セキュリティコードなどの情報を、カード発行会社とサービスとの間で暗号化してやり取りすることで、不正利用を防止することができる仕組みです。 3DS2.0では、リスクベース認証が導入されています。 これは、クレジットカードのオンライン決済において、よりスムーズかつセキュアな認証を提供するための機能です。 リスクベース認証では、カード発行会社が保持するユーザー情報をもとに、ユーザーの信頼性を評価することで、認証を要するかどうかを決定します。 どんな情報を渡せば信頼されたユーザーと判断されるかは、ブラックボックスになっています。
リスクベース認証では、以下のようなユーザー情報をもとに判断が行われます。
- ユーザーの購入・ログイン履歴
- ユーザーの地理的位置
- ユーザーのデバイス情報
これらの情報をもとに、ユーザーさんの信頼性を評価することで、不正利用のリスクを低減しつつも認証の手間が省けるため、安心かつスムーズな決済を行うことができます。
2. 今回の課題
以前から、クレジットカードでうまく決済できないというお問合せを時折いただいていました。 この度原因を調査したところ、3DS2.0APIのパラメータに渡すユーザー情報の一部が指定された形式でうまく渡せておらず、認証に失敗していることがわかりました。 そのため、パラメータに渡す情報にバリデーションを実装することで、正しく決済できるようにする必要がありました。
3. 実装
以下は、3DSサーバーに渡すパラメータに対して行うべきバリデーションの例です。
- パラメータの長さを確認する
- パラメータが指定された形式に従っているかどうかを確認する
- パラメータが許可された値の範囲内にあるかどうかを確認する
ここまではAPIの仕様を調べればわかりますが、他に考えなければならない問題は以下の２点でした。
- バリデーションをどこに設けるのか
- パラメータを渡す直前に設けるのか？それとも、ユーザーさんがサービスに情報を入力する際に設けるのか？
- バリデーションで不正な形式だと判断された場合どうするのか
- ユーザー情報を正しい形式に変換して渡すのか？それとも、渡さないのか？
この２点を、セキュリティ面やサービスの仕様面から考慮しつつ、バリデーションを実装しました。
4. 結果
バリデーションを実装したことで、ユーザーさんからのお問合せが減り、クレジットカードがうまく認証されるようになりました！
サービスの料金計算周辺のテスト環境整備
@tascriptと@mochikoはサービスの料金計算周辺のテスト環境を整備しました。 料金計算周辺の改修は影響範囲が非常にシビアであるため、テスト環境を充足することで開発者の全員が安全に改修ができる環境を提供できることを目標にしました。 今回はロリポップ！、ムームードメイン、ヘテムルの3媒体を対象として調査および改修を進めました。
料金計算機能のテストコードの見直し
今回は2日間という短期間であったため、「テストケースの網羅性」にのみ集中し、調査を進めていくことにしました。 調査を進めるにつれ、テストケースの網羅性が失われている状態が発覚しました。 これにより、料金計算のコアロジックがどのような役割を果たしているのかが不透明となっており、テストコード自体を見てもなにが起きているのかわかりにくくなっていました。 また、ユニットテスト内でデータ層のモック化ができていないことにより、コアロジックとは関係のないデータベースを利用したテストが複数ありました。 これにより、テストの実行速度低下およびテストの責務範囲を逸脱したテストコードが存在していたため、これを改修しました。
結果として、テストコードの見通しが改善されたため、「どこまでテストできているか」が一目瞭然となり、テストの網羅性向上につながりました。 また、今までテストしにくかったテストケースについても入力する値のみ変更することで、さまざまな料金体系に対してテストできるようになり、今後の価格変更やプランの追加にも強いアプリケーションの土台を作成することができました。 プロダクトはチームの協力がないと改善しないので、テスト環境を整備したらすぐさま周囲に通達して協力を仰ぐことも忘れずに実施します。
ペパボのいいところの1つとして、上記のリアクションのように称賛の文化が挙げられます。褒められたらもっともっと改善したくなりますよね。
ローカルのテスト環境の整備
上の画像では何もやってないと言ってますが、別のことをちゃんとやりました（笑）今回私も@tascriptさんと手分けしてテストコードの調査の作業を始めたのですが、とあるリポジトリでローカルのテスト環境がうまく動作しない事を発見したので、途中で作業変更して対応することにしました。 CIのテストは最新の状態になっており問題なく動作していたのですが、ローカルでテストを実行するDocker環境だけ最新の状態に追従できていない状況でした。 対応自体は難しいものではないと思うのですが、私自身がDocker環境のエラー解消に慣れておらず、環境整備プラス不足していたテストを追加するところまでやると意外と時間がかかってしまいました。
前述の通り私個人がDocker環境のエラー解消の対応経験がほとんどありませんでしたので、それに集中して取り組めたのは非常に良い経験でした。何より、エンジニアみんなでわいわいやれて楽しかったです。これからもテスト環境の整備が行き届いていない部分があれば積極的になおしていきます！
サービス仕様を共通認識するためのドキュメンテーション
@genkiroid は、以下の課題について改善の一助とすべくドキュメンテーションに取り組みました。
長年に渡る運用による調査コストの高まり
- ある問題を特定するために、過去の履歴や変更履歴を辿ることが求められるケースがあり、その結果、調査にかかるコストが増えています。
こうした課題の要因となっているもののひとつに、ドキュメントの不足があります。ホスティング事業部が運営するサービスは他の事業部と比較して多く、かつ、ありがたいことに歴史が長いものがほとんどです。そして、残念ながら、それらのサービスに関する仕様についてのドキュメントが完全に整備されている状態とは言えません。こうした状態は、システムに何らかの変更を加えようとした際に、影響範囲や変更を加えるべき実装部分に、あたりをつけることを難しくします。そのため、イチからコードを読むしかない状態に近くなり、実装を開始するまでに必要な時間が長くなります。また、それだけでなく、影響範囲を正しく特定できなければ、期待値の定義も正確にはできなくなるため、テストケースも正しく設定できず、品質の担保が難しくなります。
今回のイベント開始当初は、訳があって引き継いだ案件をリリースまで持っていくことをゴールとしていました。しかしながら、動作確認における期待値の定義を行うにあたり、ドキュメントが不足しているために、実装を見に行っていることに気付いたのです。私もその案件の影響範囲に関する部分のサービス仕様を正確に暗記しているわけではないため、ドキュメントにないことは、実装を見て確認するしかありませんでした。そのため、この時点でゴール設定を上述したドキュメンテーションに変えることにしました。今回は、単発案件のリリースを完了させるよりも、レバレッジが効くと判断したからです。
途中でゴールを変更したこともあり、成果物のボリュームは大きくはありませんでしたが、今回ドキュメントを作成した範囲に関して、今後も同様にサービス仕様を確認する必要が出た場合に、私が使った時間と比較して、おそらく半分以下の時間で済むようになるため、一定の成果につながると考えています。得られた時間をユーザーへの価値提供に回せるからです。
ムームードメインにおけるドメインAPI利用手続きの自動化
@kinosuke01 と @otomi は、一緒に以下の改善を行いました。
背景
「ムームードメインAPI」のご紹介 にあるとおり、ムームードメインでは、申請があったお客様に対してAPIを開放しています。 また、その際には検証環境APIも同時に提供をしています。
課題
検証環境APIを提供するにはアカウントのセットアップが必要です。 作業内容としては、本番環境から申請があったお客様のアカウント情報を取得し、検証環境にインポートするというものですが、エンジニアが直接SQLを発行して対応しており、この作業が地味に大変なものとなっていました。 また、提供にあたり複数のリポジトリに対しファイルの変更も必要になり、この対応にも工数が発生していました。
対応
本番環境と検証環境とではそれぞれ独立しているため、アプリケーションに検証環境のアカウントセットアップ機能を盛り込むことは困難でした。 そこで、手作業で行っていることを、そのまま自動で実行するコマンドを実装するアプローチを取りました。 エンジニアが手元のPCでコマンドを実行するだけで、検証環境のアカウントセットアップと複数リポジトリに対しての変更が完了するイメージです。Go言語で実装しました。
手元でコマンドを実行して、検証環境のアカウントセットアップとファイルの変更があっという間に終わったときは、グッときました。
リニュアルしたWEBメーラーアプリケーションの改修
私、@sangunは、@matsusukeと共にムームードメインの新WEBメーラーの改善を行いました。
ムームードメインの新しいWEBメーラーアプリケーションは、2023年03月31日にリニュアルバージョンを正式にリリースしました。 リリース後、ありがたいことにユーザーから改善点や要望がのお問合せを多くいただいています。
この2日間では特に多くの方からご要望をいただいていた機能の改修・機能設計に注力しました。 今回の改修により、同じ内容のお問合せを受けることがなくなるため、日々のops業務での対応コストを削減させることができました。
リリースして間もないため、まだまだ改善すべき点があります。 今後もユーザーが使いやすいメールクライアントを目指し、改善を続けていこうと思います！
まとめ
今回、事業部のアプリケーションエンジニアが一堂に会して改善活動に集中して取り組みました。 2日間という時間的な制約があったため、全ての課題は解決できませんでしたが 今後も定期的に開催し、機能追加などの開発業務に注力できる環境を目指します！