Tag: containers

Analytics | SAS Events
SAS Global Forum 2019 論文紹介シリーズ 第4回「オペレーショナル・アナリティクス for IT」

前回は、ビジネス価値創出につながる「オペレーショナル・アナリティクス 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のようなより単純な代替手段がありますが、それらはエンタープライズアーキテクチャにはあまり適していません。 3.SAS® on Kubernetes: Container Orchestration of Analytic Work Loads 現在、Big Dataの時代で、Advanced analyticsのためのインフラストラクチャに対するニーズが高まっています。また、分析自体に対して、最適化、予測が最も重要領域であり、小売業、金融業などの業界ではそれぞれ、分析に対する独自の課題を抱えています。この論文では、Google Cloud

Analytics | Data Management
SAS Japan 0
SASのアナリティクスをコンテナ内で実行する8つの理由

この記事は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)」と呼ばれる手法は、本番の業務環境へのリリースまでのプロセスを自動化します。これにより、アナリティクス・プリケーションの開発とデプロイを数週間ではなく、数日または数時間で完了することが可能になります。   8. ほぼ全ての場所にデプロイすることが可能 コンテナはポータブル性に優れているため、オンプレミスのデータセンターから、パブリッククラウドや、ドローン/トラック/列車に搭載されたエッジデバイスに至るまで、あらゆる種類の場所でSASの実行エンジンを動かすことが可能です。 コンテナは、イマジネーション豊かなアナリティクス活用を実現可能にする大きなポテンシャルをもたらします。あなたがSAS Viyaのライセンスをお持ちの場合は、SASが運営するDockerイメージ・ライブラリへのアクセス権を有していますから、そこから事前準備済みのコンテナイメージの形でSAS