1. コンテナ技術とマイクロサービス
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
多くの人が保有するスマートフォン、その中で様々なアプリが利用されています。このアプリ、有名なLINEなどは、実は2週間に一度程度、頻繁にアップデートされています。この頻繁なアップデートを支える技術として、コンテナ技術があります。
ソフトウェアは多くのモジュールで構成されています。その相互依存関係は複雑で、あるモジュール間の関係だけを考慮してアップデートしても、他のモジュールとの関係が崩れてしまいエラーになることが、しばしばあります。これを防ぐため、あるモジュールをアップデートした場合、あらゆる相互依存関係が崩れていないか、全体を長い時間と多くの人員を割り当てて再検証することが行われます。このようなアップデート手順（プロセス）では、2週間に一度と言った、頻繁なアップデートは不可能です。
コンテナ技術は、この問題を解決します。OS、ライブラリ、ミドルウェア、アプリ一部、など相互依存関係が強いモジュール群を一つのパッケージ（コンテナ）として考えます。このパッケージだけでソフトウェアの依存関係は閉じるので、アップデートは、このパッケージ内で閉じることができます。土台のOSがアップデートされても、このパッケージ内にOSの情報が保持されているので、土台のOSのバージョンとは関係なく、このパッケージはメンテナンスすることができます。このようなパッケージをコンテナと呼び、LinuxのName Space管理機構を使って実現されています。
このコンテナを小さな少数機能ごとに作ったものをマイクロサービスと呼びます。マイクロサービスの一つ一つがコンテナなので、このマイクロサービスごとに他のマイクロサービスとは独立してアップデートを行うことが可能です。このマイクロサービスでスマートフォンのアプリやクラウド側のサービスは構成されているので、2週間に一度程度の頻繁なアップデートが可能になります。このように頻繁にアップデートをすることで利用者を飽きさせず、バグ修正も高速に行うことをCI/CD (Continuous Integration, Continuous Delivery)と呼び、ソフトウェアにより顧客満足度を上げ、常に自社アプリが使われるビジネス環境を作るDX (Digital Transformation)の肝になっています。
また、昨今のOSS (Open Source Software)は、コンテナの形で配布されるのが多くなっており、OSSプロジェクトがコミュニティによりアップデートされても、そのOSSがコンテナであるため、自分のシステムの他のソフトウェアと干渉せず、新機能を常に使うことができます。セキュリティ面でも、OSSに脆弱性が発見されると、セキュリティパッチが当たった最新のOSSをダウンロードして安心して置き換えられるのも、コンテナ技術のおかげです。
2. MDM (Mobile Device Management)
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
ひと昔前のスマホアプリは、アップデートを、毎回、人手で行っていたのを覚えていますか？ それが、いつの間にか、多くのアプリが気づかないうちにアップデートされるようになり、使い勝手が少し変わったことで初めてアップデートされたことに気づくようになりました。このアップデートは先に述べたマイクロサービス単位で行われます。
この自動アップデートのためには、多くの人が持つスマホの対象アプリが、どのバージョンで、それをアップデートすべきか否かをサーバ側で判別することが必要です。リモートで各端末のソフトウェアの構成を把握し、そのバージョンを適切に維持することを、MDM (Mobile Device Management)と呼びます。
昔のガラケーの頃は、携帯電話内のソフトウェア構成は出荷時とほぼ変わりなかったのですが、スマホ端末内でのソフトウェア構成は、その後の利用者の使い方によって千差万別となっています。どんなマイクロサービス群が稼働しているかを、各端末の過去のサーバへのアクセスから把握することで、各端末の適切なアップデートが可能となります。
3. SBOM管理
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
スマホアプリを動かすために、どのようなソフトウェア群で構成されているかを示す、ソフトウェア部品表をSBOM (Software Bill of Materials)と呼びます。スマホアプリなど開発を行ったり、機能追加を行ったりする時、どのようなSBOM構成なのかを開発元が把握することが、 MDMの基本になります。多くの場合は、SBOMの各ソフトウェア部品は上記で示したマイクロサービスになっており、さらに、その多くはオープンソースソフトウェア（OSS）に由来するものとなっています。
アプリへの新たな機能追加のために、OSSをダウンロードして用いたり、ベンダーが開発したものを購入したりすることがよくあります。この時、新たに入手したソフトがどのような構成になっているかを明らかにして、SBOMのソフト部品構成に追加することが必要となります。この時に、FossIDのようなOSSライセンス＆セキュリティ管理ツールを用いると、どのようなOSSが混入しているのか、またその脆弱性はどうなのかがわかり、SBOMを更新する時の強い味方になります。
SBOMではソフト部品の粒度は利用者が管理しやすいようにすれば良いのですが、それらがどんなOSSの出自を持つかも合わせてFossIDにより管理しておくと、さらに安心です。OSSは多くの人が使うので、脆弱性の報告、対策パッチのリリースが高頻度にありますが、その対策パッチが必要か否かが、FossIDによる管理を併用しておくと瞬時にわかります。
お客様に寄り添いながら、安心してサービスを使い続けていただくためには、コンテナによるアプリ構成、リモートによるMDM、その管理系としてのSBOM管理、そしてOSS由来のソフト部品を明確化するFossIDを柱とするソフトウェア管理体系を構築することが肝要です。
OSS起因のセキュリティ問題に対し、適切なタイミングでパッチを充てるために、FossIDのようなツールを導入する前から、先進的な各社は手作業でSBOM管理をやって来ました。ソフトウェアのSBOM管理を行うツールはGitやSubversionなどが以前からよく利用されてきました。しかし構成管理においては、この部分はOSS由来で、その元となるOSSバージョンは何で・・・と言った情報を手作業で入れて対応する必要があります。一本のソフトウェア製品で仮に１万個のモジュール構成からなっていたとすると、一つのモジュールに関する情報を入力し確認する工数は1時間程度かかるかと思います。１万時間は一日８時間稼働したとして52人日程度となり、その費用は150万円程度に相当します。ソフトウェアのラインナップが派生も含めて毎年更新管理すべき対象が1,000本あったとすると、15億円/年に相当します。
この手作業をツールで効率化することで、ツールの費用を大幅に上回る人件費を削減することができます。大幅なコスト削減だけではなく、ソフトウェア開発能力を持つ優秀な人材を単なる情報入力の作業から解放し、競争力あるソフトウェア開発に回せることも企業の経営戦略から見れば大きなメリットとなります。ここでは試算の形でSBOM管理コストを示しましたが、多くの日本企業では、SBOM管理に関する対応工数は従業員の人件費に隠れており明示的には見ることができません。しかし筆者が経験したことから、上記で述べたようなSBOM管理でのツール入力（さらには上司報告用にExcel転機、報告書作成、過去のExcelからの再転換など非効率的な作業も含めて）で、非生産的な作業を従業員のボランティア精神に頼る形で強いており、これが日本企業の非生産性であり、日本をIT後進国たらしめていると実感しています。
以上説明したように、顧客に受け入れられるソフトウェアをCI/CDで作り、MDMで適宜アップデートしていく最新の顧客とのエンゲージメント型ビジネスモデルにおいては、SBOM管理をFossIDなどのツールにより効率化させることは、機械にできることは機械に任せ優秀な社員の能力を企業の成長に直接結びつける開発に集中させると言う経営戦略上からも、非常に大きなメリットがあります。
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは！」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法～攻めは最大の防御なり～」
5.「OSSと上手に付き合う方法～サプライチェーンを安全に～」
6.「ISO/IEC 5230で変わる？OSSコンプライアンス対策」
7.「著作権トロールとは？」
