業務をまだ本格的に始められていないこと創作するネタが思いつかなかったことから、テーマを変えました(すみません)。移行を行った際に直面した性能面の課題と、それを克服するために行ってきたことについて記そうと思います。お堅い業界の会社の話です。サービスを提供していました。本が本番環境)借りて運用していました。外部ストレージで構成。Aurora(MySQL)に移行しました。業務も担っていました(オンコール対応含む)。インフラを担当するメンバーは一部に限られていました。サーバが順番に不安定になりました。※あらかじめ、このような仕組みを仕込んでおいたので、システム全停止には至りませんでした。月には金曜夜から日曜まで週末をまるまる修理対応と復旧作業にあてるような事態も発生しましたので、なるはやで移行せざるをえない状況でした。ネットワーク、特にアベイラビリティ・ゾーン(AZ)間の遅延でした(オンプレより大きくなった)。個しか書いていなかったとしても、実際には数個、下手をすると数十個になることもあります。超える「差」が生まれます。サーバのコネクション/スレッドが埋まり、システムは停止します。使っている場合、フェイルオーバーなどで切れたコネクションのチェックと回収・再接続処理にネットワーク遅延が影響します。アプリケーションの機能に制限を設けてシステム停止だけは回避する更新が少ないデータ(マスタデータなど)についてキャッシュするなどの対応策が考えられます。日目)でも取り上げられています。サーバのローカルキャッシュの利用が考えられますが、ネットワーク遅延が問題になる場合は(容量面の無駄や更新処理への対応の問題がありますが)後者について検討してみると良さそうです。キャッシュオブジェクトを使い、データキャッシュではなく重複リクエストのカウントを行う目的で、以下のようなものを実装しました。置き換えを実施しました。Auroraクラスタへのプーリング接続にHikariCPを使うここまでの対応で、概ねオンプレ時代の性能と比べても遜色がないレベルまで回復しました。インフラまで、必要になった対応策は複数のレイヤにまたがっていますね。計測について特に性能面に課題がある場合、やみくもに原因を推測して対応しても、良い結果が出るとは限りません。原因と有効な対応策を探すには、計測が必要です。移行後にアプリケーション観点の可視化を進めました。業務(と仲間たち?)が降ってきた...というわけで、元々書こうとしていたテーマにつながるわけです。業務を担当するメンバーが発表されました。いうと専任チームのようなイメージがありますが、残念ながら私も含めて全員兼任です。業務にまともに取り組むことができない日々が続きました。過大な負荷を掛ける処理の改善キャッシュの有効利用などを進めています。I/O、キューなどによる緩衝機構なしのアーキテクチャモノリシックで技術的負債が満載のアプリケーション固定的でクラウドフレンドリーでないインフラ構成メンバーの知識が圧倒的に足りていない...などなど、色々と山積みです。メンバーと協力しながら解決していくことになりそうです。Multi-AZ構成におけるネットワーク遅延を考慮して参照クエリを振り分ける(Qiita)(偶然だとは思いますが、関連する話題を提供してくださったようでうれしいです。インフラを中心にいろいろやってます。