「窮屈」で「制約の多い」コンテナは、なぜクラウドネイティブで使われるのか：DXに悩むITマネジャーにささげる！ クラウドネイティブ講座（4）

必ずしも「コンテナ＝クラウドネイティブ」ではありません。しかも、コンテナを使い始めた人からは、「窮屈」「成約が多い」という声も多く聞かれます。それでもコンテナが広く使われているのは、なぜなのでしょうか？

[草間一人，HashiCorp]

　「DXに悩むITマネジャーにささげる！ クラウドネイティブ講座」の第4回です。

　前回は、ITにおけるコンテナ技術（以下、コンテナ）の概要を解説した上で、物流におけるコンテナ（以下、物流コンテナ）によって物流に革命が起こされたこと、そして同様の変化をコンテナでも享受できるという話をしました。

　今回は、もう少しコンテナについて深掘りしていきましょう。

革命は、標準化によってもたらされる

　物流コンテナによる革命は、物流コンテナそのものによってもたらされたわけではありません。物流コンテナはただの金属の箱であり、単体で何か変化を起こせるような機能を持っているわけではありませんでした。

　物流に革命が起こったのは、標準規格として寸法から金具に至るまで仕様が定められたこと、そしてトラックから鉄道、船、クレーンに至るまで、全てのサプライチェーンがその仕様に対応したことが大きかったのです。

　物流コンテナの中身が何であろうとも統一した取り扱いができるようになり、従来の仕組みでは大量に発生していた人間の作業を、大きく削減できるようになりました。

　コンテナも同様です。アプリケーションをDockerで動かせるコンテナイメージにするだけでは、大したメリットは得られません。それどころか、標準化を無視したコンテナイメージの作り方をしてしまうと、メリットを全てスポイルしてしまい、「コンテナ化なんてしなければよかった」という事態に陥る可能性すらあります。標準化された仕組みに正しく乗り、コンテナに対応したエコシステムで活用することが何よりも重要なのです。

コンテナ時代のアプリケーションに向けた標準“Twelve Factor App”とは

　それでは、コンテナ時代における「標準」とはどのようなものでしょうか。

　ログの出力で考えてみましょう。従来のアプリケーションの場合、ログの出力方法はアプリケーションによって異なります。例えば以下のような方法が考えられます。

• アプリケーションと同じ階層にあるlogsフォルダにファイルとして出力
• /var/logフォルダにファイルとして出力
• syslogサーバに向けて出力

　どこか1カ所にログを集約したい場合、これらの出力されたログファイルに対してログ収集エージェントを設定し、ログサーバに送信するという手法が用いられていました。

　コンテナを使った運用を行う場合、コンテナプラットフォーム側にログを収集する仕組みが備わっています。しかし、この恩恵を受けるためにはコンテナプラットフォームが用意している仕組みに沿う必要があります。具体的には、「標準出力」および「標準エラー出力」にログを出力すると、自動的にログを収集してくれる仕組みとなっています。

　一方で、独自のログファイルに出力する方法には対応していません。もしも対応させたい場合は、別途ログを収集するエージェントを立ち上げるなどの工夫が必要となります。

　このように、工夫をすれば標準から外れたことでも実現可能です。しかし、この連載で繰り返し述べているクラウドネイティブ思考、「コンピュータの力でコンピュータを動かす」「人間の関与をなくしていく」を実践するには、このような工夫は足かせにしかなりません。仕組みを人間の都合に合わせていくのではなく、人間がコンピュータの仕組みに合わせていくことを徹底したほうが良いでしょう。

　こういった、コンテナを活用していくに当たって守るべき12項目のベストプラクティスをまとめた方法論が、“Twelve-Factor App”です。正確にいうと、これが提唱されたのはコンテナ技術が流行するよりも前の2012年です。しかし、コンテナ時代である現在でも、十分に参考になる内容になっています。前述したログの話は、11番目に取り上げられています。

The Twelve Factors

I.　コードベース

バージョン管理されている1つのコードベースと複数のデプロイ

II.　依存関係

依存関係を明示的に宣言し分離する

III.　設定

設定を環境変数に格納する

IV.　バックエンドサービス

バックエンドサービスをアタッチされたリソースとして扱う

V.　ビルド、リリース、実行

ビルド、リリース、実行の3つのステージを厳密に分離する

VI.　プロセス

アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

VII.　ポートバインディング

ポートバインディングを通してサービスを公開する

VIII.　並行性

プロセスモデルによってスケールアウトする

IX.　廃棄容易性

高速な起動とグレースフルシャットダウンで堅牢性を最大化する

X.　開発/本番一致

開発、ステージング、本番環境をできるだけ一致させた状態を保つ

XI.　ログ

ログをイベントストリームとして扱う

XII.　管理プロセス

管理タスクを1回限りのプロセスとして実行する

（https://12factor.net/ja/より引用）

　一部時代にそぐわないところをリニューアルした、“Beyond the Twelve-Factor App”という方法論も2016年に提唱されており、こちらも必見です。

　クラウドベンダーには、PaaS（Platform as a Service）系のプロダクトもあります。これらはより高度な抽象化を提供しており、直接ユーザーがコンテナを扱わずともアプリケーションを良い感じに運用できるサービスを提供しています。こういったサービスにおいても、内部ではコンテナを活用しているのが一般的です。そのため、PaaSのユーザーはTwelve-Factor Appの恩恵を同様に受けられます。実は、Twelve-Factor Appを提唱したのは、PaaSの黎明（れいめい）期より存在するHerokuのエンジニアだったりします。

標準に沿うのは簡単ではない、しかし……

　「窮屈」「制約が多い」「自由に使えない」。これらはコンテナを活用し始めた多くの人から聞かれる言葉です。前述したように、コンテナをうまく扱うには守るべきルールがたくさん存在します。ひとたび標準的な使い方のレール（線路）から外れてしまうと、とたんにメリットが損なわれてしまいます。結果として、これらの声につながるわけです。

　第3回でも述べましたが、クラウドネイティブ技術はコンテナに限った話ではありません。しかし、コンテナではないクラウドネイティブ技術を使ったとしても、やはり同様な「仕組みに沿うことによるつらさ」は発生します。

　例えば、筆者が所属するHashiCorpはTerraformというインフラ構築の自動化ツールを提供しています。Terraformの特徴的な点は、インフラの構成をコードで行う“Infrastructure as Code（IaC）”という手法を用いて自動化を行うところにあります。コードで管理をすることによって、構成のバージョン管理を行ったり、再利用によって生産性を高めたりといったことが可能となります。非常にメリットの多いツールですが、導入初期には「なぜGUIから管理できるものをわざわざコードにしなきゃいけないんだ」と反発されることもあります。

　「今までのやり方ができないからクラウドネイティブ技術の導入をあきらめた」という声を、筆者はこれまで何度も聞いてきました。しかし、これは本当にもったいないことだと思っています。

　第3回で例として取り上げた物流コンテナですが、その導入に当たっては業界から多くの反発があったといいます。これまでの仕事ができなくなってしまう港湾労働者や労働組合、コンテナに合わせて改修することに消極的な港湾の運営者、標準規格への対応を渋る鉄道やトラックの業者等々。しかし最終的には、物流コンテナによる圧倒的な効率性を前にして、反対していた人や企業は消えていってしまいました。物流コンテナに積極的だった港は大きく栄えた一方で、消極的だった港は街もろとも衰退してしまったケースもあるといいます。

　そうならないためにも、なるべく早いうちから取り組んでいく必要があるでしょう。

進んで制約を受け入れることが、自由をもたらす

　「そうはいっても、今までのやり方ができないのはつらい」と思う人は、思い切って考えを変えてみるのはいかがでしょう。「この自由度のなさこそが、自由をもたらすんだ」と。

　「お前は一体何を言っているんだ」と思われるかもしれませんね。でも、極めて真面目に言っています。

　あなたは野球の経験はありますか？　野球では、よく「コンパクトなバッティングを心がけろ」と言われます。いくら動体視力が良くても、いくら筋力があっても、好き勝手にブンブン振り回したところで良いバッティングはできません。脇をしっかりと締め、体が開かないようにして振ることが大事なのです。ゴルフもそうですね。スイングの時に体が開いていると、ヘッドの軌道が乱れてしまい、打球は右に左に飛んでしまうでしょう。

　正しいフォームを学ぶ際、誰しも最初は窮屈に感じるものです。しかし、何度も練習しているうちにその窮屈さは気にならなくなり、結果も出るようになってきます。正しいフォームを学ばず結果も出なければ、どこからも必要とされずキャリアとして不自由になってしまいますね。

　車でレースをする際、道を外せば崖から真っ逆さまという危険な場所で、全力でアタックする人はいません。ですが、もしそこにガードレールがあればどうでしょう。ドライバーは安心して攻めることができ、タイムは大幅に向上するでしょう。

　ITも同じです。正しいお作法を学ぶ。標準仕様に沿う。これを守ることで、全体を通した設計から不自然な点が減っていき、結果として設計の自由度が上がります。生産性が高いとして一世を風靡（ふうび）したフレームワークであるRuby on Railsには、”Constraints are liberating（制約が自由をもたらす）” という考え方がありました。これもまさに同じことを指していますね。

　何の制約もない自由なシステムを使いながら、後々を見据えた効率のよい設計を行っていくのでは、考えなければいけないポイントが多岐にわたり大変です。逆に、クラウドネイティブ技術の考え方に素直に従っておけば、それだけである程度良い感じの設計ができ上がっている。そう考えると、ちょっとやってみようかなという気になりませんか？