支援対象地域:札幌、仙台、関東、愛知、関西、広島、福岡

  • TOP
  •   
  • コラム
  •   
  • 「デプロイ(Deploy)」とは何か

「はじめに」

IT業界に身を置く人、ITの勉強をしている人なら一度は「デプロイ」という言葉を聞いたことがあるのではないでしょうか?デプロイ(Deploy)とは元々英単語で「配置する、展開する」という意味です。IT業界では主に、システムを利用可能な状態にすることを言います。「システムを利用可能な状態にする」とはつまり、開発したアプリケーションの実行ファイルを実際のサーバーにアップロードし、実際に実行=使用できるようにすることです。また、開発以外の一般ユーザーが利用しないテスト環境などに実行ファイルを設置することもデプロイと呼ばれます。

「デプロイはどのタイミングでやるの?」

デプロイは開発したアプリケーションを公開するための「リリース」における工程の一つです。アプリケーションはリリースされて初めて世の中で使われる状態になりますが、そのためにはビルド、デプロイ、リリースという段階を踏む必要があります。これら全ての工程を行うことで、作成されたアプリケーションが公開されるのです。

ビルド

こちらもITに関わる人なら一度は聞いたことのある言葉でしょう。ビルドとはザックリ言えば、デプロイに必要な実行ファイルを作ることです。人間が書くソースコードをコンピューターが理解できる言語に翻訳=コンパイルし、コンパイルされたファイルやデータを適切な形に組み合わせる「リンク」を行うことを言います。ソフトウェアは複数のソースコードファイルが組み合わさっています。そのため、それらを一つに組み合わせるコンパイル+リンクの作業=ビルドが必要なのです。

リリース

恐らくこちらはIT業界以外の人も何の事か想像しやすい言葉ではないでしょうか。リリースとはシステムやアプリケーションを公開し、ユーザーが利用可能な状態にすることを指します。プロジェクトによって異なりますが、リリースとはデプロイを含む様々な手段や段取りをまとめたもののことを指します。

「デプロイの方法には種類がある!?」

無事にデプロイが完了する事において大切なことは

・早い:稼働停止や保守に必要な時間を極力無くす

・確実:デプロイに失敗しない、したとしてもすぐに直せる

・安定:時間や環境などの制約に縛られない

であることです。これらの実現のための具体的な方法をご紹介します。

ブルーグリーンデプロイメント

「ブルー」と呼ぶ現状の本番環境とは別に「グリーン」と呼ぶ新しい別の本番環境を構築し、外部からの通信負荷を分散する装置であるロードバランサーの接続先を切り替えながら新しい本番環境をリリースする運用方法のこと。ブルーと古い本番環境、グリーンを新しい本番環境として、両方の本番環境を同時並行させながら新しい環境でアプリケーションやシステムの変更をする際に、この方法を採用します。これによってシステム全体を稼働停止させたり、保守作業を行う必要がなくなるため、時間の節約と作業の効率化を両立させることが可能です。

イミュータブルデプロイメント

手法としてはブルーグリーンデプロイに似ていますが、イミュータブルデプロイメントではリリース後に旧環境(ブルー)を消去します。稼働中のサーバーと異なる新しい環境に新しいアプリケーションをデプロイしてテスト。問題が発生しなければ新しい環境に切り替えてしまい、旧環境は削除します。巻き戻り処理(ロールバック)をする場合も、新しい環境に古いシステムやアプリケーションをリリースして切り替えます。

シンボリックデプロイメント

複数のサーバに新しいシステムやアプリケーションを配置した後、切り替え予定のアプリケーションのシンボリックリンクを書き換えて切り替えるデプロイの方法です。運用コストと運用サーバーを最低限に押さえ、なおかつデプロイの自動化を行いたい場合に選択されることが多い方式です。

※シンボリックリンク…特定のファイルを指す別のファイルを作成し、それを通じて本体参照できるようにすること。ショートカットのようなもの。

ローリングデプロイメント

一時的に複数の運用環境が並行して動くために注意が必要ですが、大きなロスを生むこと無くバージョンアップを行うことができる手法です。しかし複数のサーバーを接続している場合は、一台ずつ切り離してシステムやアプリケーションのバージョンアップを行い切り戻すため、注意する必要があります。

「デプロイの自動化」

もし、ボタンを押すだけでソフトウェアをテスト環境や本番環境に展開することが出来たら、大変便利なことです。実際、GoogleやAWSなどの企業もデプロイ自動化サービスを提供しております。デプロイを都度、手打ち入力などをしていたらスペルミスなどで予期せぬトラブルに見舞われるかもしれませんし、何より時間がかかります。こういった点を見てみると断然、自動化したほうがメリットが多いように感じますが、自動化するにはいくつかの注意点があります。

既存プロセスが複雑だと自動化後も複雑に…

新規サービスに関しては最初からシンプルな手順のプロセスを組んでいれば問題ないのですが、既存のものに関しては複雑で破綻しやすいプロセスになっていることが多いため、再構築する必要があります。

自動化できない設定

当然のことですが、自動化向けに設定されていないコンポーネントは、ツールの裏にある構成ファイルやデータベースを見つけて直接変更するか、APIのある他のツールで書き換える必要があります。

チーム間の協調性

デプロイの自動化プロセスは、開発者と運用担当者の共同作業で作られる必要があります。この両者間で調和がとれていないと異なる方法でデプロイしてしまうリスクがある他、複数の環境構成が異なる場合、運用担当者が手動で行うデプロイプロセスのリスクが上がり、不整合とエラーの原因になり得ます。

おわりに

いかがでしたでしょうか?私自身、デプロイという言葉は調べ物をする中でよく目にしていましたし、調査の過程で意味を知ってはいました。しかしビルドとデプロイ、リリースの関係は初めて知りましたし、方法も種類があることも初めて知りました。デプロイという言葉は今後IT業界に在籍している内はよく耳にし、目にする言葉ですので、この記事が勉強の一部になってくれたら幸いです。以上、最後までお付き合いいただき、ありがとうございました。