前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス 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 Platform（GCP）で提供されるGKEのKubernetesでこれらの仕事と課題を調整する方法を紹介します。本文で使われる例は、アナリティクス領域おいて最も強力な製品であるSASと、コンテナ管理の最適者GKEを使って、分析ワークロードを管理するソリューションを構築する例を紹介します。このソリューションには、スケーラブル、高いパフォーマンス、コスト削減とデプロイメントの簡単さというメリットがあります。
4．SAS® and Containers: The State of the Union 2019
近年、コンテナはアプリケーションの構築とデプロイに対し、一般的となってきている新しい技術です。SAS Global Forum 2018では、SAS Viyaのため、Dockerコンテナの作り方を紹介しました。コンテナは、SASコードまたはJupyter Notebook（Python）からViyaとそれに関連するCASアクションを呼び出し、使用することにより、SASプログラミングとその実証環境を立ち上げることができます。この論文では、違うSAS/ACCESSエンジンを通じて、いくつか例を挙げ、コンテナをKubernetes管理環境でより複雑なデプロイメントするパターンを紹介します。
5．Enabling SAS® Software to Communicate RESTfully with Cloud Services
Representational State Transfer（REST）アーキテクチャは、クラウド通信の標準となってきています。その理由はRESTが各種独立して変化しているサービスプロバイダー間の抽象化通信方式を一つ共通の場を提供しているからです。 RESTがあるため、SASソフトウェアは通信の承認プロセスや持続させるファンクションなどの処理はどのように提供されているかを知る必要がなく、さらにクラウドサービスの変更による影響も受けません。例えば、認証プロセスをLDAPからKerberosへ変更することができ、持続性はPostgreSQLからOracleに変更することもできます。SASソフトウェアは、HTTPプロシージャを呼び出してクラウドサービス要求を送信し、LIBNAME定義をJSON（JavaScript Object Notation）エンジンと共に使用してクラウドサービス応答を解析することによって、機能にアクセスできます。このような動作原理によって、作業を自動的に負荷分散することもできます。この論文では、SASソフトウェアがクラウドサービスのRESTfulクライアントになる方法を紹介します。
6．Seriously Serial or Perfectly Parallel Data Transfer with SAS® Viya®
SAS Cloud Analytic Services（CAS）は、SAS社のインメモリ分析製品のエンジンです。膨大な量のデータに対して非常にスケーラブルなパフォーマンスを提供しています。しかし、そのすべてのデータをCASにロード（または後で保存）することは、可能でしょうか。実際、CASはネイティブSASフォーマットから始めて、多くのサードパーティのデータプロバイダからの直接ロードまでを含む幅広いデータソースをサポートすることで、対処しています。そのプロセスの中で、アーキテクチャとインフラストラクチャを慎重に計画し、評価して、意図したとおりにすべてが迅速かつ効率的に進められるように構築されています。SAS Viya3.4以降、データ転送の取り組みに置いて、CASをより効果的に使うために使用可能な言語はかなり進化しました。シリアルデータ転送方法を使用するようにCASを明示的に設定することができますが、SASが狙っているのは効果的な処理です。また、CASおよびそのほかの関連コンポーネントを完全並列転送用にセットアップすることもできます。この論文では、CASへどの種類のデータ転送方式を実行依頼をしているのかを確認し、そのバックグラウンドに何をしているのかを検証し、説明します。
今回をもって、「SAS Global Forum 2019 論文紹介シリーズ」は終了となります。来年のSAS Global Forumにおいても、アナリティクスを活用し、ビジネス課題を解決し、具体的な成果を出すために必要となる様々な情報を提供してまいりますので、ご期待ください。
なお、SAS Global Forum 2020の詳細情報は下記のリンクにご覧いただけます。
