システム開発

本番環境(プロダクション環境)へのデプロイをスムーズにする方法  (パート2)

本番環境のデプロイをスムーズにするために注意すべきことがあります。

例えばバックアップや自動展開ツールを使用するなど…。

この記事ではそんな本番環境へのデプロイをスムーズにする方法について解説していきます。

  • PHPを使って構築をしたい方
  • Webサイト構築の具体的な手法が知りたい方

これらに当てはまる方におすすめの記事となっています。この記事を読めば、ソフトウエア開発の際に本番環境のデプロイで苦労することが無くなりますよ。

ちなみに、準備編に関してはこちらの記事で解説をしています。

展開する前にバックアップすることを心がけましょう

コードを本番環境に展開する中に何が起こり得るかを100%予測することはできません。本番のデータを失ったら、顧客からの契約が取り消し、訴えられるまで追い込む会社があります。

リスクを防ぐためには、新しいコードバージョンをデプロイする前にすべてをバックアップすることを習慣にしてください。

また、バックアップ中にユーザーがデータを生成しないように、バックアップする前に保持モードに切り替えることを忘れないでください。

維持モードになりたくない場合は、ゼロダウンタイムという方法も選択肢の一つになります。

バックアップが完了したら、バックアップファイルを安全な箇所を保存してください。さらに、火災・サーバーの障害・サーバーの攻撃などの対処法として、定期的なシステムバックアップをすることもお勧めします。

しっかり調べてから、環境を準備する

展開される環境を把握しましょう

MacOSまたはWindowsでのアプリケーションの開発は一般ですが、運営環境(本番環境)はBSDやLinuxなどの別のOSである可能性があります。カーネルからユーティリティソフトウェアまで、さまざまなものがあります。

本番環境を把握すると、アプリケーションの実行時にデバッグが容易になります。

本番環境を実行するために仮想サーバー(VPS)を使用している場合は、ホスティングソフトウェアがインストールされていると簡単ですが、ソフトウェアバージョンの選択、互換性などはややこしい問題になってしまいます。

数年前、本番環境へのアプリケーションのデプロイは複雑でした。

環境は仮想化(仮想化)またはコンテナー化(コンテナー化)されていないため、ソフトウェアバージョンとの非互換性がある可能性が非常に高くなります。

アプリケーションをデプロイする前に、それらの使用方法と操作方法を把握しなければなりません。 AWSのプラットフォームで運用するための証明書を持っているのはそのためです。

すべての卵を一つのカゴに入れるな

ステムを1台のサーバーのみで実行することは、すべての卵を一つのカゴに入れるようなものです。何かのきっかけで急にサーバーが障害が発生してしまうとシステム全体が利用できなくなってしまいますね。この現象は「単一障害点」と呼びます。

この問題を解決するために、サーバー負荷分散技術を利用します。代表的ものとしては、ロードバランサー、キープアライブ、クラスタリング、レプリケーションなど。

システムの各部分は個別にスケーリングされます。たとえば、AWSを使用する場合、RDSと呼ばれるMySQLを実行するための別のサービスを購入できます。

このサービスを使用すると、MySQLを別のサーバーで実行でき、定期的なバックアップサポートできます。さらに、世界中のCDNを使用でき、アプリケーションシステム(PHP、Nodejs、Nginx … )と独立的にスケールアップできます。

同様のサービスを購入してインストールすることはできますが、MySQLをできるだけ迅速にスケーリングする場合は少し難しくなります。

開発環境と本番環境の同期をしないで

「開発環境と実環境は同期すべきだ」という説を多くの人が信じていますが、これは必ずしも正しいとは限りません。

開発・テスト・および本番環境は常に異なるので、 考慮しないままで同期すると問題が発生する恐れがあるからです。

たとえば、Dockerを使用してシステムをデプロイする場合、イメージに多数のツールとライブラリがインストールされていることがわかります。 本番環境で実行する場合、これらは実際には必要ありません。スペースを浪費し、それらをビルドしようとすると、デプロイプロセスでエラーが発生してしまいます。

ソースコードをパッケージ化する。 (ビルドアーティファクト)

PHPでは、ライブラリとクラスをソースコードにインストールして、ソースコードをパックします。ベンダーディレクトリもソースコードに従ってパッケージ化されていることを確認してください。本番環境にコードが展開されたら、それ以上何もインストールしません。

これは、エラーの原因となる間違ったバージョンの更新を回避するのに役立ちます。また、展開するたびにライブラリを再インストールする必要がないため、展開を迅速化するのに役立ちます。

サーバーに外部インターネット接続がない場合にも役立ちます。 CI / CDを使用している場合は、AntやPhingなどのビルドツールを使用して、パッケージをしてみてください。より高速になります。

パッケージ化されたソースコードをストレージツールに転送します。(Ship/transform artifact)

コンテナー技術を使用することで、コードをイメージに直接パックし、それをレジストリーに転送することができます(ソースコードを保護するために非公開にする必要があることに注意してください)。

バージョニングもサポートしているため、アプリケーションバージョンにデプロイする必要があるイメージを選択できます。

たとえば、WordPressはコンテナ化されたPHPソースコードです。「docker pull wordpress」を使用して最新バージョンのWordPressをダウンロードし、ややこしいインストールを行わなくてもすぐに実行できます。

小さく軽量なイメージを使用して、本番環境で実行しましょう。 たとえば、ubuntuの代わりに、Alpine linuxを使用するなど。 これにより、画像のサイズが数百MBから数十MBに縮小されます。 これは、迅速に展開するのにも役立ちます。

本番イメージでは、ソースコードの実行できるための必要なアプリケーションのみをインストールしてください。なぜかというと、各アプリケーションのインストール ことでイメージサイズが大きくなるためです。たとえば、PHPを実行する場合、php-fpmをインストールするだけで十分だ。composer・wget・aptなどのインストールは必要ありません。

パッケージ化されたソースコードを実行します。 (アーティファクトを実行)

それでは、パッケージ化されたソースコードを実行してみましょう。実装コマンド:

docker pull <イメージ名>

docker run <イメージ名>

分散環境におけるコンテナーの運用管理の場合はDocker Swarm、Kubernetesなどのコンテナーマネージャーツールをお勧めです。

システムの制限を把握しましょう

システムの制限ことが気にしない人はほとんどいないと思います。おそらく大規模なシステムで作業したことがないためか、そうしたとしても、「サーバーはCoderよりも安い」とよく言われるためです。

ただし、システムの制限を理解することは、システムのスケーリングを考慮するまでに、新しい機能を展開するときにサーバーの負荷容量を事前に計算するのに役立ちます。

たとえば、PHPプロセスは最大25MBのサーバーRAMを使用して作成されました。各リクエストは200msで行われるため、1秒で1つのプロセスが5つのリクエストを同時に処理できます。サーバーの2GB RAM = 2048MBの場合、システムはオペレーティングシステムと他のソフトウェアに512MBを使用すると想定としたら、残り1536MBが最大62のプロセスを作成できます。

したがって、平均して、5×62 = 310リクエスト/秒を処​​理できます。この数に驚かれる方も多いと思います。それはあなたが想像しているよりも少し少ないと思うでしょう。

上記の例から、下記の二つことを心がけましょう

  • リクエストの処理速度が速い場合、処理されるリクエストの数は多くなります。
  • いくつかの簡単な計算を通じてシステムの限界を知ることで、本番環境に展開する前にアプリケーションのパフォーマンスを測定できます。

注意:PHPが占有するプロセス数とメモリを設定できるので、最適なパフォーマンスを達成するには、リソースの不足や冗長を回避するために事前に計算してください。

上記の例には、ただRAMパラメータのみの計算方法です。CPU、ネットワーク、ディスクI / Oなど、他にも多くのパラメーターも慎重かつ詳細に計算する必要があります。

自動展開ツールを使用しましょう

自動展開ツールを選択するときは、次のような条件を考慮する必要があります。

  • ビルドツールとビルドプロセスをサポートできるか。
  • 自動化と手動展開をサポートできるか。
  • ロールバック戦略をサポートできるか。

PHPには、GitlabCI、Jenskin、Deployerなど、使用できます。

展開するときにチーム全員が待機することを確保する

システムを展開するときに誰かのコードのせいでエラーが発生場合、この人が現場にいないと危険です。プロジェクトを把握し、展開中および展開後に発生する問題を対応できる人がいることを確認してください。

まとめ

この記事では、本番環境(プロダクション環境)へのデプロイをスムーズにする方法として、4つの注意するべきことを紹介していきました。

  • 展開する前にバックアップをする
  • しっかり調べてから、環境を準備する
  • 自動展開ツールを使用しましょう
  • 展開するときにチーム全員が待機することを確保する

これらに気をつけてデプロイを行っていきましょう。


PHPの開発を外注してみるのはいかがでしょうか。 dehaソリューションズではオフショア開発によって低コストで迅速な開発をサポートしています。

PHP開発に関して詳しくお話を聞きたい方、無料お見積りをしたい方はこちらからご気軽にお問い合わせください。

▼ dehaソリューションへの簡単見積もりの依頼はこちら

Van Nguyen

Recent Posts

AI導入58%でも成果は“内向き”止まり|『DX動向2026』が示すレガシーマイグレーションの優先順位

AIや生成AIの導入が急速に進んでいます。しかし、「AIを導入した企業が、そのまま企業価値を高められているか」という問いに対しては、まだ明確に「Yes」とはいえません。 独立行政法人情報処理推進機構(IPA)が2026年7月に公表した「DX動向2026」では、日本企業のAI導入・試験利用が58.0%に達したことが明らかになりました。AI活用そのものは、もはや一部の先進企業だけの取り組みではありません。 一方で、AIによって得られた成果を見ると、「業務が効率化したり迅速化した」が91.6%であるのに対し、「顧客満足度が向上した」は4.5%、「売上や利益が向上した」はわずか3.9%にとどまっています。 つまり、AI導入は進んでいるものの、その成果はまだ「社内の効率化」という内向きの領域に集中しているのです。 この状況を変えるために重要になるのが、AIツールを増やすことだけではありません。AIが企業の中核業務や顧客接点、データ活用まで入り込めるよう、既存システムそのものを見直すことが必要です。 この記事では「DX動向2026」のデータを読み解きながら、AI活用を企業価値創出につなげるために、なぜレガシーマイグレーションが重要なのか、そしてどのシステムから刷新すべきなのかを解説します。 レガシーマイグレーションについて知りたい方 AIを活用したい方 これらに当てはまる方におすすめの記事となっています。これを読めばレガシーマイグレーションの特徴が丸わかりですよ。 (more…)

5 days ago

【2026年版】モダナイゼーション×AI:成功へ導く戦略と失敗しないための注意点

「レガシーシステムを刷新したいが、コストや移行リスクが不安」「生成AIをシステム刷新に活用したい」と考える企業が増えています。 2026年は、生成AIを活用して既存システムの解析やコード変換、ドキュメント作成、テストなどを効率化する「モダナイゼーション×AI」が注目されています。 この記事では、AIを活用したモダナイゼーションのメリットや成功のための戦略、失敗を防ぐための注意点について詳しく解説します。 モダナイゼーションが気になる方 モダナイゼーションとAIをどう組み合わせればいいのかわからない方 業務にAIを活用していきたい方 これらに当てはまる方におすすめの記事となっています。これを読めばモダナイゼーションとAIの活用方法やポイントが丸わかりですよ。 (more…)

2 weeks ago

AIで加速するモダナイゼーション:レガシーシステム刷新の手順と活用事例

多くの企業では、長年にわたって利用してきた基幹システムや業務システムが、現在も重要な役割を担っています。 一方で、こうした「レガシーシステム」は、技術の老朽化や複雑化、保守人材の不足、外部サービスとの連携の難しさなど、さまざまな課題を抱えています。 こうした状況を受け、企業ではシステムを単純に新しくする「リプレース」だけではなく、クラウドやAPI、データ分析基盤などを活用して、IT環境そのものを現代のビジネスに適した形へ変える「モダナイゼーション」が進んでいます。 本日はそんなモダナイゼーションについて、具体的な手順や活用事例を踏まえて解説していきます。 モダナイゼーションが気になる方 社内のIT人材が不足している方 レガシーシステムの刷新をしたい方 これらに当てはまる方におすすめの記事となっています。これを読めばモダナイゼーションについてわかるのはもちろん、レガシーシステム刷新の具体的な手順まで丸わかりですよ。 (more…)

2 weeks ago

DXの現状:「守りの効率化」から「攻めの価値創出」へ

〜IPA『DX動向2026』から読み解く、日本企業のリアルな課題と本質〜 はじめに:69ページの報告書が突きつける問い 独立行政法人情報処理推進機構(IPA)が発表した最新の調査資料『DX動向2026』(有効回答数:1,799社)。本レポートを精読する中で、最も印象的かつ示唆に富んでいたのは、次の現実でした。 「コストを削減することは、新たな売上を生み出すことよりもはるかに容易である」 日本においてDXへの取り組み率は75.7%に達し、過去数年間にわたり高水準で推移しています。もはや「DXに取り組むべきか否か」という議論のフェーズは完全に過去のものとなりました。しかし、その取り組みの内実をデータで精査すると、多くの企業が直面している構造的な課題が浮かび上がってきます。 1. 「守りのDX」の成功と、「攻めのDX」の停滞 DXに取り組んでいる企業のうち、60.8%が「何らかの成果が出ている」と回答しています。しかし、その「成果」の内訳には顕著な偏りが見られます。 業務効率化・コスト削減の成果:70.9% 新規事業創出・売上拡大の成果:わずか17.9% ペーパーレス化や社内業務のデジタル化といった、既存プロセスの効率化(いわゆる「守りのDX」)は順調に進展しています。しかし、製品・サービスの変革やビジネスモデル自体の刷新といった、事業価値を拡張する「攻めのDX」で具体的な成果を上げている企業は2割にも満たないのが現状です。 効率化によるコスト削減はDXの重要な足がかりですが、それ自体がゴールではありません。真の変革は、効率化によって生み出された余力を「新たな事業機会の創出」へ再投資することで初めて達成されます。 2. 投資拡大の裏にある「投資対効果(ROI)の不可視性」 レポートが示すもう一つの注目すべきデータは、投資と効果測定のギャップです。…

3 weeks ago

モダナイゼーションとは?DXとの違いやAIを活用した業務システムの刷新手法・手順を徹底解説

企業の業務を支える基幹システムや業務システムは、長年にわたって使い続けることで、企業独自の業務ノウハウが蓄積される一方、システムの老朽化や複雑化が進みやすくなります。 「古いシステムを刷新したいが、業務を止めることはできない」「既存システムに詳しい担当者が退職し、保守が難しくなっている」「DXを推進したいものの、既存システムが足かせになっている」といった課題を抱える企業も少なくありません。 こうした問題を解決するための重要な取り組みが「モダナイゼーション」です。 モダナイゼーションは、単純に古いシステムを新しいものへ置き換えるだけではありません。既存システムが持つデータや業務ロジック、ノウハウを活かしながら、現在のビジネス環境に適したIT基盤へと刷新していく考え方です。 この記事では、モダナイゼーションの基本的な意味からDXとの違い、代表的な刷新手法、AIを活用した進め方、実施手順、成功させるためのポイントまで詳しく解説します。 モダナイゼーションについて知りたい方 古いシステムを刷新したい方 DX化をすすめたい方 これらに当てはまる方におすすめの記事となっています。これを読めばモダナイゼーションについてわかるのはもちろん、DX化との違いまで丸わかりですよ。 (more…)

3 weeks ago

AI活用で業務効率化へ:2026年度IT導入補助金のスケジュールと活用法

「AIを業務に取り入れたいけれど、導入コストが気になる」「どのようなAIツールを選べばよいのかわからない」「補助金を使ってDXを進めたい」――このような悩みを抱える中小企業・小規模事業者は少なくありません。 そこで活用を検討したいのが、2026年度の「デジタル化・AI導入補助金」です。 従来の「IT導入補助金」から名称が変更され、2026年度はAI活用を含むデジタル化をより意識した制度となっています。 業務効率化や生産性向上につながるITツールの導入費用を支援することで、中小企業のDXを後押しする制度です。 この記事では、2026年度のデジタル化・AI導入補助金について、制度の概要から申請スケジュール、AI活用の具体例、申請時の注意点までをわかりやすく解説します。 AI導入を検討している方 IT導入補助金を申請したい方 これらに当てはまる方におすすめの記事となっています。これを読めば2026年度の「デジタル化・AI導入補助金」の詳細がわかるだけでなく、具体的な申請方法も丸わかりですよ。 (more…)

4 weeks ago