コンテナ化について
今回は、コンテナ化についての概略と実際にあるシステムをコンテナ化した時に起きた問題点等を紹介させていただきます。 今回の記事の前提はOpenShiftでの構築を前提としております。
コンテナとは？
コンテナとは端的に説明すると、アプリの動作環境を仮想的に構築する技術の一つです。
そもそもコンテナとは何なのかということを説明するにあたり、仮想化の説明からさせていただきます。
仮想環境になる前の構成では図の左側のようにアプリ一つに対してサーバが一つという造りになっていました。 これでは新しいアプリを作ろうとするとサーバごと増やすことが必要になります。 しかし仮想化をすると一つのサーバの上に仮想ソフトを入れてその上にアプリを立ち上げることができるようになります。 左の図と右の図ではアプリが動いている数は同じなのですが、サーバは一つになります。 仮想ソフトがサーバ上に仮想的な環境を用意することで、複数のアプリを動かせるようになりました。
これにより、それぞれの物理サーバが不要となるため、コスト削減、運用効率化のメリットがあります。
ここからコンテナ化するとどうなるかというのが以下の図となります。
左が仮想環境、右がコンテナ化した場合になります。コンテナ化するとサーバが一つであることは仮想化とは変わりませんが、その上にホストOSが乗っていることが大きな差分です。 仮想環境ではアプリを動かすためにそれに紐づくOSを立ち上げる必要があります。普通にPCを立ち上げる時、シャットダウンをする時などを思い出していただけると分かりやすいと思うのですが、 OSの構築や正常なシャットダウンには時間がかかります。また複数になってくるとOSが使用するリソースもかなり増えてきてしまいます。 しかしコンテナではホストOSが一つでその上で各アプリが動作しているので、アプリを動かすからといってOSを立ち上げる必要は無く、使用リソース量が低減でき、サーバの負荷が減らせます。
コンテナ化の利点
コンテナ化すると使用リソースが低減でき、サーバの負荷を減らせると書きましたが、他にも以下のような利点があります。 ステートレス 時刻同期が不要 APL更新時の作業負荷の低減 異常時の一時措置が不要 柔軟なスケールイン/スケールアウトが可能 コンテナのバックアップが不要
ステートレス
アプリが終了するとデータも消えてしまう。独立しているため負荷を分散することが容易になる。 しかし、顧客情報などを保持するようなアプリをコンテナ化する上ではステートフルな造りにする必要がある。
時刻同期が不要
OpenShiftにはNTPを有効にすることで時刻同期が容易に可能(デフォルトで有効になっていない場合もあるので有効にする手順が必要な場合はある)
APL更新時の作業負荷の低減
仮想環境では資材を一つ一つ展開、更新が必要な場合があります。 しかし、コンテナ化をすると検証環境で検証を行ったコンテナを別環境で展開することのみで更新が可能となります。
異常時の一時措置が不要
異常が起きた場合、自動でセルフヒーリングにより展開されていたPodを自動で再構成されることで異常が起きていなかった状態に戻すことが可能です。 システムによりますが、一時措置相当の対応が自動で行われるためシステムが異常状態でいる期間が短くなります。
柔軟なスケールイン/スケールアウトが可能
仮想環境ではユーザの最大接続数に合わせてサーバの台数を増やすことで対応したり、負荷分散をさせることで対応することが必要になりますが、 コンテナの場合にはユーザからの接続が多くなると自動的にPodを追加したり、逆に接続が少なくなり展開しているPod数が不要であると判断された場合には不要になったPodを減らします。
コンテナのバックアップが不要
柔軟なスケールイン/スケールアウトが可能ということもあり、「バックアップが不要」というよりは「バックアップが不要になるように設計すべき」といえます。(どこかのPodだけがバックアップを作成した場合、今生成されているPodにはデータが展開されない/ズレる等が出てきてしまうので)
コンテナの利点まとめ
コンテナの利点を書かせていただきましたが、まとめると大きく以下の4点になります。
自律性： オートデプロイ機能やセルフヒーリング機能により自動的に復旧が可能
拡張性： アクセスが集中したときはオートスケーリング機能により、一時的にリソースを拡張し即座に対応可能
集約性： ゲストOSを共有することで必要リソースを軽減できる
移行性： 開発環境で用意したコンテナを商用環境で再配置するのみなので工事が簡略化できる
コンテナ化するにあたり起きた問題点
これまでコンテナ化することの利点を書きましたが、コンテナ化することで起きた問題もあります。
OpenShiftではIPv6通信ができない
80/443ポートの通信しか受けられない
HTTPリクエストでヘッダ内にあるConnectionの値が「close」の場合、OpenShiftに削除された後コンテナに渡される
OpenShiftからコンテナの通信は、HTTPリクエストのヘッダ内にて指定されたホスト名を使って識別するため、ヘッダを統一する必要がある
コンテナからのレスポンスヘッダがOpenShiftで全て小文字に変換されてしまう
いくつかの問題に関してはシステムによっては使わない話であったり、OpenShift以外であればコンテナであっても起きない事象があったりします。 逆に上記以外の問題が起きる可能性があるので、既存システムをコンテナ化する場合には様々な検討/検証が必須となります。
まとめ
コンテナについて利点・問題点を中心に記事を書かせていただきました。 既存システムをコンテナ化する場合には色々と設計し直し、通信の見直し等が必要になります。 また、一つのシステムだけをコンテナ化する場合にはコンテナ化による恩恵が少なくなります。 他の技術でも言えることになりますが、コンテナ化することが本当に最善なのかを検討/検証することが大切になります。
