前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス for Data Scientist」ユースケースの論文を紹介しました。今回は、企業様にとって、クラウド上のインフラアーキテクチャと分析プラットフォームのデプロイメントについて、ご紹介します。昨今、なぜ「コンテナ」が注目されているのか、そして、クラウドやコンテナ上に分析プラットフォームを移行/構築し、活用することに関心があるのであれば、ぜひ最後までご覧ください。 1．Cows or Chickens: How You Can Make Your Models into Containers モデルは特定の作業（新しいデータをスコアリングして予測を出すこと）として役割を果たしてきています。一方、コンテナは簡単に作成し、廃棄し、再利用できることができます。実際、それらは簡単にインテグレートさせ、パブリッククラウドとオンプレミス環境で実行できます。SASユーザは本論文を通じて、簡単にモデルの機能をコンテナに入れることができます。例えば、パブリッククラウドとオンプレミス環境でのDockerコンテナ。また、SASのModel Managerは様々なソース（オープンソース、SAS、コンテナ等々）からモデルの管理を行うことができます。したがって、この論文はそれらの基本知識と、どのようにSASの分析モデルをコンテナに入れることをメインに紹介します。 2．Orchestration of SAS® Data Integration Processes on AWS この論文では、Amazon Web Services（AWS）S3でのSASデータインテグレーションプロセスの構成について説明します。例としては、現在サポートしているお客様がクレジット報告書を生成するプロセスを毎日実行しています。そして、そのお客様の対象顧客は1カ月ごとに1回その報告を受け取ります。データ量としては、毎日に約20万の顧客情報が処理され、最終的に毎月約600万人の顧客へ報告することとなります。プロセスはオンプレミスデータセンターで始まり、続いてAWSのSASデータインテグレーションでAPR計算が行われ、最後にオンプレミスデータセンターで報告書が生成されます。さらに詳しい情報としては、彼らのアーキテクチャ全体はマイクロサービスを使われていますが、同時にAWS Lambda、簡易通知サービス（SNS）、Amazon Simple Storage Service（Amazon S3）、およびAmazon Elastic Compute Cloud（EC2）などの独立した高度に分離されたコンポーネントも使われています。つまり、それらにより、データパイプラインに対するトラブルシューティングが簡単になっていますが、オーケストレーションにLambda関数を使用することを選択すると、プロセスがある程度複雑になります。ただし、エンタープライズアーキテクチャにとって最も安定性、セキュリティ、柔軟性、および信頼性もあります。S3FやCloudWatch SSMのようなより単純な代替手段がありますが、それらはエンタープライズアーキテクチャにはあまり適していません。 ３．SAS® on Kubernetes: Container Orchestration of Analytic Work Loads 現在、Big Dataの時代で、Advanced analyticsのためのインフラストラクチャに対するニーズが高まっています。また、分析自体に対して、最適化、予測が最も重要領域であり、小売業、金融業などの業界ではそれぞれ、分析に対する独自の課題を抱えています。この論文では、Google Cloud
