コードレビュー自動化、障害注入／分散トレーシング、マルチクラウドIaC――コンテナベースのCI/CDがもたらす新たな開発者体験とは：コンテナベースのCI/CD本番事例大解剖（終）（1/2 ページ）

Kubernetes、コンテナ技術を活用したCI/CD基盤におけるサービス開発について、リクルートテクノロジーズの事例を基に解説する連載。最終回は、「プロダクト品質の磨き込み」「アジリティの向上への取り組み」の2つを中心に解説を進めます。

[藤原涼馬, 小松凌也，リクルートテクノロジーズ]

　本連載「コンテナベースのCI/CD本番事例大解剖」では、リクルートテクノロジーズが取り組んだ事例を基に、Kubernetes、コンテナ技術を活用したCI/CD（継続的インテグレーション／継続的デリバリー）基盤におけるサービス開発について解説しています。

　これまで3回にわたる連載では、アプリケーションエンジニアおよびインフラ／運用エンジニアの観点から、技術選定における考え方とプロダクト開発の取り組みで生じた現場での課題とその対応について解説しました。それらの各種取り組みについては、ここまでの連載で述べた取り組みだけではなく、その他のさまざまなプロジェクトでも並行して進めています。

　連載最終回となる今回は、さまざまなプロジェクトにわたって取り組んでいる、または今後取り組んでいこうとしている事柄について解説します。主な取り組み内容として、「プロダクト品質の磨き込み」「アジリティの向上への取り組み」の2つを中心に解説を進めます。

プロダクト品質の磨き込み

　コンテナベースのCIを活用することで、よりスピーディーかつ安定したビルドとテストの環境を手に入れることができ、テストを積極的に記述しようという文化をチーム内で醸成できました。その結果、プロダクトの保守性向上といった成果を得ることができました。また、安全かつ確実なデプロイプロセスをKubernetesの活用により実現できました。

　こうしたCI、Kubernetesを中心とした取り組みを通じて、コードやデプロイプロセスの品質を一定水準まで高めることができたものの、その一方で取り組むべき課題は多く残っています。

　次に、具体的な課題感と、検討中または取り組み中の対応方針について説明します。

工学的手法に基づいた品質の測定

　アプリケーションコードとテストコードを記述した後に、CIを用いてテストを実行することを「文化」としてチームに根付かせることで、問題のあるコードがリリース予定のコードに紛れ込むことは激減しました。少なくとも既存機能についてはテストのステータスから既存の仕様を壊しているか否かの判断が可能になりました。ただし、その前段階の課題が残り続けています。

　具体的には、レビュアーがコードレビューを行う際、「適切なテストが定義されているか」といった判断を依然として行う必要があります。このような課題を放置し続けた場合、特に新規機能の開発スピードが上がるにつれて、急激にレビュアーの負担が増してしまいます。

　本来であれば、コードレビューは「ロジックをさらにシンプルかつ高速なものにできないか」「元来意図していた仕様をコードが満たせているか否か」といった観点で行われるべきです。ところが、「テストが十分に記述されているか」といったことを確認するのは、コードレビューで本来なすべき事柄から少し外れてしまいます。

　そこで現在、レビュアーの負担を軽減する取り組みを進めようとしています。具体的には、ソースコードの循環的複雑度（Cyclomatic complexity）とテストカバレッジなど複数の定量的指標を組み合わせることで、コードレビューの実施時にレビュアーにかかる負担を削減したいと考えています。

人間の注意力に頼り過ぎないコードレビューの実現

　「Kubernetesにより安全かつ確実なデプロイが実現できた」と先に述べました。ただし、これは正しい環境設定のコードが記述されている場合に限られます。現在、ここが大きな問題となっています。

　これは特に、新しい開発環境をもうワンセット準備するといった、「新規環境払い出し」の際に問題になりがちです。具体的には、環境変数に他の環境向けの値を誤って指定しているなど単純かつささいなことが原因となって問題が発生します。ささいなことであれ、システム全体では不具合を抱えた状態となってしまいます。

　こうした単純な誤りに対しては、「レビュアーが気を付ける」「ダブルチェックする」といった対策になりがちです。ところが、これは根本的な解決策とはいえません。現時点では、環境設定をコードで管理できているため、設定ミスが発生した場合でも原因の特定はすぐにできました。しかし、問題発生の予防にはなりません。今後システムに改修が加えられ、設定の複雑化が進んでいくことを考えるとリスク低減に向けた仕組みが必要です。

　そこで、「人間の注意力に頼ったチェックではなく、機械を使った仕組みでカバーしよう」という観点で、「人間が得意なことは人間に、機械が得意なことは機械に任せる」とした方が長期的に見て効果が上がりやすいと考えています（図1）。もちろんですが、人が念のために確認することを否定するものではありません。

図1　人間と機械、それぞれの得意なこと苦手なこと

　そこで、問題発生を予防するための仕組みとして下記を考えています。

1. 環境固有な設定情報の命名ルールの策定とルール運用の厳格化
2. 1.に「Lint」などを使ってCIパイプライン上で自動チェックする仕組みの実現

　レビューでは、機械に判断できることは可能な限り機械に任せる（または機械によって人間の判断を支援する）こととし、「そもそも仕様に準拠した実装になっているかどうか」「処理のためのアルゴリズムが適切か否か」といった人間ではないと判断が困難なものに注力できるような仕組みを、本格的に作り上げようと考えています（図2）。

図2　機械がやるべき部分と人間がやるべき部分を明確にする

　ここまでに挙げた工学的手法に基づく品質の測定と、人間の注意力に頼らないレビューの実現を通じて、レビューの際にレビュアーが単純なチェックで消耗するのではなく、より高度な事柄（仕様の充足度合いやそれを実現するロジックの良しあしなど）の判断に注力できるようにしたいと考えています。

運用フィードバックを生かした継続的なセキュリティ品質の改善

　プロダクトの品質は、アプリケーションコードのみにはとどまりません。機能以外の部分についても品質を継続的に磨き込んでいく必要があります。

　一つの例として、セキュリティ品質を継続的に改善していくための仕組み作りにも取り組んでいます。具体的には、外部攻撃対策としてプロダクトリリース初期からWebアプリケーションファイアウォール（WAF）と不正侵入検知システム（IDS）を導入し、それらとパブリッククラウドのサービスを組み合わせることで、品質としては十分なものを確保しつつ、低コストの運用と継続的な改善に取り組んでいます。また、WAF／IDSの導入に際しても高頻度のデプロイとアップデートの実現を目的にコンテナとしてデプロイ、運用しています。

図3　継続的なセキュリティ改善のための取り組みイメージ

　さらに、各種機密情報（DBのパスワードなど）の管理についても、パブリッククラウドの仕組みを利用して暗号化した状態で管理し、権限を持たない人の場合はそれらシステムの機密情報を閲覧できないようにしたり、「権限を持つ人である場合でも、いつどこで機密情報を取り扱ったのか」を、人的コストをあまりかけることなく確認できるようにしたりする仕組みを整えようとしています。

　具体的な実現手段としてGoogle Cloud Platform（GCP）の「Cloud Key Management Service（KMS）」を活用しています。これによっていつ、どこで、誰が機密情報をエンコード、デコードしたのかがログから追えるようになります（図4）。

図4　Cloud KMSを用いた機密情報へのアクセス監査

　Cloud KMSから得られた情報を蓄積、分析することで、「普段とは異なる人が情報にアクセスする」といった事象があった場合などに対し、すぐに気付きやすい環境を作り上げることができます。

非正常系処理におけるアプリケーション品質の磨き込み

　プロダクトの品質改善における中期的なチャレンジ事項として、特に非正常系処理における、アプリケーション品質を磨き込むための取り組みを進めようとしています。

　ここで述べている「アプリケーション品質」とは、「コードのロジックが非正常系処理も含めて適切に実装されていること」「非機能、特に性能面で十分な実装がなされていること」を含んでいます。これらの実現に向けたコアテクノロジーとして、「Istio」などのサービスメッシュを活用しようとしています。

　第1の目的は、Istioによる障害注入（Fault Injection）によって、アプリケーションコードよりも下のレイヤーで障害が発生している状況を模倣し、処理を継続または復旧できるかといった点を確認することです。

　さらに第2の目的として、「通信などが不安定になることで、サービス全体の性能影響などを中心にどのような事象が発生するのか」を、簡易的な負荷試験と組み合わせて定量化、可視化することを見据えています。可視化に際しては分散トレーシングの仕組みを活用し、遅延やリトライが発生した際に意図しなかったコンポーネントに影響が発生しないかといった影響範囲の可視化の実現に向けた準備を進めています（図5）。

図5　Istioによる障害注入

　特に後者（分散トレーシング）については、本番環境においても有用であることが明白であり、本番環境における性能監視の観点でも導入することを検討中です。