‫ダジャレです｡
‫最近よく言われるのは､ 「Dを取ることを気にするな」ということです｡ B. PostgresがDockerコンテナで動作している場合､
‫DBをベアメタルで維持した方が良い場合があること､ 特にレプリケーションを使用した場合｡
‫もしあなたが今日､ ベアメタルでDBSを動かしていて､ うまくいっているのなら､ ただクールだからという理由でコンテナライズしているのか､
‫それとも何か必要なものを得るための特定の理由でコンテナライズしているのか､ 自問する必要があります｡
‫そうですね｡
‫データベースはおそらく コンテナで素晴らしく動作します｡
‫また､ 多くのコンテナでデータベースが稼動していることもお伝えしておきます｡
‫私は､ 必要なときにはコンテナでデータベースを動かしています｡
‫私が好むオプションは､ データベースのクラウドホスティングを自分たちだけで利用することです｡
‫つまりオンエアされればw｡ S. とか､ RDXを自社ソリューションに使えるので､ そっちの方がいいなぁ｡
‫クラウドを運営するクラウドエンジニアはDBが得意な日が多いので､ ほとんどの人がDB専任ではないので､
‫自分でデータベースサーバーを運用・保守するのはやめてほしいですし､ 私たちもそうです｡
‫ですから､ 私は常にクラウド上でデータベースを運用することを好んでいます｡
‫というのも､ ほとんどの場合､ 同社のストレージと同社の環境でホスティングした方が､
‫自動的な冗長性､ 優れたログ記録とモニタリングが得られるので､ より安くつくと主張できるからです｡
‫そして､ もしそのすべてを自分で行わなければ､ クラウドストレージそのものよりも高くつくでしょう｡
‫ホスティング自体はベアメタルサーバーより高いかもしれませんが､ 組織にとってはコストがかかりますし､
‫自分ですべてを管理するにもコストがかかります｡
‫だから､ クラウドが苦手とする他のことに時間を割きたいのです｡ クラウドが得意とすることのひとつにデータベースがあります｡
‫つまり､ データベースを運用する場合､ ベアメタル上のデータベースと､ コンテナ内の同じベアメタル上のデータベースでは､
‫性能に差はないのです｡
‫あなたのボリュームが機能する方法には､ ごく稀なケースを除いてはあります｡
‫そして､ データベースのログとボリューム自体を適切に保存している限り､ そしてそのボリュームがベアメタルの場合と同じストレージにあると仮定すれば､
‫ファイルを別の場所に移動すれば明らかにストレージIoが変わるので､ すべてが同じになります｡
‫エミュレーションやディレイ､ コンテナの中にあるシムのような層は存在しません｡
‫ベアメタルで､ ホストOS上で動作しているんですね｡
‫これは自信を持って言えることで､
‫私のDockerリソースページでHP e HPと検索していただければ､
‫数年前にDockerとHewlett-Packard
‫HP Hewlett-Packard Enterprise（以下HP）のホワイトペーパーがあります｡
‫また､ 3つの異なるシナリオで､ 1つのデータベース､ つまり1つのデータベースエンジンをVMで使用した場合と､ 1つのホストで複数の犠牲者を出した場合のパフォーマンスの続編を作成しました｡
‫そうですね｡
‫どちらが､ 多くの人が使うクラウドモデルなのか｡
‫これは､ 従来のモデル､ つまり､ いくつかのVMと多くのコンテナで､ それぞれ個別の単一インスタンスを実行するモデルです｡
‫つまり､ OSの数は少なくても､ 私の続編のエンジン全体が同じ数であるか､ 同じ数の私の続編のエンジンを仮想化せずにコンテナでベアメタルで動かしているということです｡
‫そうですね｡
‫そこで､ 従来の掃除機からコンテナに移行する際に使用する可能性の高い3種類のモデルを試したところ､
‫間違いなくベアメタルが圧勝しました｡
‫マウスと同じボリュームをいくつ作るかによって､ 8つ以上のOSが必要になる可能性がありましたが､
‫今は1つのOSで済むので､ パフォーマンスの面でも､ 管理の面でも優れています｡
‫また､ 各OSを起動する必要がなく､ OSを何度も起動するためにギガ単位のRAMを使用する必要がないため､
‫スペースやメモリ資源を大幅に節約することができます｡
‫そうですね｡
‫だから､ 効率を考えれば､ 私のベアメタルではずっと良かったんです｡
‫それは､ ベアメタルで動くコンテナです｡
‫もし､ コンテナを使わずにベアメタルでデータベースを動かすとしたら､ 同じOS上で複数のデータベース・エンジンを動かしたくはないでしょう｡
‫そうですね｡
‫つまり､ ベアメタル上でコンテナを使用しない場合､ どちらかの物理マシンの全リソースを必要とすることになるのです｡
‫そうですね｡
‫例えば､ 非常に大きなデータベースがある場合､ あるいは､ 同じベアメタル上に5つの異なるシングルインスタンスを積み重ねることができないため､
‫リソースを十分に活用することができない場合です｡
‫コンテナの利点は､ 同じベアメタルの中で､ 別々のデータベース・エンジンを分離できることです｡
‫そして､ なぜそうしないのか｡
‫私がそうするとき､ もしあなたが非常に金属にアクセスできるのであれば､ あなたはそうすることを望んでいるのです｡
‫ですから､ Postgresをコンテナに入れるのは､ カッコイイからという理由では行いません｡
‫長所と短所をリストアップして､ 長所は孤立していることです｡
‫容器を増やすなど､ いろいろなものを追加することができ､ それらが相反することを心配しなければなりません｡
‫また､ データベースが専用のハードウェアを持ち､ リソースを共有することがないのであれば､
‫コンテナは必要ないかもしれませんね｡
‫今ならいずれ逃げられるかもしれませんね｡
‫あなたが持っているものすべて｡
‫全部コンテナに入れたら､ 他のものも全部コンテナに入れたくなりますよ｡
‫そうですね｡
‫すべての管理ツールでコンテナを探させることになるのです｡
‫そこには賛否両論があるわけです｡
‫そうですね｡
‫私はコンテナランドに突っ込むことはしませんが､ あるOSから何かを取り出して､ そのOS上のコンテナに入れることは､
‫私には通常､ 全くパフォーマンスが変わらないとは言えないことは確かです｡
‫本当に同じOSで同じ処理をしているんです｡
‫ただ､ その周りにセキュリティの境界線があるだけです｡
‫そのため､ リソースへのアクセスが制限され､ マシン上で他のことができなくなる可能性があります｡
‫わかりました｡
‫もし興味があれば､ 私のDockerのページとBrett Fisher dot
‫com slash doctorにあるホワイトペーパーを読んで､ データベースのメンタルパフォーマンスとインパフォーマンスについて読んでみてください｡