メニュー

Dockerを使用したデプロイメントにより、複数環境のデプロイにかかる時間を10分の1に削減し、10人のチームにとって2つの運用スタッフのポストを節約することができました。

先月、私たちシンガポールのEコマースSaaSの小規模チームは危機一髪でした。大規模なセールの前に東南アジアの3つのサイトで在庫同期機能を更新しましたが、ローカルでのテストでは問題ありませんでした。ところが、インドネシアのクラウドサーバーにデプロイすると、依存関係のエラーが発生しました。2人のバックエンドエンジニアと1人の運用チームが18時間もかけて問題を解決しましたが、そのせいで3日前に予定していたストレステストが遅れてしまいました。

まずは、Dockerデプロイメントとは何かを理解しましょう。

簡単に言うと、アプリケーションのコード、依存ライブラリ、設定ファイル、さらにはオペレーティングシステムのカーネルパラメータまでをすべて一つの標準的な「コンテナイメージ」にまとめるということです。あなたのローカル環境でどのように動作するかに関わらず、Dockerエンジンがインストールされているどのサーバーでも同じように動作します。単一のイメージは最小で20MBにでき、起動時間は1秒を超えません。。

私たちは3ヶ月間の実際の収益を使用しました。

Shipping containers and cranes at Hamburg port showcasing global trade.

まず、環境の不一致という問題を完全に解決しました。以前は、各サイトに異なるNode.jsのバージョンやデータベースドライバを設定するだけで半日以上かかっていましたが、今ではパッケージ化されたイメージをイメージリポジトリに直接アップロードするだけで、3つのサイトをワンクリックで取得して起動できるようになりました。デプロイにかかる時間は平均4時間から24分に短縮され、大規模なセール前のバージョンアップデートでももう一晩中待つ必要がありません。

次に、サーバリソースの使用率が2倍になります。以前は、各サイトで2コア4Gクラウドサーバーをレンタルしていましたが、アイドル時のCPU使用率は10%未満でしたが、Dockerを使用してアプリケーション、キャッシュ、タイミングタスクを4コア8Gサーバーにプラグインし、リソースは十分です。毎月のサーバーコストが直接620ドル節約されました。10人未満の小規模なチームにとっては、それは小さな数字ではありません。

最後に、拡張速度が突発的なトラフィックに完全に対応できるようになりました。昨年のブラックフライデーでは、臨時でサーバーを追加するのに約2時間かかりましたが、今年はピーク時の10分前に12のコンテナのコピーを立ち上げて、通常のトラフィックの3倍に耐えられました。その後、リクエストのタイムアウトは一度も発生していません。

急いで車に乗らないでください。これらの落とし穴については、もう私たちがあなたのために対処しておきました。

Vibrant red and blue shipping containers under a clear sky, perfect for industrial themes.

最初の穴は、ミラー書き込みが肥大化しすぎることです。最初に、公式のNode jsフル機能イメージパッケージを使用して直接、アプリケーションイメージは1.2Gを持っており、海外のミラーリポジトリに20分以上送信し、その後Alpineベースイメージに切り替え、無駄な依存関係を削除し、最後のイメージは90MBのみで、転送速度は10倍以上高速です。

二つ目の問題は、データがコンテナ内に保存されていたことです。最初は気づかずに、ユーザーがアップロードした商品画像をコンテナのローカルディレクトリにそのまま保存していました。その後、コンテナが再起動したところ、すべての画像が失われてしまい、バックアップから復元するのに1日かかりました。その後、すべての永続化データをサーバーのローカルディレクトリやクラウドストレージに移行したところ、問題は二度と発生しませんでした。

第三の問題は、リソース制限を設けていなかったことです。最初にサービスを開始した際には、コンテナにCPUやメモリの上限を設定していませんでした。ある時、あるサイトのタイマーチェックがバグを起こし、サーバーのCPUを使い果たしてしまい、結果として他の2つのサイトも全てダウンしてしまいました。その後、各コンテナにリソースの上限を設定するようになり、単一のサービスに問題が発生しても全体に影響を与えないようになりました。

Dockerを使うべきかどうか?私たちの判断基準はとてもシンプルです。

使用場面:複数のサーバーに同じアプリケーションをデプロイする必要があり、開発環境、テスト環境、本番環境を頻繁に切り替える必要がある場合、またはチームの規模が3人を超えており、それぞれのメンバーが異なる開発環境を使用している場合に、Dockerを使用すると効率が向上します。

使用Dockerが不適切なケース:もしあなたが小さなブログを運営しており、サーバーも1台だけで、コードの更新も半年に1回しかないのであれば、Dockerを学ぶために時間を費やす必要はありません。宝塔(BaoTa)を使うか、手動でのデプロイの方がずっと簡単でしょう。

初めての方への3つの具体的なアドバイス

Blue and yellow shipping containers aligned on a sandy beach with the ocean and sky in the background.

  • 最初の3回のイメージパッケージングでは、公式のベストプラクティステンプレートを直接検索してください。自分でDockerfileを無闇に書くと、イメージの肥大化や権限エラーの問題の80%を避けることができます。
  • K8sのような複雑なオーケストレーションツールには最初は手を出さず、Docker Composeを使って3つ以下のサービスを管理しても全く問題ありません。
  • ミラーリポジトリはクラウドプロバイダーの海外ノードを使用しましょう。自分で構築する必要はありません。そうすれば節約できた時間で、いくつもの新しい機能を開発することができます。

よくある小さな問題に対する統一的な回答

Q:Dockerはサーバーのパフォーマンスを大幅に消費するのでしょうか?私たちがテストしたところ、パフォーマンスの低下は5%未満で、ほとんどの中小規模のチームにとっては全く感じられません。

質問:以前の古いアプリケーションをDockerに移行できますか?もちろん可能です。3年間運用されていたPHPの古いプロジェクトで、2日間でイメージを作成し、移行が完了しました。新しい環境を構築するよりもずっと早かったです。

役に立ちましたか?

テクニカルサポートオンラインサポート
侧栏
トップへ戻る
简体中文ZH-CNDefault繁體中文ZH-TWEnglishEN日本語JA한국어KOภาษาไทยTHTiếng ViệtVIBahasa IndonesiaIDEspañolESFrançaisFRDeutschDEРусскийRUPortuguêsPTItalianoITالعربيةAR