1. ‘SAS 컨테이너 런타임’이란? SAS는 SAS Viya 2021.1.1.3에서 SAS 컨테이너 런타임(SAS Container Runtime, 이하 SCR)을 출시했으며, 그 이후 많은 고객이 운영환경에서 SCR을 구현했습니다. 이 혁신적인 런타임 엔진은 SAS 모델과 의사결정을 Open Container Initiative (OCI) 호환 컨테이너에 배포하는 역할을 합니다. SCR은 표준 기술을 사용하여 SAS Viya 외부에서 모델과 의사결정을 실행합니다. 클라우드
背景の紹介 これまでのSAS製品は、SAS 9でもSAS Viya 3.5でも、ほとんどがWindowsやLinuxのプラットフォームで動作していました。 そのため、Windowsクライアントを持つユーザーは、SMBサービスやWindowsのファイル共有機能を介して、これらのプラットフォームに保存されたファイルに簡単にアクセスすることができていたのです。 SASが開発した最新のクラウドネイティブ・データアナリティクス・プラットフォーム「SAS Viya」は、WindowsやLinuxなどのOS上で直接動作するのではなく、コンテナ／ポッドの形でKubernetes（以下、K8s）上で動作し、従来の製品とはアーキテクチャが大きく変わっています。K8s上で動作するサービスのコンテナ内のデータは一時的なものなので消えてしまう特徴があります。この点に対して、お客様は最新の製品を使用する際に、K8sに保存したデータをローカルのWindowsシステムからどのようにアクセスするのか、SASで作成したレポートなどのデータをどこに保存するのかという疑問を持つことが多いようです。 今回は、下記の図の構造のような、K8sに保存されているファイルを、比較的簡単な方法でWindowsクライアントと共有する方法をご紹介したいと思います。 本記事の内容は、Microsoft Azure上にデプロイされたSAS Viya Stable 2021.2.3に基づいています。centos 7.9上で、kubectl、kustomization、azure cliなどのコマンドラインツールを利用する作業が含まれているので、Linux、Kubernetes、SAS ViyaのデプロイメントとAzureに関する一定の知識が必要です。また、お使いのクラウドベンダーや製品のバージョンによって、設定方法が異なる場合もありますので、詳細は各ドキュメントをご確認ください。 SAS Viya on Kubernetesが利用するストレージの紹介 まず、K8s上にデプロイされたSAS Viyaサービスを使用した場合のデータの保存方法について簡単に説明します。 例えば、SAS Studioを利用する場合、ユーザーがセッションを作成するたびに、SAS ViyaはK8s上に一つのコンテナを作成します。これは、ユーザーがセッションで実行したすべてのコードや操作がこのコンテナに入っているミニLinux内で実行されます。 ご存知のように、コンテナの最大の利点は、インストール作業や設定などが一切いらず、配置したらすぐに使えることです。コンテナが提供するサービスや機能を使用するために設定を行う必要はありませんが、同時に、コンテナ内のデータに加えた変更も保存されず、新しいセッションを作成するたびに、まったく同じ設定を持つまったく新しいコンテナが作成されます。 そのため、SAS Studioで作成した新しいデータを保存したい場合は、コンテナの外部にあるストレージに保存する必要があります。K8sではこの外部ストレージは永続ボリュームと呼びます。 永続ボリュームを利用することにより、SAS Studioのセッションが終了しても、作業中にユーザーが作成した新しいデータはちゃんと保存されています。次にユーザーが新しいセッションを作成する時、以前使用していた永続ボリュームが新しいセッションに自動的にマウントされ、ユーザーが永続ボリュームに保存されていたデータを使って引き続き作業できます。この記事で紹介するデータ共有方法も、こちらの永続ボリュームを利用しています。 データ共有するための設定方法 次に、K8sで作成したファイルをWindowsと共有する方法を紹介します。前述したように、作業中に発生したデータを永続ボリュームに保存することができるので、永続ボリュームをWindowsにマウントするだけで、作業用PCとK8sの間でデータを共有することができますが、実現方法は使用する永続ボリュームの外部ストレージの種類によって異なります。 AzureのK8sサービス上でSAS Viyaを利用する場合、使用する外部ストレージは、大体以下の3種類です。Azure Fileを共有ストレージとして使用する場合、追加のサーバは必要なく、使い方も比較的簡単なので、本記事ではAzure Fileを外部ストレージとして使用する場合の共有方法を紹介します。 - ネットワークファイルシステム（以下NFS） - Azure Disk - Azure File（本記事で紹介する方法） データを共有するためには、次のような手順が必要です。 これらの手順には、AzureとK8sの管理者権限と関連する知識が必要なため、一般的にはサーバ管理者やSAS Viya導入の担当者が行うことになることに注意してください。 １．ストレージクラスの作成 ２．永続ボリューム要求の作成
In my previous post, Group-based access to Azure Files in the new SAS Viya, I walked through an example of making one or more Azure File Shares available to SAS Viya end user sessions with a group-based access pattern. This post extends the scenario and covers the case where we
You've probably heard by now the new SAS Viya runs on containers orchestrated by Kubernetes. There is a lot to know and learn for both experienced users and k8s noobies alike. I would recommend searching the SAS Communities Library for a wealth of information on deployment, administration, usability, and more.
Having trouble easily moving software from one environment to another? Surely this ought to be an uncomplicated process, especially in the modern age of technology! However, let us consider an analytical model built in a design environment to detect fraudulent credit card transactions. This is now ready to be rolled
前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス 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
