teratailエンジニアの鈴木です。実は11月の終わり頃(11/25)から数週間に渡り、teratailが非常に重く、時にはサーバーからエラーが返ってしまう状況がありました。本件に関して、ユーザーの皆様に多大なご迷惑をおかけすることになり、大変申し訳ございませんでした。今回は、不具合に関してのお詫びと共に、本件への対応として行った、GCPロードバランサを使用する上でのApacheの設定について紹介しようと思います。本件によりサイト上に起こっていた現象としては、以下のようなものが挙げられます。時間に対してある程度一定の割合で、クライアントへ502エラーが返るリクエスト数が変化する昼間と夜間でも、エラー率に変化がないブラウザでは、サーバーからレスポンスが返らず、画面がフリーズする画面がフリーズする現象に関しては、サイトのいくつかの機能のために同期XMLHttpRequest(非推奨)を使用していたことが原因です。対応方法の説明へ入る前に、まずは現在のteratailの構成について簡単に紹介します。Platformへ移行してから、kubernetesを利用した以下のような構成で動いています。GCE上の各Podで、Apacheを含むteratailのコンテナが動作しています。今回起こった不具合の原因は、一言で言うと、GCPロードバランサによるコネクション維持に対して、Apache側のタイムアウトが短すぎるという点にありました。以下の記事で、Nginxにおける同様の事例について詳しく解説されています。BalancerGCPロードバランサを利用することで、クライアントとアプリケーションとのコネクションは、次の2つに分かれます。クライアント-GCPロードバランサ間のコネクションGCPロードバランサ-GCEインスタンス間のコネクション上記の記事によれば、後者のコネクションは、通信の有無にかかわらず10分間程度維持されるようです。このコネクションをGCPロードバランサが再利用しようとした際に、Apacheがコネクションを切断してしまうと、クライアントへ502エラーが返ってしまいます。Apache側でGCPロードバランサとのコネクションを完全に維持するために、KeepAliveを例えば以下のような値に変更しなければなりません。10000ApacheのKeepAliveに関する設定については、クライアントとのコネクションが増えすぎるのを防ぐために、KeepAliveTimeoutを十分短くすべきだ、と言われることが多いように思いますが、GCPロードバランサにおいては事情が異なります。[RPS]未満(コンソール画面で確認不能)まで減らすことができました。最後に繰り返しになりますが、今回の不具合でユーザーの皆様にはご迷惑をおかけし、大変申し訳ありませんでした。今回の場合は、完全なサービス停止ではなくリクエストがたまに失敗するという形だったこともあり、開発チームの認識が遅れ、不安定な状況が長引いてしまいました。今後このようなことがないよう、対策として、エラーをより細かく監視できる仕組みやチームの体制を整えました。継続的な監視と改善を行い、サービスの安定化に努めてまいります。今後ともteratailをよろしくお願いいたします。blog引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。