コロナ禍をきっかけにリモートワーク（remote work）やテレワーク（telework）が急増したという記事をよく見かけますが、正確に言えば、実際に増えたのは在宅勤務（work from home）です。リモートワークなら、出張所の職員は常にそうだし、テレワークも、リモートワークよりは「臨時」感が強まるものの、ほぼ同義です。どちらも「遠隔地での仕事」に変わりはありません。それに対し、在宅勤務は「じぶんち」で働くわけで、リモートワークの一形態にすぎませんが、じぶんちは他よりも特殊な環境です。何よりも、そこには自由があります！ 服装も自由。髭も伸ばし放題。ビデオ会議のときは上半身だけ身なりを整え、マスクをすれば問題なし。仕事に疲れたら、ふぅ…とため息をついて、「おれ、この仕事、向いてるのかぁ」と呟きながら、占いサイトで仕事運などもチェックできます。そう、独り言呟き放題なのも在宅勤務の特権です。が、息抜きに個人的なサイトを眺めるのは、あまりおすすめできません。

在宅勤務の急増で、企業のサイバーセキュリティ リスクも急増していますが、その主な原因は社員が息抜きに個人的なサイトを閲覧するからだそうです。会社のパソコンを通じた「いかがわしい」サイトへのトラフィックが、コロナ禍で6倍に増えたという、米クラウドセキュリティ企業の調査結果もあるぐらいです。

でも、この手の調査は、グローバルと銘打ってはいるけど、その対象に日本がどの程度含まれているのかはよくわかりません。日本の場合、在宅勤務のスペースが限られていることもあって、むしろリスクが高いのは、コーヒーショップなど、ネットがセキュアされているのか、誰が見ているのかわからない環境で仕事をすることではないでしょうか。そう言えば、半沢直樹も、居酒屋などの3密環境で重大機密をけっこうな大声で話し合っていました。いろんな意味でハイリスクです。

話がそれましたが、要するに、ユーザー（社員）側のリスクが高まっている以上、そのアクセス先となるクラウド側のセキュリティは今まで以上に強化しなければなりません。

クラウドセキュリティアライアンスが今年3月から5月にかけて200社以上を対象に行った調査によれば、83%の回答者がクラウドのセキュリティを最優先課題に挙げ、90%が何らかのクラウド セキュリティ ツールを使用しているそうです。しかし、その半数が人材不足でセキュリティ ツールを十分に使いこなせていないと答え、34％がセキュリティツールの複雑さが障害になっていると回答しています。にもかかわらず、セキュリティツールを使用している企業の3分の1は複数の製品を併用しているそうです。

複数の製品をどのように使い分けているのか、詳細は明らかではありませんが、思い当たるのは、たとえば、アクセス制御と暗号化に別々の製品を使うことでしょうか。それぞれを使いこなすために専門知識が必要になり、人材不足で本来使えるはずの機能を使いきれず、また別のシステムを継ぎ当てて複雑さが増す、とうような悪循環に陥っているのかもしれません。

クラウドにセキュリティツールを導入するときは、複雑化を避けることが重要なポイントになるようです。たとえば、HyTrust 製品のように、パブリッククラウドとプライベートクラウドのさまざまなサービスに一様に対応できて、それぞれのユーザーインターフェースから制御できるしくみなら、IT管理者がセキュリティツールのために学習しなおす必要がなく、すぐに効率よくセキュリティを強化できます。

コロナ禍が長引いて、今後も在宅勤務が常態化する見込みもある中、クラウドセキュリティの強化を考えている企業は、マルチクラウドのサポートとラーニングカーブの緩やかさ、そしてアクセス制御や暗号化など、幅広いニーズに対応できる製品を選ぶことがクラウドセキュリティ強化への第一歩であり、その後の運用を左右する最大の一歩なのではないでしょうか。

Kubernetes環境への円滑な移行は、遅かれ早かれIT部門が直面する課題。でも、そこには思わぬ落とし穴も・・・

コンテナ環境、特にKubernetesの普及が近い将来一気に進む可能性のあることは、前回のブログ「国内企業のコンテナ普及率が二桁の大台に」で取り上げました。

当然ながら、既存の環境からKubernetes環境への移行をいかに円滑に、効率よく進めるかが、各企業のIT部門が抱える喫緊の課題になってくるはずです。

そこで陥りがちな過ちは、既存の環境に合わせたデータ保護ソリューションを、新しいKubernetes環境にそのまま当て嵌めてしまうことです。これは当事者の立場になって考えたら、致し方ないことです。さんざんお金と時間と労力をかけて築き上げた、すでに機能しているツールを、そのまま使いたくなるのは人間のさがです。

それに、Kubernetes環境に展開されたアプリケーションは、Kubernetes自体の機能で複数のサーバーに分散され、パフォーマンスの最適化と障害耐性が確保されるわけで、アプリケーションのコンポーネントとデータの管理はKubernetesに任せれば良いという考え方も成り立ちます。それを包含する従来のインフラストラクチャに対して、従来のバックアップとリカバリのソリューションを適用すれば、Kubernetesの導入完了、これで我が社もクラウド ネイティブの仲間入り！と言えないこともありません。

でも、ここは慌てず、一歩下がって冷静に戦略を俯瞰してみてください。

まず、Kubernetesによるアプリケーション コンポーネントの分散管理は流動的です。全体のバランスに応じて配置が常に調整しなおされ、IPアドレスもその都度変わる可能性があります。既存のバックアップとリカバリのソリューションがそれに対応できるでしょうか？

まして、Kubernetesがアプリケーションを複数サーバーに分散するとき、別のアプリケーションが部分的に同一のサーバーに共存することが少なくありません。Kubernetesは、個々のアプリケーションの視点から、その全コンポーネントを管理するので、各サーバーに何を任せるかという役割を固定するような従来式の既成概念はありません。インフラストラクチャの視点に立つ従来式のバックアップ ソリューションには手に余るどころか、ほとんど異次元の世界にならないでしょうか？ 「まったく今どきの若いもんは一体何を考えているのか」と、従来式ソリューションのぼやきが聞こえてきそうです。

Kubernetes管理下に置かれたデータベースも含めて、まるごと全部バックアップしちゃえば済む、というアイデアもあるかもしれません。でも、仮にアプリケーションにコーディングのミスがあって、それが誤ってデータを削除してしまうようなミスの場合、データのバックアップが独立していないと、気が付いたらバックアップのデータも欠損していたということになりかねません。Kubernetesが良かれと思ってコンポーネントをレプリケーションして、あちこちのサーバーに再現したら、データ喪失の被害が拡大する危険性も否めません。

結論を言うと、Kubernetes環境のデータ保護は、Kubernetes専用ソリューションに任せたほうが安全です。Kubernetes特有の、柔軟にスケーリングして臨機応変に配置換えする動的な環境構成に対応でき、アプリケーションの視点からデータを管理できるツールが理想的です。

そして、データセット全体の完全コピーを単独で保持できるしくみも重要です。Kubernetes環境のデータサービス オプションはいろいろありますが、この観点から言えば、Kubernetes独自のAPIを通じて、外部ストレージでデータを管理するのが理想的と言えます。

もっと言えば、Kubernetesの導入と同時に、CI/CDパイプラインを実装して、前述のコーディング ミスのような状況を開発プロセスの早い段階で除去できるしくみを確立できたら、なお良いです。欲を言えば、きりがないですが・・・

とりえあず、Kubernetes専用のデータ保護ソリューション（特にKasten K10のようなアプリケーションの視点からデータを管理できるツール）の採用は、ぜひ検討してみてください。

Kubernetesがコンテナ環境のデファクトスタンダードに

コンテナの実用化がどれだけ進んでいるのか、具体的な数字を見たいと思い、IDC Japanの「2020年 国内コンテナ／Kubernetesに関するユーザー導入調査結果」を参照してみました。コンテナの普及は、昨年までは非常に緩やかなものでしたが、今年2月に458社を対象に行われた調査では、コンテナを本番環境で使用している企業が初めて二桁の大台に乗り、導入に前向きな企業までを含めると全体の7割に達する勢いで急上昇しています。

一方、「コンテナ？うちは物流会社じゃないよ」と答えたかどうかはわかりませんが、そもそもコンテナを知らないと回答した企業ははじめて一桁になり、しかも20.9%とから7.9%に激減しているので、コンテナの認知度は確実に高まっているようです。

そして、Kubernetesですが、コンテナを本番環境で使用している企業と導入構築／テスト／検証段階にある企業を対象にした調査では、54.7%がKubernetes（コミュニティ版）を使用し、24％がKubernetesを含むRed Hat OpenShiftを使用していると回答したそうです。ほぼ8割が何らかの形でKubernetesを使用しており、コンテナ オーケストレーション ツールはKubernetesの一人勝ち状態のようです。

ちなみに、世界に目を向けると、CNCF（Cloud Native Computing Foundation）が昨年1337社を対象に行った調査で、コンテナを本番環境で使用している企業はすでに84%だそうです。2016年に23％だったので、日本は大体4、5年遅れていると言えます。

ということは、ここから4、5年で日本も80%ぐらいまで激増するかもしれません。新技術の導入にはより慎重な日本企業が、ひとたび導入障壁を超えたら、一気に浸透する可能性は十分にあります。これをマーケティング用語で「キャズムを超える」と表現するらしいです。キャズム（chasm）とはもともと地割れのような溝のことを指します。底が深くて暗いので、向こう側に飛び移るには大変な勇気が要ります。でも、実際には飛び越えられない距離ではないので、ひと思いに飛び越えてしまえば、あとは自由に走り出せるイメージなのでしょう。

だから、あなたも勇気を出して思い切りジャンプしてみましょう！なんて無責任なことは言えませんが、市場動向として急増の兆しがあるのは事実です。まだ開発環境をコンテナ化していない企業は、一気に実用化を目指さなくても、調査／検討はしておくに越したことはないでしょう。

今からコンテナを導入するなら、同時にKubernetesの導入を検討すべきことは、調査結果からも理解できます。まずはコンテナ、そのあとKubernetesと段階を踏むと、インフラ設定が二度手間になったり、Kubernetesのためのやり直しが生じかねません。また、Kubernetes環境のデータ保護やセキュリティ管理のツール（たとえば、Kasten K10）の導入も同時進行で検討すべきです。その辺りの背景は「Kubernetesへの移行を成功させるには」で考察されているので、ご参照ください。