Docker コンテナにデータベースをデプロイする場合の欠点は何ですか?

序文

Docker は過去 2 年間で非常に人気が高まっています。開発者はすべてのアプリケーションとソフトウェアを Docker コンテナにデプロイすることに熱心ですが、データベースもコンテナにデプロイするつもりですか?

この問題は根拠のないものではありません。インターネット上にはさまざまな操作マニュアルやビデオチュートリアルが多数見つかります。編集者は、データベースがコンテナ化に適さない理由をいくつかまとめましたので、ご参考ください。同時に、データベースを使用する際は、皆さんがより慎重になることを願っています。

今のところ、データベースをコンテナ化するのは非常に無理がありますが、開発者全員がコンテナ化の利点を味わっていると思います。技術の発展とともに、より完璧なソリューションが生まれることを願っています。

Docker がデータベースのデプロイメントに適さない 7 つの理由

1. データセキュリティの問題

コンテナ内にデータを保存しないでください。これは Docker コンテナの公式使用ヒントの 1 つでもあります。コンテナはいつでも停止または削除できます。コンテナが rm されると、コンテナ内のデータは失われます。データの損失を防ぐために、ユーザーはデータ ボリューム マウントを使用してデータを保存できます。ただし、コンテナ ボリュームの設計は永続的なストレージを提供するために Union FS イメージ レイヤーに基づいており、データのセキュリティは保証されません。コンテナが突然クラッシュし、データベースが適切にシャットダウンされない場合、データが破損する可能性があります。さらに、コンテナ内のデータ ボリューム グループを共有すると、物理マシンのハードウェアに重大な損傷が発生する可能性があります。

Docker データをホストに保存したとしても、データが失われないことは保証されません。 Docker ボリュームは、Union FS イメージ レイヤーに永続的なストレージを提供するように設計されていますが、まだ保証がありません。

現在のストレージ ドライバーでは、Docker は依然として信頼性が低いというリスクがあります。コンテナがクラッシュし、データベースが適切に閉じられていない場合、データが破損する可能性があります。

2. パフォーマンスの問題

ご存知のとおり、MySQL は IO 要件が高いリレーショナル データベースです。物理マシンで複数のインスタンスを実行すると、IO が蓄積され、IO ボトルネックが発生し、MySQL の読み取りおよび書き込みパフォーマンスが大幅に低下します。

Docker の使用に関する 10 大問題点に関する特別セッションで、ある国営銀行のアーキテクトが次のように述べました。「データベースのパフォーマンスのボトルネックは通常、IO で発生します。Docker の考え方に従うと、最終的には複数の Docker IO 要求がストレージ上に現れます。現在、インターネット上のほとんどのデータベースは共有なしのアーキテクチャに基づいており、これが Docker への移行を検討しない要因となっている可能性があります。」

学生によっては、パフォーマンスの問題に対する対応する解決策を持っている場合もあります。

（１）データベースプログラムとデータの分離

Docker を使用して MySQL を実行する場合は、データベース プログラムとデータを分離し、データを共有ストレージに保存し、プログラムをコンテナーに配置する必要があります。コンテナ内で例外が発生した場合や、MySQL サービスに異常が発生した場合は、新しいコンテナが自動的に起動されます。また、ホストマシンにデータを保存しないことを推奨します。ホストマシンとコンテナはボリュームグループを共有するため、ホストマシンへのダメージが大きくなります。

（２）軽量データベースや分散データベースの実行

Docker で軽量データベースまたは分散データベースをデプロイする場合、Docker 自体は、コンテナ サービスを再起動するのではなく、サービスを終了して新しいコンテナを自動的に起動することを推奨しています。

（３）アプリケーションの合理的なレイアウト

IO 要件が高いアプリケーションやサービスの場合、データベースを物理マシンまたは KVM に展開する方が適切です。現在、TX Cloud の TDSQL と Alibaba の Oceanbase は、Docker ではなく物理マシンに直接デプロイされています。

3. ネットワークの問題

Docker ネットワークを理解するには、ネットワーク仮想化についてしっかりと理解している必要があります。予期しない状況に対処する準備も必要です。サポートや追加ツールなしでバグ修正を行う必要がある場合があります。

より高い負荷を実現するには、データベースに専用の持続的なスループットが必要であることはわかっています。また、コンテナはハイパーバイザーとホスト仮想マシンの背後にある分離レイヤーであることもわかっています。ただし、データベースのレプリケーションにはネットワークが不可欠であり、マスター データベースとスレーブ データベース間の 24 時間 365 日の安定した接続が必要です。未解決の Docker ネットワークの問題は、バージョン 1.9 でも未解決のままです。

これらの問題をまとめると、コンテナ化によりデータベース コンテナの管理が困難になります。あなたはトップクラスのエンジニアであり、どんな問題も解決できると私は知っています。しかし、Docker ネットワークの問題のトラブルシューティングにどれくらいの時間を費やしていますか?データベースを専用の環境に置いた方が良いのではないでしょうか?本当に重要なビジネス目標に集中するための時間を確保します。

4. ステータス

ステートレス サービスを Docker にパッケージ化してコンテナをオーケストレーションし、単一障害点の問題を解決するのは便利です。しかし、データベースはどうでしょうか?データベースを同じ環境に置くと、データベースはステートフルになり、システム障害の範囲が広がります。次にアプリケーション インスタンスまたはアプリケーションがクラッシュすると、データベースに影響が及ぶ可能性があります。

知識ポイント: Docker では、水平スケーリングはステートレス コンピューティング サービスにのみ使用でき、データベースには使用できません。

Docker の急速な拡張の重要な特徴は、ステートレスであることです。データ状態を持つものは、Docker に直接配置するのに適していません。データベースを Docker にインストールする場合は、ストレージ サービスを別途提供する必要があります。

現在、TX Cloud の TDSQL (金融分散データベース) と Alibaba Cloud の Oceanbase (分散データベース システム) は、どちらも管理が容易な Docker ではなく、物理マシン上で直接実行されています。

5. リソースの分離

リソースの分離という点では、Docker は仮想マシン KVM ほど優れていません。Docker は Cgroup を使用してリソース制限を実装しますが、リソース消費の最大値を制限することしかできず、他のプログラムが独自のリソースを占有するのを分離することはできません。他のアプリケーションが物理マシンのリソースを過度に占有すると、コンテナ内の MySQL の読み取りおよび書き込み効率に影響します。

必要な分離レベルが増えるほど、発生するリソースのオーバーヘッドも大きくなります。専用環境と比較して、水平スケーリングが容易なことが Docker の大きな利点です。ただし、Docker では、水平スケーリングはステートレス コンピューティング サービスにのみ使用でき、データベースには使用できません。

データベースの分離機能が見当たらないので、なぜコンテナに配置する必要があるのでしょうか?

6. クラウドプラットフォームの適用性の欠如

ほとんどの人はパブリック クラウドを通じてプロジェクトを開始します。クラウドにより、仮想マシンの操作と置き換えの複雑さが簡素化されるため、新しいハードウェア環境をテストするために夜間や週末に人的労力を費やす必要がなくなります。インスタンスをすぐに起動できるのに、インスタンスが実行される環境について心配する必要があるのはなぜでしょうか?

だからこそ、私たちはクラウドプロバイダーに多額の費用を支払っているのです。インスタンスにデータベース コンテナを配置すると、上記の利便性はなくなります。データが一致しないため、新しいインスタンスは既存のインスタンスと互換性がありません。インスタンスを単一マシン サービスの使用に制限する場合は、DB にコンテナ化されていない環境を使用する必要があります。コンピューティング サービス層を弾力的に拡張する機能のみを保持する必要があります。

7. データベースを実行するための環境要件

DBMS コンテナが他のサービスと同じホスト上で実行されるのはよくあることです。ただし、これらのサービスのハードウェア要件は大きく異なります。

データベース (特にリレーショナル データベース) には高い IO 要件があります。一般的なデータベース エンジンは、同時リソースの競合を回避するために専用の環境を使用します。データベースをコンテナに配置すると、プロジェクトのリソースが無駄になります。インスタンスに多くの追加リソースを構成する必要があるためです。パブリック クラウドでは、34G のメモリが必要な場合、起動するインスタンスには 64G のメモリが必要です。実際には、これらのリソースは十分に活用されていません。

どうすれば解決できるでしょうか?レイヤーで設計し、固定リソースを使用して異なるレイヤーの複数のインスタンスを起動できます。水平方向にスケーリングする方が垂直方向にスケーリングするよりも常に優れています。

要約する

上記の質問に対する回答として、データベースをコンテナにデプロイしてはならないという意味でしょうか?

答えは「いいえ」です

データ損失を気にしなくてよい業務（検索、追跡ポイント）をデジタル化し、データベースシャーディングでインスタンス数を増やすことでスループットを向上させることができます。

Docker は軽量または分散データベースの実行に適しています。Docker サービスがクラッシュすると、コンテナ サービスを再起動する代わりに、新しいコンテナが自動的に起動されます。

データベースは、ミドルウェアとコンテナ化されたシステムを使用して、自動的にスケーリング、災害からの回復、切り替え、複数のノードを備えています。コンテナ化することもできます。

上記は、Docker コンテナにデータベースをデプロイする際の欠陥の詳細な内容です。Docker がデータベースのデプロイに適していない理由の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。