コンテナをビジネスにどう活用するのか?-- SOMPOホールディングス、デンソーの取り組みを紹介

ZDNET Japan Ad Special

2020-10-02 11:00

[PR]クラウドネイティブ技術に取り組む企業を支援するコミュニティCNBF(Cloud Native Bright Future)が2020年8月5日、オンラインミートアップ「コンテナをビジネスにどう活用するのか!?」を開催した。

 クラウドネイティブ技術に取り組む企業を支援するコミュニティCNBF(Cloud Native Bright Future)が2020年8月5日、オンラインミートアップ「コンテナをビジネスにどう活用するのか!?」を開催した。世界中が依然としてコロナ禍を脱していない今、多くの企業はビジネスモデルや働き方の変革を迫られており、テレワークやリモートでのオペレーションを推進していく必要がある。デジタル化を急速に進めるにはコンテナやKubernetesは強い支えとなるだろう。今回は基礎知識のエッセンスと、実際にコンテナをビジネスに活用しているSOMPOホールディングス、デンソーの取り組みを紹介した。

クラウドネイティブな世界をキャッチアップ。Docker/Kubernetesの基礎知識

 最初のセッションでは、今からコンテナやクラウドネイティブの世界に足を踏み入れる人でも一気にキャッチアップできる情報を、「Docker/Kubernetes コトハジメ」と題してCNBF運営委員の早川大貴氏がまとめた。

 コンテナとはアプリケーションの実行に必要な環境(コードやランタイムなど)を1つのパッケージにまとめたもので、コンテナイメージとも呼ばれている。Dockerはコンテナアプリケーションの実行環境とその周辺ツールだ。従来のVMはハードウェアを仮想的にエミュレートしており、ハイパーバイザーの上にそれぞれのゲストOSやアプリケーションが稼働する。一方コンテナはホストOSの上に実行環境(Docker)があり、その上でコンテナアプリケーションがプロセスとして稼働する。

 実際にDockerを使う時はDockerfileを作成し、Dockerイメージをビルドする。Dockerコンテナを起動すると、コンテナで稼働するアプリケーションにアクセスできるようになる。コンテナイメージを保存(プッシュ)するのがコンテナレジストリ。SaaSならDocker Hub、GCP Container Registry、AWS ECR、Azure Container Registryがあり、OSSならHarbor、Kraken、Quayがある。

 続いてコンテナオーケストレーター。コンテナを使うようになると、コンテナを管理するものが必要になってくる。有名なものにKubernetesがある。Kubernetesは、もともとGoogleが内部で運用していたコンテナ基盤をOSS向けに作り直したもので、現在はCloud Native Computing Foundation(CNCF)に移管され、「Graduated」プロジェクトとして認定されている。

 KubernetesではPodと呼ばれる単位でコンテナを実行する。Kubernetesのコントロールプレーンにはetcd(データベース)、kube-controller manager、cloud-controller manager、kube-scheduler、kube-api-serverがあり、ノード(クラスタに参加しているサーバー)にkubelet、kube-proxyなどがある。

図:Kubernetesのコンポーネント
図:Kubernetesのコンポーネント

 Kubernetesは設定ファイルに基づきリソースを宣言的に作成するため、宣言的APIと呼ばれる。またコンテナが何らかの理由で停止すれば自動修復(セルフヒーリング)が行われ、SDKを使うKubernetes本体の機能を拡張できるのも特徴だ。Kubernetesには先述したPodのほかに、同一のPodをクラスターで展開しローリングアップデートによるデプロイするDeployment、Podを周期的に実行するCronJobなど多様なリソースが存在する。

 実際にKubernetes Componentsを使うなら、パブリッククラウドが提供しているマネージドサービス、またはKubernetesクラスター構築ツールを使うのが一般的だ。パブリッククラウドのマネージドサービスならGoogleのGKE、Amazon EKS、AzureのAKS、IBMのIKSなどがある。構築ツールならkubeadm、Rancherが有名だ。

 もしKubernetesについて学びたいなら、Kubernetesオフィシャルサイトのチュートリアルを見るといいだろう。学習支援用のKubernetes Playground(Katacoda)もあり、ブラウザから操作を試すことができる。またパブリッククラウド各社ごとに提供されているチュートリアルページも参考になる。

 書籍なら、代表的なものに「Docer/Kubernetes 実践コンテナ開発入門」、「15Stepで習得 Dockerから入るKubernetesコンテナ開発からK8s本番運用まで」、「Kubernetes実践入門 プロダクションレディなコンテナ&アプリケーションの作り方」、「Kubernetes完全ガイド」などが参考になる。

 技術者認定試験なら、管理者向けの「Certificate Kubernetes Administrator(CKA)」、アプリケーション開発者向けの「Certified Kubernetes Application Developer(CKAD)」がある。どちらもクリエーションラインが認定試験向けのトレーニングを提供している。

 ミートアップに参加したいのなら、このCNBFのほか、「Kubernetes Meetup Tokyo」、「CloudNative Days」などがある。Kubernetes用にSlackワークスペースがあるので、分からないことがあれば#jp-users-noviceチャンネルで質問するといい。英語も可なら#kubernetes-noviceチャンネルやStack Overflowの[kubernetes]タグから質問する方法もある。

なぜコンテナなのか? なぜコンテナオーケストレーションツールを使うのか?

 続いては、SOMPOホールディングスのデジタル戦略部の西野大介氏が、「"流行"に踊らされない、事業会社にとって真に価値のあるコンテナ活用を考える」と題したセッションを行った。SOMPOホールディングスではCDO(最高デジタル責任者)にシリコンバレー経験のある楢﨑浩一氏をすえ、モダンな開発手法や最新技術を全面的に取り入れている。当然ながらスクラムにより、ビジネス部門と一体となりアジャイル開発を進めている。

 IDCの調査によると、日本におけるコンテナの普及率は14.2%でようやく2桁に乗り始めたところ。しかし多くの企業は「自社環境にコンテナが適合するか」で迷っているところだろう。そこで西野氏は、コンテナの特性を紹介するとともに、コンテナに着目した事例を採りあげ、コンテナのどのような特徴がビジネスに好影響をもたらすのかを説明した。

 コンテナの特性として挙げられるのが不変性(Immutable Infrastructure)、再現性(Infrastructure as Code)、可搬性(Portability)である。

 不変性はステートレスで常に現在の状態を管理するということ。コンテナは仮想化されているため、変更があればいったん破棄して刷新する。これまでのステートフルな過去の歴史を背負いながら変更を管理するのとは対照的で、従来が「秘伝のタレ」だとすれば、コンテナは「使い切りパックのタレ」といったところだ。

 再現性はコードによる静的管理となる。コード化することで手作業を減らす。逆にこれまでは人手による動的管理で、手順書で人的な運用を必要としていた。

 可搬性は特定バージョンのライブラリやアプリケーションの依存関係など、環境ごと動かすことができることを表す。これまでは環境は動かさず中身(アプリケーション)を動かしていたため、ローカルから本番環境に移したら動かないなどの事象が起きることもあった。

 今回紹介した事例は同社のPWA(Progressive Web Apps)のモバイルアプリケーションだ。大きく分けてフロントエンド・バックエンド・AIの3系統あり、AI部分でコンテナを活用している。

 AI部分でコンテナを活用した理由は、開発環境と開発時期の差を埋めるためだ。開発環境は組織や段階(開発と本番)で環境が異なり、また開発時期はフェーズや機能刷新でアプリ部分とAI部分の開発時期に差が出てくるといった事情があった。そこにコンテナの不変性、再現性、可搬性がうまくはまり、高生産性と低コストがもたらされると判断した。

 コンテナオーケストレーションツールの採用背景については、サービスディスカバリ、ヘルスチェックやセルフヒーリング、オートスケーリング、ロードバランシングといった特性が挙げられる。デジタル戦略部のSprintチームでは、オーケストレーションツールとしてAWSのEKS(Amazon Elastic Kubernetes Service)および、ECS(Amazon Elastic Container Service)を採用している。

 EKSはOSSのエコシステムにあり、自由度は高いが難易度が高め。ECSはAWS独自で相対的に自由度や難易度が低めとなり、AWSの他のサービスと連携がしやすいといった特徴がある。一般的に、EKSはマイクロサービスや大規模本番向けなど、長期利用し要件が複雑なシステムでコストをかけても自由度と今後の移植性を重視したい時に向いている。逆にECSはPoCや小規模の社内システムなど、短期利用や要件がシンプルなシステムでコストをかけてでも自由度や移植性を追求する必要がない時に向いているとされる(ただし、大規模開発にECSが用いられるケースや、小規模でもスキルセット等によりEKSが適すケースもあるため、あくまで一般論であるとした)。

 今回のAI実行環境で使うコンテナそのものに特別な仕様はなく、オーケストレーションにおける高い自由度は必要ない。加えてアプリ部分についても、規模が小さく要件もシンプルであることから、ECSを選択した。

 また、今後のサービス展開によりアクセス数が大きく変わる可能性があり、ここにコンテナオーケストレーションツールのサービスディスカバリ、オートスケーリング、ヘルスチェック、セルフヒーリングの利点が享受できる。つまりオーケストレーションツールにより高可用性や高性能が実現できるわけだ。

図:コンテナとオーケストレーションツールの特徴と利点
図:コンテナとオーケストレーションツールの特徴と利点

 西野氏は、「コンテナの導入にはコンテナの不変性、再現性、可搬性などの特性を軸にして高生産性・低コストが実現できるプランが望ましい。オーケストレーションツールの導入には特徴を踏まえ、サービスを比較した上で、高可用性・高性能を実現できる構成を検討するといいでしょう。みなさま、楽しいコンテナライフを!」と締めくくった。

高度化するクルマのECUをKubernetesでオーケストレーション

 最後のセッションは、デンソーでデジタルイノベーション室長を務める成迫剛志氏による「Kubernetesをクルマに載せる ~DENSO Misaki 開発のご紹介~」だ。

 今、自動車業界は100年に1度の大変革期を迎えていると言われている。鍵となる新しい領域はCASE(Connected、Autonomous/Automated、Shared、Electric)と呼ばれており、ここではConnectedと関連してコンテナやKubernetesを取り上げた。

 もともとクルマには電子制御のECU(Electronic Control Unit)が数多く積まれている。エンジンの燃料噴射、オートクルーズ、ライトの制御を行うものから、周囲に何か検知したら止まるなどセンサーと連動して動きを制御するものまである。こうした組み込みの小さなコンピュータ(マイコン)が単独で動きつつ、全体で協調しているわけだ。

 ECUは組み込みなので出荷時のまま使い続けることが多く、バグフィックスや新機能追加が容易ではない。可能とするには「Connected」が重要になる。パソコンやスマートフォンと異なり、クルマは常に移動しており、郊外やトンネルなどネットワーク接続は不安定なことが多い。

 デンソーが現在開発中のConnected Vehicle Platform(コネクテッドカーのプラットフォーム)が「Misaki」だ。これは、天上と地上をつなぐ霊的な存在「ミサキ」を由来としており、Kubernetesをベースとしてクラウドとクルマをつなぐためのインフラとなる。

 Misakiの開発目的はいくつかある。組み込みシステム開発に着手するハードルを下げ開発のスピードアップを図るために、一般で普及しているクラウド周辺の技術や言語を使えるようにすること。クルマにアプリのデプロイやアップデートを簡単にできるようにすること。アプリケーション開発でネットワーク接続の問題を扱わなくてもすむようにすることなどだ。

図 動画11:10あたり:全体アーキテクチャ
図 動画11:10あたり:全体アーキテクチャ

 全体アーキテクチャは右側から、UI、API、デジタルツインがあり、クラウドとエッジ(クルマ)でアプリケーションのデプロイや管理をできるようにしている。

 Kubernetesを使う理由はECUへのアプリのデプロイや管理を容易にするため。現在ECUは小規模なマイコンが多いものの、ナビゲーションやエアコン制御などではストレージや大きなメモリを使うなどリソースが大きくなりつつある。近年では強力なGPUを搭載したものが登場しており、自動運転などにも利用され始めている。ただしクルマは誤動作すれば人命に直結する可能性があるため、現状のKubernetesベースのインフラは制御系ではなく、まずは情報系やエンタテインメント系を対象としている。

 Misakiはクルマにアプリをデプロイまたはアップデートするほかに、スペックに応じてクラウドとエッジで処理を分散することができる。例えばハイスペックなクルマならクルマ内で全て処理し、ロースペックなクルマなら一部の処理はクラウドで実行するといった制御ができる。そうした制御にKubernetesのサービスディスカバリやロードバランシングなどの特性を活かす。

 成迫氏はMisakiのオーケストレーターとサービスメッシュについて、デモを交えながら詳しく解説した。オーケストレーターは先述したように、クルマのスペックや負荷を自動判断してアプリのオーケストレーションやデプロイを行う。処理をクラウドとクルマで動的に分散したり、新しいアプリに差し替えたりできる。

 サービスメッシュはマイクロサービス的に処理が進むなかで、データのやりとりを制御する。それぞれのマイクロサービスにプロキシが隣接してデータプレーンとなり、全体をコントロールプレーンで制御する。プロキシが中間にあることで、通信状況がオンラインからオフラインに切り替わるとデータをキューにためておき、オンラインに回復すると自動的にクラウドにつなぐ。アプリが通信状態を考慮しなくてもいい。

 成迫氏は、「まだ量産までには時間がかかりますが、将来必ず必要になる機能であり、プロトタイプ開発を推進しています。運用面など解決すべき課題は多々ありますが、クラウドで先行している技術により、アプリを効率的に開発し、運用できるようにしていきます。さらに未来はスマートシティなどにも適用領域が広がると考えています」と、その将来性に期待を寄せている。

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]