この記事はSAS Institute Japanが翻訳および編集したもので、もともとはJames Ochiai-Brownによって執筆されました。元記事はこちらです（英語）。

自己完結型のパッケージ内でソフトウェアを実行するというアイディアは、2013年のDockerの立ち上げと共に広まり始め、今ではアプリケーション開発とDevOpsのコミュニティにおけるホットなトピックとなっています。Red Hat社による最近の調査では、調査対象企業の57％が、いくつかのワークロードにコンテナを利用しており、次の2年間で採用数が2倍近くになると期待している、と回答しています。

SASはこのトレンドを認識しており、現在ではデプロイメント・オプションの一つとしてSAS for Containersを提供しています。これが仮想マシン上でSASを実行する手法の完全なリプレースになるとは思われませんが、そこには顕著なメリットがいくつか存在します。

1. アナリティクスへのセルフサービス型アクセス

組織の中には、「SASを利用したいが、それを手にできない分析担当者」を抱えているところもあります。また、SAS Platformを保有しているものの、そのオンボーディング・プロセスに承認手続きが設けられているビジネス部門も存在します。プラットフォームの運用管理者がファイルシステムやセキュリティモデルに変更を加えなければならない可能性があり、そのプロセスに時間がかかることもあります。

コンテナを利用すると、物事がよりセルフサービス型になります。IT部門はSAS用の標準的なコンテナイメージを準備し、それを社内のユーザー向けに提供します。分析担当者は用途に応じてその中から選択し、自分専用のインスタンスを起動するだけで、数分以内にSASでの作業を開始できます。Domino Data LabとBlueData は、こうした機能を提供するコンテナベースのデータサイエンス・プラットフォームの例です。

2. 様々なソフトウェア・ツールやバージョンに関するニーズへの対応が簡素化

SAS Platformの従来型の実装は、多数のユーザーによって共用されます。ユーザーは設定済みのソフトウェアを使用しなければなりませんが、それが最新バージョンであるとは限りません。コンテナを利用すると、IT部門はデータ分析担当者に対し、SASとオープンソースのソフトウェアを組み合わせた幅広い種類のコンテナイメージを提供することができます。例えば、SAS 9.4、SAS Studio、Jupyter Notebookを組み合わせたコンテナイメージも可能ですし、SAS Studio、Jupyter Notebook、R Studioのいずれからでもアクセスできる形でSAS Viyaの機械学習機能を提供するようなイメージも可能です。IT部門は、試用版ソフトウェアを提供することさえ可能です。開発者は、特定のプロジェクトに必要なソフトウェア・コンポーネントやAPI群を組み合わせて、独自のコンテナイメージを作成することもできるようになります。

3. ソフトウェア・アップデートの容易化

実際には、コンテナ内のSASソフトウェアがアップデートされることはありません。必要なのは、新しいバージョンで別のコンテナイメージを作成し、それを用いて別のコンテナを構築することだけです。つまり、ソフトウェアのアッグレード中にユーザーの作業を邪魔することは一切ありません。週末の作業も不要ですし、アップグレードがうまく進まないときに、どうやってシステムを元に戻せばよいかパニックになることもありません。新しいコンテナをテストし、準備が整った段階でそれをユーザー向けに展開すればよいのです。様々なバージョンのコンテナイメージを保持できるため、ユーザーは時間的な余裕をもって自分のコードを各バージョンでテストしたり、問題がないことを確認した上で新しいバージョンに移行したりできるようになります。

4. スケーラブルかつ柔軟で、隔離された計算処理環境

コンテナ・オーケストレーター（例：Kubernetes）は、多くのコンテナを起動することで、大きなコンピューティング・リソースを割り当てることができます。そのため、オンボードするユーザーが増えても、ジョブがスローダウンすることはありません。リソース消費が特に激しいプロセスを実行する場合でも、それが他のユーザーに影響することはありません。各コンテナは、それぞれのマシンのリソースの範囲内でのみ実行可能です。したがって、より多くのパワーが必要な場合は、コンテナを停止し、より大きなマシン上でそれを起動し直します。作業の完了後にコンテナを終了すると、そのマシンは他のユーザーのために解放されます。

5. アナリティクスをWebアプリに統合することが可能

今や、アナリティクスは分析担当者だけのものでありません。デジタル変革に取り組んでいる組織は、顧客がデジタルチャネルを通じて利用するWebアプリやモバイルアプリの背後にアナリティクスを組み込もうとしています。具体的には、画像処理、レコメンデーション、意思決定支援などを含むAIアプリケーションなどが考えられます。これらのWebアプリは従来の方式で実装されたSAS Platformと組み合わせて機能させることも可能ですが、その一方で、必要なSASソフトウェア、分析モデル、小型の実行エンジンとしてのサポーティング・コードだけで構成した実行エンジンを軽量なコンテナに実装すると複数の利点があります。こうすることで、開発者は、他のユーザーに影響を与えることなく、SASソフトウェアの設定やAPI群を変更する自由を手にします。これは、アプリケーションがPythonまたはJavaで実装される方法に似ています。

6. 自動モデル・チューニング

モデルの中には、データが変化するたびに、あるいは新しいフィードバックを受け取るたびに、頻繁に更新する必要があるものもあります。コンテナを利用すると、そうしたモデルを再チューニングし、その結果をコンテナ内にパッケージし、実業務環境にデプロイするまでのプロセスを自動化することができます。

7. DevOpsやCI/CDによるデプロイメントの合理化／効率化

典型的なSASユーザーはDevOpsの世界には馴染みがないかもしれませんが、DevOpsは昨今の主流となりつつあるアプリケーション開発手法です。アナリティクスをWebアプリに統合したい場合、私たちはこのプロセスに沿って進める必要があり、それを最も簡単に行う方法が、コンテナを利用する手法です。SASコードとモデルをコンテナ内にカプセル化すると、アプリ開発者（＝Dev）側では、デプロイのために運用チーム（＝Ops）側に渡す前に、コンテナに接続しテストを実行できるようになります。「継続的インテグレーション（CI）」と呼ばれる手法では、アプリ（SASのパーツを含むアプリ）の全てのブランチ（分岐）における変更は、それらが一緒に正しく機能する状態を確保するために、定常的にマージされ、自動テストにかけられます。「継続的デリバリー（CD）」と呼ばれる手法は、本番の業務環境へのリリースまでのプロセスを自動化します。これにより、アナリティクス・プリケーションの開発とデプロイを数週間ではなく、数日または数時間で完了することが可能になります。

SASコードとモデルをコンテナ内にカプセル化すると、Dev側では、デプロイのためにOps側に渡す前に、コンテナに接続しテストを実行できるようになります。 Click To Tweet

 

8. ほぼ全ての場所にデプロイすることが可能

コンテナはポータブル性に優れているため、オンプレミスのデータセンターから、パブリッククラウドや、ドローン／トラック／列車に搭載されたエッジデバイスに至るまで、あらゆる種類の場所でSASの実行エンジンを動かすことが可能です。

コンテナは、イマジネーション豊かなアナリティクス活用を実現可能にする大きなポテンシャルをもたらします。あなたがSAS Viyaのライセンスをお持ちの場合は、SASが運営するDockerイメージ・ライブラリへのアクセス権を有していますから、そこから事前準備済みのコンテナイメージの形でSAS Viyaをダウンロードすることができます。コンテナのカスタマイズや適合化を実行したい場合は、GitHub上でSAS Viyaをコンテナ方式でデプロイするためのDockerレシピ群をチェックしてください。基本事項は以上です。あとは、真のメリットの実現に向け、あなた自身がコンテナの試用、適合化、共有、改善、業務環境へのデプロイに取り組む段階です。