リスクと報酬：ソフトウェアコンテナを理解するためのガイド

十分に年をとった私たちの人々は、ソフトウェアが主に物理的なメディアによって配信された日のことを思い出すことができます。 ブロードバンドインターネットとスマートフォンの普及により、ブラウザやアプリなどのユーザークライアントがアクセスするクラウドでホストされるソフトウェアであるWebサービスの時代が到来しました。

少し前までは、Webアプリケーションはプライベートデータセンターの物理マシン上で直接実行されていました。 管理を容易にするために、これらのアプリケーションは通常モノリシックでした。単一の大規模サーバーにすべてのバックエンドコードとデータベースが含まれていました。 現在、Amazonのようなウェブホスティングサービスとハイパーバイザーテクノロジーの普及は、そのすべてを変えました。 アマゾンウェブサービス（AWS）とVirtualBoxのようなツールのおかげで、OS全体を1つのファイルに簡単にパッケージ化できるようになりました。

EC2などのサービスを使用すると、マシンイメージをパッケージ化し、仮想サーバーのセットをつなぎ合わせることが簡単になりました。 マイクロサービスのパラダイムが登場しました。これは、ソフトウェアアーキテクチャへのアプローチであり、大きなモノリシックアプリが、1つのことをうまく行う小さな焦点を絞ったサービスに分割されます。 一般に、このアプローチでは、ボトルネックをすばやく見つけてシステムの変更を特定しやすくなるため、スケーリングと機能開発が容易になります。

家畜へのペット

私はこのトレンドの真っ最中にインフラストラクチャエンジニアになりました。 一連のbashスクリプトを使用して、Amazonで最初の本番環境を構築したことを思い出します。 サーバーは私にとってペットのようでした。 それぞれにかわいい名前を付けました。 私はそれらを注意深く監視しました。 私はアラートに迅速に対応し、それらを健康に保ちました。 愛するペットのように、それらを交換しようとするのは苦痛だったので、私はそれらのインスタンスを愛情を込めて扱いました。

構成管理ツールであるChefが登場し、すぐに私の生活が楽になりました。 ChefやPuppetなどのツールを使用すると、クラウドシステムの管理に関連する手作業の苦痛のほとんどを取り除くことができます。 その「環境」構造を使用して、開発サーバー、ステージングサーバー、および本番サーバーを分離できます。 その「データバッグ」と「ロール」を使用して、構成パラメーターを定義し、変更のセットをプッシュできます。 今、私の「ペット」サーバーはすべて服従学校を卒業していました。

その後、2013年にDockerが登場し、新しい時代が始まりました。家畜としてのソフトウェアの時代です（聴衆のビーガンに謝罪します）。 コンテナーパラダイムは、構成管理ではなく、オーケストレーションの1つです。 Kubernetes、Docker Compose、Marathonなどのツールは、実行中のインスタンスの構成値を調整するのではなく、事前定義されたイメージ内を移動することに重点を置いています。 インフラストラクチャは不変です。 コンテナが故障した場合、私たちはそれを修正しようとはしません。私たちはそれを頭の中で撃ち、交換します。 私たちは個々の動物よりも群れの健康に関心があります。 サーバーにかわいい名前を付けることはもうありません。

報酬

コンテナは多くのことを簡単にします。 彼らは企業に彼ら自身の特別なソースにもっと集中させます。 技術チームは、インフラストラクチャと構成管理について心配する必要がなく、代わりに主にアプリコードについて心配することができます。 企業はさらに一歩進んで、MySQL、Cassandra、Kafka、Redisなどのマネージドサービスを使用して、データレイヤーをまったく処理する必要がないようにすることができます。 企業がインフラストラクチャを気にせずに高度な分析を行えるようにするために、「プラグアンドプレイ」の機械学習サービスを提供するスタートアップもいくつかあります。 これらの傾向は、サーバーレスモデル、つまりチームが単一のVMまたはコンテナーを管理せずにソフトウェアをリリースできるようにするソフトウェアアーキテクチャアプローチに至りました。 S3、Lambda、Kinesis、DynamoなどのAWSサービスがこれを可能にします。 したがって、類推を拡張するために、私たちはペットから家畜、そしてある種のオンデマンドの動物サービスに移行しました。

これはすべてとてもクールです。 12歳の子供が数回クリックするだけで洗練されたソフトウェアシステムを起動できる時代に私たちが住んでいるのはクレイジーです。 少し前までは、これは不可能だったことを覚えておく必要があります。 ほんの数人の米国大統領の前には、物理​​メディアが標準であり、ソフトウェアを製造および配布する手段を持っていたのは大企業だけでした。 バグ修正は贅沢でした。 これで、その12歳の子供は、AWSアカウントを作成して、自分のソフトウェアを全世界で利用できるようにすることができます。 バグがある場合、誰かがSlackで彼にバグを報告し、数分ですべてのユーザーに修正が加えられます。

リスク

非常にクールですが、価格がないわけではありません。Amazonのようなクラウドプロバイダーに依存するということは、大企業や独自のテクノロジーに依存することを意味します。 リチャード・ストールマンとエドワード・スノーデンがあなたにそのようなことを心配させなかったなら、Facebookでの最近の大失敗は確かにそうあるべきです。

ハードウェアからの抽象化が進むと、透明性と制御が低下するリスクも伴います。 何百ものコンテナを実行しているシステムで何かが壊れたとき、私たちは、検出できる場所で障害が発生することを期待する必要があります。 問題がホストオペレーティングシステムまたは基盤となるハードウェアにある場合は、特定が難しい場合があります。 適切なインストルメンテーションがない場合、VMを使用して20分で解決できた可能性のある停止は、コンテナーで解決するのに数時間または数日かかる場合があります。

Dockerのようなものに関して心配する必要があるのは、失敗だけではありません。 セキュリティの問題もあります。 どのコンテナプラットフォームを使用する場合でも、バックドアや非公開のセキュリティの脆弱性がないことを信頼する必要があります。 オープンソースプラットフォームの使用も安全性を保証するものではありません。 システムの一部をサードパーティのコンテナイメージに依存している場合、脆弱になる可能性があります。

要約

家畜のパラダイムは多くの理由で魅力的ですが、欠点がないわけではありません。 スタック全体をコンテナ化するために急ぐ前に、技術チームはそれが正しい選択であるかどうかを考え、悪影響を軽減できることを確認する必要があります。

個人的には、コンテナでの作業が大好きです。 新しいプラットフォームやパラダイムが生まれるにつれ、今後10年間で物事がどこに向かうのかを楽しみにしています。 しかし、元セキュリティコンサルタントとして、私はすべてに代償が伴うことを十分に注意しています。 ユーザーや開発者としての自律性を放棄しないように注意を払うのはエンジニアの責任です。 世界で最も簡単なCD/CIワークフローでさえ、コストに見合う価値はありません。