クイック エンジニアリングブログ

株式会社クイック Web事業企画開発本部のエンジニアリングチームが運営する技術ブログです。

暫定AWS環境からの脱却:IaC再構築によるリプレイスとデプロイの最適化

皆さんこんにちは、システム基盤を日々支えるインフラエンジニアのTOKです。

突然ですが、次のような状況に身に覚えはありませんか?

  • 暫定的な環境で運用を始めたものの、拡張性やパフォーマンスが課題に。
  • プロジェクトの納期が厳しく、理想的な設計を追求する余裕がない。
  • 複雑なアプリケーション構成で、既存のIaC(Infrastructure as Code)ツールでは対応が難しいと感じた。

こうした問題に直面している方に向けて、この記事では私が担当したAWS暫定環境からの脱却事例と、その過程でのIaC再構築、そして運用の最適化について紹介します。 リプレイスの過程で直面した課題をどのように解決し、どんな結果を得られたのか?その詳細をお伝えします。 もし、あなたがインフラ運用やデプロイの効率化に関心があるなら、この経験がきっと役に立つはずです。それでは、具体的なプロセスを見ていきましょう。

1. 暫定的なAWS環境でのリプレイス案件

このリプレイス案件では、暫定的なAWS環境で稼働しているサービスを最終的な環境に移行する必要がありました。 通常は、既存の標準IaCツール(Itamae、Ansible、Jenkins、AWS CLI、GitLab、GitHub、Capistrano)を使用するところですが、このプロジェクトでは新たなIaC基盤の構築が求められており、また、納期が厳しい状況下でした。 そんな中で私が取った手順は以下となります。

初期フェーズにおける課題とその対応

サービス運営チームとの連携を通じて、サービスの特徴や将来的な拡張性を考慮した設計を行うのは一般的ですが、今回のプロジェクトでは納期が最優先でした。 そのため、拡張性や理想的なインフラ構成を追求する余裕がなく、迅速な対応が必要でした。

具体的には、暫定的なAWS環境から本番環境への移行において、まずはシンプルで安定した構成を優先しました。冗長化は後にして、まずは単一サーバー構成でサービスを稼働させることに注力しました。段階的に冗長化やロードバランサーを用いた複数EC2の構成を追加することで、限られたリソースと時間を最大限に活用し、短期間でサービスの安定稼働を実現しました。

新しいベース環境の構築

初期段階ではシングル構成のアーキテクチャを使用し、標準的なIaCをベースにしつつカスタムIaCを作成しました。暫定環境でシングルサーバー構成を採用し、動作が安定した後に、標準的なロードバランサーと複数台のEC2によるラウンドロビンで負荷分散を実現しました。このアプローチは、短期間での安定動作を実現するために合理的な選択でした。

冗長構成の検証

重要だったのは、アプリケーション開発者と密に協力し、冗長構成を理論上検証し、その後実際に動作確認を行うことでした。この確認はシステム全体の安定性を確保するために欠かせませんでしたし、問題なく動作することが実証できたことは、大きな成果と言えます。

ビルドフローのリプレイス

リプレイス作業中に、Amazon Linux 2023への移行時期が重なりました。この際、DockerコンテナのOSバージョンアップやCapistranoのビルド用ライブラリの更新が必要となりました。この点については「追加の工数」と捉えるのではなく、今後のプロジェクト全体に役立つテンプレート作成とリファクタリングの機会と捉え、協力会社と連携して新しいテンプレートを作成しました。その結果、生産性とメンテナンス性の向上を達成できました。

このように、一度に全体を移行するのではなく、小さなステップを踏むことで、プロジェクトの安定性を保ちながらリプレイスを進めました。

2. アプリケーション構成の特殊性によるIaCの再構築

次の課題は、アプリケーションの構成が他のプロジェクトと大きく異なることでした。通常は標準的なデプロイ手法が用いられますが、今回は特殊なデプロイ手順が必要であり、従来のIaCでは対応が難しいことが判明しました。

IaCの見直しと再設計

まず、既存のIaCテンプレートを見直しました。標準的なIaCではこのプロジェクトの要件に適合しない部分が多く、プロジェクト特有のIaCを再設計する必要がありました。この経験から、1つのIaCテンプレートで全てのプロジェクトに対応できるわけではないことを学びました。プロジェクトごとに異なる要件や制約があるため、柔軟性を持たせるためにはモジュール化されたテンプレートの採用が重要です。このアプローチにより、各プロジェクトに合わせたカスタマイズが可能となります。

しかし、今回はプロジェクトのタイムラインに追われ、十分なモジュール化を実現できませんでした。 今後は早い段階からプロジェクト固有の要件を把握し、モジュール化されたアプローチを設計に組み込むことが重要だと感じました。 これにより、将来的なプロジェクトでも効率的かつ柔軟に対応できる基盤を構築できると考えています。

このように、暫定的なAWS環境でのリプレイスや特殊なアプリケーション構成に伴う課題に対して、IaCの再構築やデプロイフローの最適化を行いました。 課題を明確に認識し、段階的な改善を行うことで、安定したサービス提供を実現しました。また、これらの改善は他のプロジェクトでも応用可能です。

以上、少しでも皆さんのお役に立てれば嬉しいです。


\\『真のユーザーファーストでマーケットを創造する』仲間を募集中です!! //

919.jp