コンテナの定義：コンテナは、「実行環境を切り替える際に、ソフトウェアが正常に動作することを保証する方法」という問題を解決するために生まれました。
現在、コンテナとDockerは依然として技術分野で最もホットなキーワードであり、ステートレスなサービスのコンテナ化は大きな流れとなっています。同時に、あるホットな話題が多くの議論を呼んでいます：データベースMySQLはコンテナ化すべきか？
様々な意見を真剣に分析すると、賛成派は単にコンテナの利点という観点からMySQLのコンテナ化を主張しており、その主張を検証するような具体的なビジネスシナリオはほとんどありません。一方、反対派はパフォーマンスやデータセキュリティなど複数の要素からMySQLのコンテナ化は不要と論じ、不適切なビジネスシナリオの例も挙げています。それでは、DockerでMySQLを実行すべきでないN個の理由について話しましょう。
データセキュリティの問題
データをコンテナ内に保存しないこと。これはDocker公式のコンテナ利用のヒントの一つでもあります。コンテナはいつでも停止・削除できます。コンテナがrmされると、コンテナ内のデータは失われます。データ損失を防ぐために、データボリュームマウントを使ってデータを保存することができます。しかし、コンテナのVolumes設計はUnion FSイメージレイヤー上に永続ストレージを提供するものであり、データセキュリティの保証が不十分です。コンテナが突然クラッシュし、データベースが正常に終了しなかった場合、データが破損する可能性があります。また、コンテナ内でデータボリュームグループを共有すると、物理マシンへのハードウェア損傷も大きくなります。
パフォーマンスの問題
ご存知のように、MySQLはリレーショナルデータベースであり、IOに対する要求が高いです。一台の物理マシンで複数のMySQLを実行すると、IOが累積され、IOボトルネックが発生し、MySQLの読み書きパフォーマンスが大幅に低下します。
あるDocker応用の十大難点に関する専門例会で、某国有銀行のアーキテクトも次のように指摘しました。「データベースのパフォーマンスボトルネックは通常IOに現れます。Dockerの発想に従えば、複数のDockerのIO要求が最終的にストレージに集中することになります。現在のインターネットのデータベースはシェアナッシングアーキテクチャが多く、これもDockerへの移行を検討しない理由の一つかもしれません。」
実際、この問題に対応する戦略もいくつかあります。例えば：
- データベースプログラムとデータの分離
DockerでMySQLを実行する場合、データベースプログラムとデータを分離し、データは共有ストレージに、プログラムはコンテナ内に配置する必要があります。コンテナに異常が発生したりMySQLサービスが異常になった場合、新しいコンテナを自動的に起動します。また、データをホストマシンに保存することは推奨しません。ホストとコンテナでボリュームグループを共有すると、ホストへの損傷が大きくなるためです。
- 軽量または分散データベースの実行
Docker内で軽量または分散データベースをデプロイします。Docker自体、サービスがダウンしたら新しいコンテナを自動起動し、コンテナサービスの再起動を繰り返さないことを推奨しています。
- アプリケーションの適切な配置
IO要求が高いアプリケーションやサービスの場合、データベースは物理マシンやKVMにデプロイする方が適切です。現在、Tencent CloudのTDSQLやAlibabaのOceanBaseは、Dockerではなく物理マシンに直接デプロイされています。
ステートフルの問題
Dockerにおける水平スケーリングは、ステートレスな計算サービスにのみ適用でき、データベースには適用できません。
Dockerの急速な拡張の重要な特徴の一つはステートレスであることです。データ状態を持つものはDocker内に直接配置するのは適していません。Dockerにデータベースをインストールする場合、ストレージサービスは別途提供する必要があります。
現在、Tencent CloudのTDSQL（金融向け分散データベース）やAlibaba CloudのOceanBase（分散データベースシステム）は、管理が容易なDocker上ではなく、物理マシン上で直接実行されています。
リソース分離の面
リソース分離の面では、Dockerは確かに仮想マシンKVMに劣ります。DockerはCgroupを使用してリソースを制限しますが、リソース消費の最大値を制限するだけで、他のプログラムが自分のリソースを占有するのを防ぐことはできません。他のアプリケーションが物理マシンのリソースを過剰に占有すると、コンテナ内のMySQLの読み書き効率に影響を与えます。
必要な分離レベルが多ければ多いほど、得られるリソースオーバーヘッドも増えます。専用環境と比較すると、容易に水平スケーリングできることがDockerの大きな利点です。しかし、Dockerにおける水平スケーリングはステートレスな計算サービスにのみ適用でき、データベースには適しません。
それではMySQLはコンテナ内で実行できないのか？
MySQLも全くコンテナ化できないわけではありません。
データ損失に敏感でない業務（例：ユーザーによる商品検索）では、データベースシャーディングを利用してインスタンス数を増やし、スループットを向上させることができます。
Dockerは軽量または分散データベースの実行に適しています。Dockerサービスがダウンすると、コンテナサービスの再起動を繰り返すのではなく、新しいコンテナが自動的に起動されます。
データベースはミドルウェアとコンテナ化システムを利用して、自動スケーリング、災害復旧、切り替え、複数ノードの組み込みが可能であり、コンテナ化することもできます。
代表的な事例：同程旅行、京東、阿里（Alibaba）のデータベースコンテナ化は良い事例ですので、ご自身でご確認ください。
原文著者：老王谈运维（老王の運用保守談義）
原文リンク：https://www.toutiao.com/i6675622107390411276?wid=1640184427889