こんにちは、WEAR部運用改善チームの佐野です。
私たちのチームでは、WEARの日々の運用業務を安全かつ効率的に行えるよう改善をしています。今回は、年初から行っていた不要APIの削除作業についてご紹介します。
背景
残念なことに長い間WEARでは不要になったAPIが放置されてしまっており、どのAPIが実際に使用されているものなのかが分かりにくい状態になっていました。WEARのAPIはWeb・iOS/Androidアプリ・バッチ・社内ツールから参照されているのですが、使用されているのかが明確でないAPIが多数残されていることにより、以下のような問題がありました。
- リプレイスや脆弱性診断の対象箇所の洗い出しの際に余計なコストが掛かる
- 運用業務において何かを調査をする際に、使用されていないAPIがあることで不要なコードも増え、調査がしにくい
実際に、他部署からの問い合わせの調査でとある処理を追っていたら、思っていたAPIではなく実際に使われているのは似たような名前をした別のAPIだった…というような事もありました。
上記の問題を解消するために、不要なエンドポイントや関連ファイルを削除し、現在使用されているエンドポイントのみを残して整理することにしました。
体制・スケジュール
削除対応は、バックエンドエンジニア4名で実施しました。
まず削除候補のAPIの調査を行い、削除対象となったものについては以下の流れで関連ファイルの削除とアクセス監視を行いました。
新たに削除するエンドポイントを毎週1人あたり約3つずつ追加していき、全ての削除が完了するまで約8か月かかりました。
削除する上でのリスク
現在使用されているAPIを誤って削除してしまった場合サービスに影響が出てしまうため、削除前の確認と削除後の監視を慎重に行う必要がありました。確認ポイントについては抜け漏れが無いように後述する一覧表を元にチェックリストを作成して管理しました。
事前調査について
APIを削除するにあたり、以下の通り事前の確認を行っていきました。
1. 削除候補API一覧の作成
まず、以下の2つの観点から削除候補のAPIを洗い出してスプレッドシートの一覧表を作成しました。
- アプリチームにヒアリングした、iOS, Androidアプリから参照していないAPI
- Swaggerに記載されていないAPI
作成した管理表には削除対象のエンドポイントであるか、対象である場合は現在のステータスがひと目でわかるように項目を設けて、一連の削除作業を通して使用しました。
2. アクセス有無の確認
担当者ごとに、Splunkを用いてアクセスログの分析を行いました。
直近2か月で対象のAPIへリクエストが飛んできているかを基準としてアクセスの確認を行いました。なぜ期間を2か月に指定したかというと、月次で動いているバッチ処理からのアクセスを検知するためです。
3. アプリ以外からの参照を確認
前述した通り、WEARのAPIはアプリ以外にもWeb・バッチ・社内ツールから参照されています。まずはアプリ以外の全てのリポジトリ内で削除候補のAPIのエンドポイント名でgrepして、他のリソースから呼び出されていないことを確認しました。
4. アプリからの参照を確認
アプリからの参照有無が確認できていないエンドポイントについて、APIのエンドポイントを定義しているクラスで参照されていないことを確認しました。その後、アプリチームへの最終確認を行い、確認が取れたものを削除対象と判断しました。
削除手順について
上記の確認の結果、削除対象となったエンドポイントは以下の流れで削除していきました。
ブランチの運用
前述した通り、ルーティングの削除→3日間のアクセス監視→アプリケーションコードの削除→3日間のアクセス監視という流れで進めるため、ブランチを分けて作業していきました。毎週火曜日をリリース日と定め、監視期間中に次のリリースの準備を進めていました。
総行数の確認
WEARではこうした不要コードの削除も成果として称える文化があります。そのため、対象のエンドポイントを削除することで何行分のコードを削除できたかを最後にカウントできるように、以下のGitコマンドで削除前後のリポジトリ内の総行数を取得し一覧表に記録しました。
git ls-files | xargs -n1 git --no-pager blame -w | wc -l
ルーティングの削除
対象のルーティングの定義を削除した後、Postman等を使ってAPIを呼び出して、HTTPステータス404が返却されることを確認しました。
アプリケーションコードの削除
ルーティングから呼び出していたControllerの処理を削除しました。Controllerクラスに紐づくModelクラスも不要になるかを確認し、他から参照されていなければ全て削除しました。
また、WEARのリプレイス前の環境ではなんとストアドプロシージャが多用されているのですが、削除した処理でしか使用されていないものは追々削除していけるように一覧表に記録しておきました。
Swaggerの定義削除
削除したAPIに関する記載を全て削除しました。
Splunkダッシュボードでのアクセス監視
ルーティング、アプリケーションコードの削除後にはそれぞれ3日間の監視期間を設けました。事前のアクセス確認と同様に、ここでもSplunkを使用しました。Splunkにはダッシュボードという機能があり、プルダウンから対象のAPIを選択してアクセスの有無がひと目で分かる状態にしていました。
アクセスがない場合
アクセスがある場合
作業中の問題点
Splunkの検索クエリ改善
Splunkを用いたアクセス確認を行う際に、結果が出るまでに数時間かかるという問題がありました。当初は検索期間を短い期間に区切って検索したり、前日の退勤時にバックグラウンドでログの検索を開始して翌日の朝に確認したりしていました。
しかし、あまりにも調査に時間がかかってしまうためクエリの改善を行いました。
改善前のクエリ
* uri_path="/api/hoge*" sourcetype="ms:iis:auto" host IN(some-wear-host) source="path/to/log"
改善後のクエリ
* sourcetype="ms:iis:auto" host IN(some-wear-host) source="path/to/log" | search uri_path="/api/hoge*" OR uri_path="/api/fuga*"… | stats count as request_count by uri_path
改善した内容は以下の通りです。
- Bot用のログは参照しないように検索対象のログを絞る
- 期間がパフォーマンスに影響するため、1か月分×2並列で動かす
- 1エンドポイントずつ検索していたものをORで条件を繋げて複数検索にする
- 最低限の情報だけ返すように、uri_path毎のリクエストカウントを出力する
これらの改善をした結果、1つのエンドポイントのログを確認するのにかかる時間を3分の1以下に短縮できました。
さらに、バックグラウンド実行を選択して終了時にメール通知を受け取るようにすることで、ノンストレスで調査を進めることができました。
APIの誤削除について
アクセス有無の確認を徹底して行っていましたが、とあるバッチの処理で呼び出されているAPIを誤って消してしまうことがありました。なぜ起きてしまったかと言うと、それらのファイルがGit管理されていないという落とし穴があったためです…。
アクセスログから使用されているAPIだと分かったはずですが、特定のIPアドレスからの大量のアクセスを不正なものと判断してしまっていました。実際は不正アクセスではなく、AWSで固定IPを付与したホストからのアクセスであったことが後の調査で判明しました。
これらを踏まえ、他にもGit管理されていないファイルが存在しないか確認し、全てのファイルを管理下に置いたうえで再調査を行いました。
また、2か月間全くアクセスのないAPIを削除対象とするように改めました。
まとめ
最終的に削除したAPIは201件（全体の36.7％）、行数は52,392行（全体の8.8％）でした。
通常業務と並行して作業を行っていたため長期戦にはなりましたが、不要なAPIを全て削除したことで、より効率の良い安全な運用ができる状態に近づけることができました。また、削除したAPIでしか使用されていなかったストアドプロシージャも順次整理していく予定です。
さいごに
ZOZOテクノロジーズでは、一緒に安全かつ効率的にサービスを作り上げてくれる方を募集中です。
つい後回しにされがちな技術的負債の返済作業を、現場が提案して優先順位をあげて取り組める環境があることはWEAR部の強みだと考えています。
ご興味のある方は、以下のリンクからぜひご応募ください！
