外部サービスの処理時間を把握せよ

続いて紹介されたのが、「サードパーティコンテンツ」だ。

矢落氏は、「ページ読み込み時間のうち、サービス提供者がコントロールできるのは3分の1程度」という調査結果を提示。残りの3分の2は、外部サービスとの連携処理になるという事実を明かした。

にもかかわらず、外部サービスのパフォーマンスを意識する管理者/開発者は少ない。そのうえ、自分達の責任ではないと考えている節があり、外部サービスによる遅延時間を把握していない企業が多いという。

矢落氏は、「ユーザーからすると、外部サービスも含めたすべての処理がWebアプリケーション提供者の責任という認識」と意識改革を促したうえで、「今風に言うならば、外部サービスに関しても、パフォーマンスを"Under The Control"に置く必要がある。APIの使い方が悪いのか、外部サービスが一時的に遅くなっているのか、外部サービスに致命的なトラブルが発生しているのか、まで把握できるようにしなければならない」と警鐘を鳴らした。

あるBlogサイトでは30以上の外部サービスと連携。読み込み時間の3分の2は、外部サービスの呼び出しに費やしているという調査結果も

トランザクションあたりのDBコールは想定外の数に

矢落氏が挙げた3つ目の問題は「DBコール」。

DB周りはパフォーマンスチューニングのポイントとして挙げられることが多いが、それでもなお無闇矢鱈にDBコールを実装する開発者は少なくないという。また、O/R Mapperなどの利用によりSQLを書かずにDBにアクセスするケースが増え、開発者の意図しない形でDBコールが発生しているケースも多い。

「1つ1つの処理は10ms、100ms程度なのでわかりづらいが、ボディブローのように効いてくる。まとまった数になると、大きな問題になってくる」(矢落氏)

矢落氏によると、DBコールが問題になるケースは大きく4つある。まず、必要以上のデータをリクエストするケース。続いて、同じデータを複数回リクエストするケース。さらに、複数のクエリーでデータセットを得るケース。そして、フレームワークのキャッシングに問題があるケースである。

なかでも2つ目、3つ目に当てはまるケースは多いという。

「現場に検証しに行くと、1トランザクションあたり100回のDBコールがあるというのはざらにある。なかにはログイン処理で1000を超えたものもあった」(矢落氏)

こうした事態を防ぐうえでは、「メソッドあたりで測るのではなく、トランザクションあたりで測ることが大切」(矢落氏)という。また、「遅いときだけ調査してもわからないことが多いので、全トランザクションをモニタリングし、SQLの実行回数が増えてきたことが視覚的にわかるようにてほしい。改善策を検討する際には、ユーザー視点に立って、できるだけ上流からアーキテクチャを検証するべき」とアドバイスした。

あるeコーマスサイトでは、ログイン処理で1020回ものDBコールがあった

高負荷時のみ発生する「同期待ち」

矢落氏が最後に紹介したのが「不適切な同期」である。

マルチスレッド処理においては、オブジェクトの排他処理により同期待ちに陥るケースが少なくない。特にフレームワーク側の制御で発生することが多いようだ。

厄介なのは、この問題が「高負荷時に限り発生するものがほとんど」(矢落氏)という点。そのためテスト環境では表れず、本番稼働に至って初めて発覚することが少なくないという。

テスト環境で発見するには、負荷テストが必須。また、発見しても、同期待ちの根本原因となる呼び出し元コードを特定するのは大変であるため、問題発生個所からコードをドリルダウンできる環境が必要という。

矢落氏は、「マルチスレッドプログラミングのベストプラクティスを解説する書籍やWebサイトがあるので、そういったノウハウを参考に、設計時から同期の必要性と範囲を検討してほしい」とアドバイスを送った。

同期待ちは高負荷環境でのみ発生するケースがほとんど。テスト環境で見逃してしまうケースが多い

*　　*　　*

講演の最後に矢落氏は、「アーキテクチャが複雑化する中で『Application Performance Management(アプリケーションパフォーマンス管理)』を実現するためには一気通貫の性能測定ツールが必須」と説明。

「ユーザーが体感する処理時間を把握したうえで、どの処理が遅いのか、どこにアクセスしているのかを明らかにしなければ対策は打てない」とし、パフォーマンスの常時モニタリングやさまざまな粒度で視覚化する仕組みが必要であることを強調し、降壇した。