プロジェクト立ち上げ時から考慮したい品質
西田@リテールアプリ共創部マッハチームです
今回は「品質」をテーマにブログを書いていきます
アプリケーションの品質を高めるために、自分が実践してきた内容をご紹介します
品質の定義
品質と一言で言っても、様々な観点があります
今回は特に以下の品質に関する自分なりの工夫を紹介します
- 稼働率が高い
- バグが少ない
- セキュリティが担保されている
- パフォーマンスが高い
稼働率が高い
ローンチしたアプリケーションが稼働し続けることは重要です
アプリケーションが停止すると、お客様の業務が止まってしまったり、金額的な損失が発生する可能性もあります
そのためには、想定外のことが発生してもアプリケーションの提供が止まらないよう、冗長化構成をとったり異常を検知したりすることが大切です
冗長化構成
稼働率を高めるために、アプリケーションを実行するインフラ環境は冗長構成を取ることが多いです。インスタンスが一部応答不能になったとしても、他のインスタンスが処理できるようにし、アプリケーション全体として機能を止めないように構成します
コンピューティングリソースならALBを使ったり、データベースなら Aurora を使うなどして冗長構成を構築することが多いと思います
今回は、冗長構成を取る際に筆者が気をつけていることをご紹介します
冗長化構成をテストできるようにする
本番環境だけでなく開発環境やステージング環境も冗長構成を構築しテストできるようにします
どうしても小〜中規模のアプリケーションだと、開発環境やステージング環境まで冗長構成にするのがもったいなく感じられ、本番環境だけ冗長構成にすることもあります
ただし、一度も冗長構成でテストしないまま冗長構成された本番にいきなりリリースしてしまうと思わぬ不具合が発生することがあり、場合によっては長時間の修正が必要になってしまうケースもあります
よくある例として、RDSを使って冗長構成(Read Replica)で構築した場合に、リードレプリカとライターを使い分けるような実装をすることがあります。その場合レプリケーションラグで不具合が起こりうる可能性があります。
例えば、1つの処理の中に、データベースへの書き込みと、後続処理でそのデータを読み込むといった処理がある場合、1つのDBであれば問題ありませんが、冗長構成になった場合にレプリケーションラグが発生し、書き込んだはずのデータが読み込めないといったことが起こり得ます
また、アプリケーションのメモリが共有されてる前提でのコードが書かれてる場合に冗長構成をとるとうまく動作しなかったり、ステートフルな接続を使った処理がある場合、冗長化されているリソース間で協調的な動作が必要だったりと、冗長化構成を取る上でのはまりどころがあります
そのため、本番リリース前に冗長化構成でテストできる環境を用意しておくことは重要と考えます
監視
アプリケーションに異常が発生している場合に、素早く検知、対処し、サービス提供が可能な状態にいち早く復旧させることができるようにしておくことは重要です
そのために特に筆者が重要と考えるのは以下です
- 外形監視
- アプリケーションのログ監視
外形監視
運用者自らがアプリケーションの異変にいち早く気づくことは重要です
外形監視はできるだけ、実際にアプリケーションの動作に必要な要素を全てチェックするのが望ましいです。例えば、ヘルスチェックのエンドポイントを用意する場合は、データベースへの接続まで含めるなどの工夫ができると良いです
アプリケーションログ監視
外形監視を、アプリケーションの全ての機能に対して設定することは難しいです
想定外の事象がアプリケーションで起こっていることを検知するために、アプリケーション自身のログを監視することが有効です
例えば、ログレベルが ERROR や FATAL のものが出力されるとアラートされるように監視設定を行います
そのため、アプリケーションから出力するログは、将来的に監視に使用されることを念頭に設計しておくと良いです
アラートが必要でない場面でもERRORレベルで出力してしまったり、レイヤードアーキテクチャを採用している場合、いろんなところでERRORレベルのログを出力してしまい、複数のアラートが発報されてしまったりすることもあるので監視を意識したログ設計をしておく必要があります
バグが少ない
アプリケーションの不具合が多いと、ユーザーの印象が悪くなり、利用してもらえなくなったり、不具合の内容によっては、アプリケーションの継続提供が難しくなる場合もあります
バグを少なくするためには、自動テストなどを用意してCIなどで実行しているケースが多いと思います
自動テストは、共通化できる箇所で切り出し、それに対してテストを書くことで、テストの保守性を高めることができます。詳細は以前のブログを参照してください
このブログでは、自動テストを書いた上で品質を高めるために自分が気をつけているポイントを紹介します
テストも負債
テストコードも負債になり得ます。アプリケーションのコードは、様々なテクニックで冗長的な記述を減らしたり、行数を抑えるようにすることが多いですが、テストは多く書かれることが多い気がします
自分が関わったプロジェクトでも元のコードの 1.5 〜 3倍くらいは書くことが多く、AIを使うようになって、テストを書くのが容易になってさらにこの傾向は強くなってると感じてます
テストが多くなってくると、テストを通すこと自体が目的になり、元の目的を見失ったりすることがあります
テーブル駆動テストなどを駆使して、多くのパターンを少ない記述でテストできるようにする
共通的な処理はヘルパー関数等を用意し、何度も同じ記述を書くのを防ぐ
レイヤードアーキテクチャを採用している場合、各レイヤー間で何を保証すべきかを明確にする。レイヤーが分かれていると、同じようなテストが様々なレイヤーで行われ、テストが肥大しがちです
実際に動かさないとわからない
自動テストが充実してくると、自動テストが通っただけで、動作確認完了としてしまいたくなります
しかし、自動テストはあくまで開発者やAIが局所的に考えた想定ケースを保証するだけで、アプリケーション全体としてはうまく動作しないということは度々起こります
また、AIが生成したコードがテストを通すことを優先してしまい、テストの意図が損なわれることがあります
そのため、実際にアプリケーションを動かして手動で動作確認することは大事です
パフォーマンス
アプリケーションの動作が遅いと、ユーザーの離脱につながったり、悪い印象を与えてしまうことがあります。また、パフォーマンスが悪いと、それだけコストが余分にかかってしまうこともあります。
パフォーマンスを悪くしないために筆者が気をつけていることをご紹介します
基本的なアルゴリズムを知る
基本的なアルゴリズムを知っておくと、ボトルネックを解消するのに役立つことがあります。データベースにインデックスに使われるB-TreeやHashのアルゴリズムの特性を知っておくと、そのデータベースが何が得意で、何が不得意かのイメージをつけることができます
また、計算量のイメージを持っておくと、いざ N (データ量)が増えた場合に、ボトルネックになりやすい処理の当たりがつきやすくなります
まとめ
今回は筆者がアプリケーションの品質を高めるために実践してることを書かせていただきました。
この記事が誰かの参考になれば幸いです
