検索

開発者の皆さん、こんにちは！ InterSystems IRIS Cloud SQL and IntegratedMLコンテストの投票が開始されました。 🔥 ベストアプリケーションはこれだ！！ 🔥と思う作品にぜひ投票をお願いします。 投票方法は以下ご参照ください。 Experts nomination: インターシステムズの経験豊富な審査員がベストアプリを選び、Expert Nominationで賞品をノミネートします。 ⭐️ @Alexander.Koblov, Support Specialist⭐️ @Guillaume.Rongier7183, Sales Engineer⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Steve.Pisani, Senior Solution Architect⭐️ @Timothy.Leavitt, Development Manager⭐️ @Evgeny.Shvarov, Developer Ecosystem Manager⭐️ @Dean.Andrews2971, Head of Developer Relations⭐️ @Alexander.Woodhead, Technical Specialist⭐️ @Andreas.Dieckow , Principal Product Manager⭐️ @Aya.Heshmat, Product Specialist⭐️ @Benjamin.DeBoe, Product Manager⭐️ @Robert.Kuszewski, Product Manager⭐️ @Carmen.Logue , Product Manager⭐️ @Jeffrey.Fried, Director of Product Management⭐️ @Luca.Ravazzolo, Product Manager⭐️ @Raj.Singh5479, Product Manager⭐️ @Patrick.Jamieson3621, Product Manager⭐️ @Stefan.Wittmann, Product Manager⭐️ @Steven.LeBlanc, Product Specialist⭐️ @Thomas.Dyar, Product Specialist Community nomination: 開発者コミュニティのメンバーは、お好みのアプリケーションに対して1位～3位を指定しながら投票できます。 開発者コミュニティでのあなたの状態 順位 1位 2位 3位 開発者コミュニティに記事を掲載したり、OpenExchange（OEX）にアプリをアップロードしたことがある方 9点 6点 3点 開発者コミュニティに1つの記事を掲載した、または 1アプリケーションを OEX にアップロードしたことがある方 6点 4点 2点 開発者コミュニティへコメントや質問を投稿したことがある方 3点 2点 1点 エキスパートレベル 順位 1位 2位 3位 グローバルマスターズの VIP レベル または、InterSystems Product Managers 15点 10点 5点 グローバルマスターズの Ambassador レベル 12点 8点 4点 グローバルマスターズの Expert レベル または DC モデレーター 9点 6点 3点 グローバルマスターズの Specialist レベル 6点 4点 2点 グローバルマスターズの Advocate レベル または インターシステムズの従業員 3点 2点 1点 「ブラインド投票」とします！ 各応募作品への投票数は、誰にも分らないようになっています。1日1回、この記事のコメント欄に投票数を公開する予定です。 コンテストページの表示順は、コンテストに応募した時期が早ければ早いほど、上位に表示されます。 メモ：新しいコメントの通知を受けるために、この投稿を購読することをお忘れなく！（記事末尾の ベルのアイコンをクリックするだけ！） 投票に参加するには： Open Exchange へのサインインします（開発者コミュニティのアカウントを使用してください）。 投票ボタンは、開発者コミュニティ内で、質問／回答／記事の掲載／投稿に対するコメント など 記載いただいた方に対して有効になります。 ボタンが押せない場合は、コミュニティへのコメントやオリジナルの記事など、書き込みお願いします！詳細は、こちらの記事をご参照ください。 気が変わった場合は？　－　選択をキャンセルして別のアプリケーションに投票できます。 ぜひ 🔥これだ🔥 と思う作品に投票お願いします！ メモ：コンテストへ応募された作品は、投票週間中にバグを修正したり、アプリケーションを改良したりすることができますので、アプリケーションのリリースを見逃さずに購読してください

# はじめに データ分析は、急速に展開するこの時代において、ビジネス上の意思決定を行う上で欠かせない側面です。 組織はデータ分析に大きく依存して、十分な情報に基づく意思決定と競合優位の維持を行っています。 この記事では、Pandas と InterSystems Embedded Python を使ってデータ分析を実行する方法について説明します。 Pandas の基本、InterSystems Embedded Python を使用するメリット、および両方を組み合わせて有効なデータ分析を実行する方法について説明します。 .png) ## Pandas とは？ Pandas は幅広いタスクに使用可能で、Pandas ができることよりも、できないことを記述する方が簡単なくらい汎用性の高いツールです。 基本的に、Pandas はデータの拠点として機能します。 データのクリーニング、変換、分析を行うことで、データを理解しやすくすることができます。 たとえば、データセットがコンピューターに CSV ファイルとして保存されている場合、Pandas はデータを DataFrame というテーブルのような構造に抽出することができます。 この DataFrame を使用すると、以下のような様々なタスクを実行できます。 * 各列の平均、中央値、最大値、または最小値を求める、列間の相関性の有無を判定する、特定の列のデータの分布を調べるなど、データに関して、統計を計算し、質問に答えます。 * 欠損値の削除や特定の基準に基づく行と列のフィルタ処理によって、データをクリーニングします。 * 棒、線、ヒストグラム、バブルなどをプロットできる Matplotlib を使ってデータを可視化します。 * クリーニングと変換を終えたデータを CSV、データベース、または別の種類のファイルに保存します。 モデリングや複雑な可視化を詳しく見る前に、データセットの性質をしっかり理解しておくことが必要です。Pandas には、この理解を達成するために最適な方法が備わっています。 ## InterSystems Embedded Python を使用するメリット InterSystems Embedded Python は、InterSystems データプラットフォーム内に組み込まれている Python ランタイム環境です。 プラットフォーム環境から離れることなく、データプラットフォーム内で Python コードを安全かつ効率的に実行する方法を提供します。 つまり、様々な環境を切り替えながらデータ分析タスクを実行する必要がないため、データ分析の効率と生産性が向上します。 ## Pandas と InterSystems Embedded Python の組み合わせ Pandas と InterSystems Embedded Python を組み合わせることで、データアナリストはデータ分析タスクを簡単に実行できます。 InterSystems Embedded Python には、Python コードを実行するための安全で効率的なランタイム環境が備わっており、Pandas には、一連の強力なデータ操作ツールが備わっています。 これらを合わせることで、組織に包括的なデータ分析ソリューションを提供しています。 ## Pandas のインストール ### Python パッケージをインストールする Pandas と InterSystems Embedded Python と使用するには、Python パッケージとして Pandas をインストールする必要があります。 以下は、Pandas のインストール手順です。 * 管理者モードでコマンドプロンプトを開きます（Windows）。 * コマンドプロンプトで `/bin` ディレクトリに移動します。 * 次のコマンドを実行して Pandas をインストールします: `irispip install --target \mgr\python pandas` 。このコマンドによって Pandas は InterSystems が推奨する `/mgr/python` ディレクトリにインストールされます。インストールするパッケージによって、実際のコマンドは異なる場合があります。 `pandas` を、インストールしたいパッケージの名前に置き換えてください。 それだけです！ これで、Pandas と InterSystems Embedded Python を使用できるようになりました。 ````shell irispip install --target C:\InterSystems\IRIS\mgr\python pandas ```` .png) Pandas をインストールしたので、[employees データセット](https://drive.google.com/file/d/1Ggpl4xDfcKDtSjUnyIostp-fJgidFks1/view?usp=sharing)で作業できるようになりました。 以下は、CSV ファイルを Pandas DataFrame に読み込み、データクリーニングと分析を実行する手順です。 ### まず、Python の新しいインスタンスを作成しましょう Set python = ##class(%SYS.Python).%New() ### Python ライブラリをインストールします。ここでは、pandas と buildins をインポートします。 Set pd = python.Import("pandas") #;To import the built-in functions that are part of the standard Python library Set builtins = python.Import("builtins") ### データを pandas ライブラリにインポート InterSystems Embedded Python を使用して Pandas DataFrame にデータを読み込むには、いくつかの方法があります。 以下は一般的な 3 つの方法です。 次のサンプルファイルを[例](https://drive.google.com/file/d/1Ggpl4xDfcKDtSjUnyIostp-fJgidFks1/view?usp=sharing)として使用しています。 ### CSV からデータを読み取る CSV ファイルへのパスを使って `read_csv()` を使用し、カンマ区切り値を読み取ります。 Set df = pd."read_csv"("C:\InterSystems\employees.csv") ### テキストファイルをインポートする {#importing-text-files} テキストファイルの読み取りは CSV ファイルに似ています。 唯一のニュアンスは、以下に示すように、`sep` 引数で区切り文字を指定する必要があることです。 この区切り文字引数は、DataFrame 内の行を区切るために使用するシンボルを参照します。 区切り文字として、コンマ（`sep = ","`）、ホワイトスペース（`sep = "\s"`）、タブ（`sep = "\t"`）、コロン（`sep = ":"`）が一般的に使用されます。 ここでは、`\s` は 1 つのホワイトスペース文字を表します。 Set df = pd."read_csv"("employees.txt",{"sep":"\s"}) ## Excel ファイルのインポート 単一シートの Excel ファイルをインポートするには、ファイルパスを入力とする "read\_excel()" 関数を使用します。 たとえば、df = pd.read\_excel('employees.xlsx') というコードの場合、"diabetes.xlsx" という Excel ファイルを読み取り、そのコンテンツを "df" という DataFrame に格納します。 どの行を DataFrame のヘッダーにするかを決定するヘッダー引数など、他の引数も指定することができます。 デフォルトでは、ヘッダーは 0 に設定されているため、最初の行がヘッダーまたは列名になります。 列名を指定する場合は、names 引数に名前のリストを渡すことができます。 ファイルに行インデックスが含まれる場合は、index_col 引数を使って指定できます。 Pandas DataFrame または Series では、インデックスが行または列の位置を指す識別子であることに注意してください。 DataFrame の行または列にラベルを付け、インデックスを使用して特定の行または列にアクセスすることができます。 行インデックスは、値の範囲、時系列、一意の識別子（社員 ID など）、またはその他の種類のデータにすることができます。 列に関しては、インデックスは通常、列名を示す文字列です。 Set df = pd."read_excel"("employees.xlsx") ### Excel ファイルをインポートする（複数のシート）{#importing-excel-files-(multiple-sheets)} 複数のシートが含まれる Excel の読み取りも、それほど変わりません。 `sheet_name` という追加の引数を 1 つ指定し、シート名の文字列またはシート位置の整数を渡すだけです（Python では 0 インデックスが使用されているため、最初のシートは `sheet_name = 0` でアクセスできます）。 #; Extracting the second sheet since Python uses 0-indexing Set df = pd."read_excel"("employee.xlsx", {"sheet_name":"1"}) ### JSON からデータを読み取る Set df = pd."read_json"("employees.json") ## DataFrame 内のデータを確認 #### `.head()` と `.tail()` を使ってデータを表示する方法 これには、インポートした builtins ライブラリを使用できます（ZW でも動作します） do builtins.print(df.head()) .png) ### データセットの列をすべて表示 Do builtins.print(df.columns) .png) ## データのクリア ### 'Start Date' 列を日時オブジェクトに変換 Set df."Start Date" = pd."to_datetime"(df."Start Date") 更新後のデータセットは以下のようになります。 .png) ### 'Last Login Time' 列を日時オブジェクトに変換   Set df."Last Login Time" = pd."to_datetime"(df."Last Login Time") .png) ### 'Salary' 列の欠損値に平均給与を設定 Set meanSal = df."Salary".mean() Set df."Salary" = df."Salary".fillna(meanSal)   ## 分析の実行 ### 性別ごとの平均給与を計算 Do builtins.print(df.groupby("Gender")."Salary".mean()) ### .png) ### チームごとの平均ボーナス率を計算 Do builtins.print(df.groupby("Team")."Bonus %".mean()) ### .png)   ### 毎年採用される社員数を計算   Do builtins.print(df."Start Date".dt.year."value_counts"()."sort_index"()) ### .png) ###   ### 年功者かどうかで社員数を計算 Do builtins.print(df."Senior Management"."value_counts"()) .png) ## Pandas でのデータの出力 {#outputting-data-in-pandas} Pandas は様々なファイルタイプからデータをインポートできるように、様々な形式にエクスポートすることも可能です。 これは特に、データが Pandas を使って変換され、ローカルマシン上に保存する必要がある場合に行われます。 以下は、Pandas DataFrams を様々な形式で出力する方法です。 ### DataFrame を CSV ファイルに出力する {#outputting-a-dataframe-into-a-csv-file} Pnadas DataFrame（ここでは `df` を使用）は、`."to_csv"()` メソッドを使って CSV ファイルとして保存されます。  do df."to_csv"("C:\Intersystems\employees_out.csv")   ### DataFrame を JSON ファイルに出力する {#outputting-a-dataframe-into-a-json-file} `."to_json"()` メソッドを呼び出して、DataFrame オブジェクトを JSON ファイルにエクスポートします。 do df."to_json"("C:\Intersystems\employees_out.json")   ### DataFrame を Excel ファイルに出力する {#outputting-a-dataframe-into-an-excel-file} DataFrame オブジェクトから `."to_excel"()` を呼び出して、`“.xls”` または `“.xlsx”` ファイルとして保存します。 do df."to_excel"("C:\Intersystems\employees_out.xlsx")   ## 毎年採用される社員数を示す基本的な棒グラフを作成してみましょう。 これには、matplotlib.pyplot を使用します。   //import matplotlib Set plt = python.Import("matplotlib.pyplot") //create a new dataframe to reprecent the bar chart set df2 = df."Start Date".dt.year."value_counts"()."sort_index"().plot.bar() //export the output to a png do plt.savefig("C:\Intersystems\barchart.png") //cleanup do plt.close() .png)   以上です！ これらの単純なステップを使えば、CSV ファイルを読み取り、データをクリーニングして、InterSystems Embedded Python で Pandas を使って、基本的な分析を実行できます。   ## 動画 以下のリンクを使って、動画にアクセスできるようになりました。 動画そのものは、上記のチュートリアルの包括的な概要と詳細として機能します。 ## まとめ  提供されたチュートリアルは、Pandas が実行できる基本機能しかカバーされていません。 Pandas を使うと、広範なデータ分析、可視化、フィルタリング、集計タスクを実行できるため、あらゆるデータワークフローで貴重なツールとなります。 また、他のデータサイエンスパッケージと組み合わせると、たとえば、対話型ダッシュボードを構築し、機械学習モデルを開発して予測を行い、データワークフローを自動化することができます。 Pandas の理解をさらに深めるには、以下に記載するリソースを調べ、学習過程を加速させましょう。   ## 免責事項 _Pandas と InterSystems の活用には様々な方法があることに注意してください。 提供された記事は、教育のみを目的としており、最も最適なアプローチを保証するものではありません。 この記事の著者として、Pandas の機能を継続的に学習し調査しているため、より良い結果を生み出す別の方法や手法が存在する可能性があります。 したがって、読者は慎重な判断と注意を以って、この記事に記載さあれている情報を各自のプロジェクトに適用することをお勧めします。_

2023.2 の開発者プレビュープログラムの一環として、２番目の開発者プレビューを公開いたします。今回リリースされたのは、InterSystems IRIS と InterSystems IRIS for Health です。 本リリースの注目点 2023.2では、多くの機能修正と改善に加えて、時間認識モデリングや 強化された外部テーブル、読み込み専用の FEDERATED テーブルといった新機能が含まれる予定です。これら新機能の一部は、今回の開発者プレビュー版にはまだ含まれていません。ご注意ください。 2023.2の別の注目点は、プライベート・ウェブサーバ (PWS) がインストーラから削除されることです。このことは昨年に発表され、インターシステムズ製品のインストーラから削除予定ですが、今回のプレビュー版ではまだPWSは存在します。詳細はこちらのドキュメントをご覧ください。 --> PWSが含まれないインストーラにご興味のある方は、こちらのフォームからEAPに登録してください。その際、オプションで「No Private Web Server」をお選びください。このEAPに関する情報はこちらをご参照ください。 今後のプレビューリリースは、2週間ごとの発表を予定しており、新機能が完成次第、プレビュー版に追加されていきます。みなさまとよりよい製品にできるよう、ぜひ開発者コミュニティにみなさまのフィードバックをお寄せください。お待ちしております。 ドキュメントは以下のリンクからご覧いただけます。本バージョンが正式公開 (General Availability - GA) されるまで、数週間かけてドキュメントは更新される予定です。 InterSystems IRIS InterSystems IRIS for Health キットについて これまでと同じく、継続的デリバリ (CD) リリースは、すべてのサポート対象プラットフォーム向けに、従来のインストーラ形式と Docker コンテナ形式の両方でご提供します。サポート対象プラットフォーム一覧は、こちらのドキュメントをご覧ください。 インストーラとプレビュー用ライセンスキーは、WRC のプレビューダウンロードページ もしくは 評価サービスページ (2023.2を入手するには、"Show Preview Software" フラグをチェックしてください) から入手いただけます。 InterSystems IRIS / IRIS for Health の Enterprise Edition ならびに Community Edition、また関連コンポーネント、それら全てのコンテナイメージは、新しくなった InterSystems コンテナレジストリページから入手いただけます。docker コマンドに関する詳細な情報は、「InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ」の記事をご覧ください。 今回の開発者プレビューのビルド番号は 2023.2.0.201.0 です。 入手可能なイメージの一覧については, ICR に関するドキュメントをご覧ください。また、すべてのコンテナイメージの tarball 版は、WRC のプレビューダウンロードページから入手いただけます。

応募期間は 2020年6月29日～7月12日 です！ 優勝特典 １、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 1位 - $2,000 🥈 2位 - $1,000 🥉 3位 - $500 2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。 🥇 1位 - $1,000 🥈 2位 - $500 複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。 参加資格 どなたでもご参加いただけます。 コンテストのスケジュール 6月29日～7月12日 応募期間7月13日～7月19日 投票7月20日 優秀者発表 コンテストの課題 AI / MLInterSystems IRIS を使った AI/ML ソリューションの開発。 InterSystems IRIS を使用して開発された AI/ML ソリューションの中から、優秀アプリケーションに賞が贈られます。アプリケーションは、ライブラリ、パッケージ、ツール、または InterSystems IRIS を使用した AI/ML ソリューション等です。 アプリケーションは、IRIS Community Edition、IRIS for Health Community Edition、IRIS Advanced Analytics Community Editionのいずれかで動作する必要があります。 アプリケーションはオープンソースであり、GitHub で公開されている必要があります。 特別な技術を活用して開発されたアプリケーションは、テクノロジボーナスの対象となります。ボーナスの詳細については、このページで後日お知らせします。 ※コンテスト用テンプレートをご用意しています。テンプレート利用方法については、以下の動画をご参照ください（ページ内の テンプレート環境説明 もご参照ください。） テンプレートへのURL InterSystems IntegragedML Template IntegratedMLのGit InterSystems PythonGateway Template PythonGatewayのGit 参考情報 ドキュメント：IntergratedML（英語） オンラインコース（英語） InterSystems IRIS の IntegragedML について学ぶ 機械学習を行う前のデータの準備 機械学習ツールキットを使用した予測モデリング 参加要件（英語） コンテストの応募要件については、こちらをご覧ください。 審査員 インターシステムズ社のプロダクトマネージャ、Developer Communityのモデレータ、グローバルマスターアドボケイト（VIPレベル）等、Developer Community 内での投票も行われます。 審査及び投票ルール（英語） コンテストの審査および投票ルールはこちらをご覧ください。 テンプレ―トの環境説明 (1) 事前準備 Dockerのインストール　（コンテナを管理するアプリ） Gitのインストール　（ソースを管理するアプリ） VSCodeのインストール　（IDE） (2)　コマンド実行例 cd 任意のディレクトリgit clone [gitのURL] コンテナ作成のためのビルドdocker-compose build コンテナの開始docker-compose up -d コンテナの停止docker-compose stop コンテナ一覧を表示docker ps コンテナ一覧に表示されるコンテナ名を使用してコンテナにログインします。docker exec -it [コンテナ名] bash (3) 説明内容補足 (3)-1 IntegratedML テンプレート（00:46～17:55）補足情報 Jupyter起動用URL （4:00頃）http://localhost:8896/tree (3)-2 PythonGateway テンプレート(18:00～)　補足情報 Python Gateway　コミュニティの記事（英語） PackageSample.ObjectScriptのTest()メソッド実行例（19:11～） コンテナにログインdocker exec -it pythongateway-template_iris_1 bash IRISにログインiris session IRIS 以下、PythonGatewayコンテナ起動中のURL（ポートを変更されている場合はURLをご変更ください） チュートリアル用URL （22:30～） チュートリアル：プロダクション用URL（ユーザ名：Admin、パスワード：SYS） グラフ表示（ユーザ名：Admin、パスワード：SYS） 応募方法 以下の応募方法ビデオをご参照ください。 以下、コンテストに応募する迄の手順をご説明します。 コンテスト応募までの流れは以下の通りです（※ビデオでは、3番以降の内容をご紹介しています）。 1、IRISプログラミングコンテスト用テンプレートを使用して、開発環境を準備します。 2、コンテスト用アプリケーションを作成します。 3、コンテストの準備が完了したら、ソースコードをローカルのGitリポジトリへコミットします。 初回コミット時に、Gitの初期設定がないためコミットが失敗することがあります。その場合は、以下のコマンドでGitユーザ名とEmailを設定します。 git config --global user.name "ここにユーザ名"git config --global user.email "ここにメールアドレス” 4、ローカルのGitリポジトリのコミットが完了したら、リモートのGitリポジトリを作成します。 リポジトリ作成後、リモートリポジトリのURLをコピーします。 5、リモートのGitリポジトリへPushします。 git push ここにリモートのリポジトリのURL 6、OpenExchangeにログインし、アプリケーションを追加します。 ※事前にDeveloper communityでユーザアカウントを作成する必要があります。 ログイン後、Profile→Applications　から　Application　をクリックし、4 でコピーしたリモートのGitリポジトリのURLを設定します。 アプリケーションを登録すると、画面右上に「Send Approval」のボタンが表示されるので、クリックします。 再度作成したアプリケーションを開くと、「Apply for Contest」ボタンが表示されるので、クリックすると応募が完了します。

Amazon Web Services（AWS）クラウドは、コンピューティングリソース、ストレージオプション、ネットワークなどのインフラストラクチャサービスの幅広いセットをユーティリティとしてオンデマンドかつ秒単位の従量課金制で提供しています。 新しいサービスは、先行投資なしで迅速にプロビジョニングできます。 これにより、大企業、新興企業、中小企業、公営企業の顧客は、変化するビジネス要件に迅速に対応するために必要なビルディングブロックにアクセスすることができます。   更新: 2019年10月15日 以下の概要と詳細は Amazon が提供しているものであり、こちらから参照できます。 概要 ### AWS グローバルインフラストラクチャ AWS Cloud のインフラストラクチャは、リージョンとアベイラビリティーゾーン（AZ）を中心に構築されています。 リージョンは、世界中にある複数の AZ が存在する物理的な場所です。 それぞれの AZ は、別々の施設にある冗長電源、ネットワーク、接続機能を備えた 1 つ以上の異なるデータセンターで構成されています。 これらの AZ は、単一のデータセンターを使用する場合よりも高い可用性、耐障害性、拡張性を持つ本番アプリケーションとデータベースを運用する機能を提供します。 AWS グローバルインフラストラクチャの詳細は、こちらを参照してください。 ### AWS のセキュリティとコンプライアンス クラウドのセキュリティはオンプレミスのデータセンターのセキュリティとほぼ同じですが、設備とハードウェアのメンテナンスにコストがかからないという点が異なります。 クラウドでは、物理サーバーやストレージデバイスを管理する必要はありません。 代わりに、ソフトウェアベースのセキュリティツールを使用して、クラウドリソースに出入りする情報のフローを監視および保護します。 AWS クラウドは、責任共有モデルを提供しています。 AWS はクラウドのセキュリティを管理しますが、クラウドのセキュリティはユーザーが責任を負います。 つまり、実際のデータセンターと同じように、自身が所有するコンテンツ、プラットフォーム、アプリケーション、システム、およびネットワークを保護するために導入することを選択したセキュリティを制御し続けることができます。 AWS クラウドのセキュリティの詳細は、こちらを参照してください。 AWS が顧客に提供する IT インフラストラクチャは、最良のセキュリティプラクティスとさまざまな IT セキュリティ標準に合わせて設計および管理されています。AWS が準拠している保証プログラムの完全なリストは、こちらを参照してください。   AWS クラウドプラットフォーム AWS は、ビジネスや組織のニーズに合わせて組み合わせて使用できる 多くのクラウドサービスで構成されています。 次のサブセクションでは、InterSystems IRIS のデプロイで一般的に使用される主な AWS サービスをカテゴリ別に紹介します。 他にも多くのサービスがあり、特定のアプリケーションに役立つ可能性があります。 必要に応じて必ず調査してください。 サービスにアクセスするには、AWS マネジメントコンソール、コマンドラインインターフェース、またはソフトウェア開発キット（SDK）を使用できます。 AWS クラウドプラットフォーム コンポーネント 詳細 AWS マネジメントコンソール AWS マネジメントコンソールの詳細は、こちらを参照してください。 AWS コマンドラインインターフェース AWS コマンドラインインターフェース（CLI）の詳細は、こちらを参照してください。 AWS ソフトウェア開発キット（SDK） AWS ソフトウェア開発キット（SDK）の詳細は、こちらを参照してください。 AWS コンピューティング 次のようなさまざまなオプションを利用できます。AmazonElastic Cloud Computing（EC2）の詳細はこちらを参照してください。Amazon EC2 Container Service（ECS）の詳細はこちらを参照してください。Amazon EC2 Container Registry（ECR）の詳細はこちらを参照してください。Amazon Auto Scaling の詳細はこちらを参照してください。 AWS ストレージ 次のようなさまざまなオプションを利用できます。Amazon Elastic Block Store（EBS）の詳細はこちらを参照してください。Amazon Simple Storage Service（S3）の詳細はこちらを参照してください。Amazon Elastic File System（EFS）の詳細はこちらを参照してください。 AWS ネットワーキング 次のようなさまざまなオプションを利用できます。 Amazon Virtual Private Cloud（VPC）の詳細はこちらを参照してください。Amazon Elastic IP アドレスの詳細はこちらを参照してください。Amazon Elastic Network Interface の詳細はこちらを参照してください。Amazon の Linux 向け拡張ネットワーキングの詳細はこちらを参照してください。Amazon Elastic Load Balancing（ELB）の詳細はこちらを参照してください。Amazon Route 53 の詳細はこちらを参照してください。   InterSystems IRIS サンプルアーキテクチャ この記事の一部では、アプリケーション固有のデプロイの出発点として、AWS に InterSystems IRIS をデプロイする場合のサンプルを提供しています。デプロイの可能性には多数ありますが、これらのサンプルをガイドラインとしてご利用ください。このリファレンスアーキテクチャでは、最も小規模なデプロイから非常にスケーラブルなワークロードまで、コンピューティングとデータの両方の要件に対応する非常に堅牢なデプロイオプションを紹介しています。  このドキュメントでは、高可用性と災害復旧に関するオプションと共にその他の推奨されるシステム運用について説明しています。これらの運用は、組織の標準的なプラクティスとセキュリティポリシーに対応できるように変更してください。 InterSystems では、ユーザー固有のアプリケーションについて、AWS ベースの InterSystems IRIS デプロイに関するご相談またはご質問をお受けしています。 * * * ## サンプルリファレンスアーキテクチャ 以下のサンプルアーキテクチャでは、キャパシティと機能を高めるさまざまな構成を提供します。これらの小規模な開発、本番、大規模な本番、およびシャードクラスタを使用した本番の例を検討してください。開発作業用の小規模な構成から、ゾーン全体に適した高可用性とマルチリージョン災害復旧機能を備えた非常にスケーラブルなソリューションへと構成が成長していく様子を確認できます。さらに、SQL クエリの超並列処理によるハイブリッドワークロードに対する InterSystems IRIS データプラットフォームの新しいシャーディング機能を使用するサンプルアーキテクチャも用意されています。 * * * 小規模な開発の構成 この例では、最小構成を使用して、開発者数最大10 人と 100 GB のデータに対応できる小規模な開発環境を示します。仮想マシンのインスタンスの種類を変更し、EBS ボリュームのストレージを適切に増加するだけで、より多くの開発者と保存データを簡単にサポートできるようになります。 これは開発作業をサポートし、InterSystems IRIS の機能や、必要に応じて Docker コンテナの構築とオーケストレーションに慣れる上で十分な構成です。小規模な構成では通常、データベースミラーリングによる高可用性を使用することはありませんが、高可用性が必要な場合にはいつでも追加することができます。    小規模な構成のサンプル図 以下の図 2.1.1-a のサンプル図は、図 2.1.1-b のリソーステーブルを示します。含まれているゲートウェイは単なる例であり、組織の標準的なネットワーク実践に合わせて調整できます。  図-2.1.1-a: サンプルの小規模開発アーキテクチャ   以下の AWS VPC 内のリソースは、最低限の小規模構成としてプロビジョニングされています。AWS リソースは必要に応じて追加または削除することができます。    小規模構成の AWS リソース 以下のテーブルは、小規模構成 AWS リソースのサンプルを示しています。 図 2.1.1-b: 小規模構成 AWS リソースのサンプルテーブル   VPC への不要なアクセスを防止するには、適切なネットワークセキュリティとファイアウォールのルールを検討する必要があります。Amazon は、次のようなネットワークセキュリティのベストプラクティスを提供しています。 https://docs.aws.amazon.com/vpc/index.html#lang/en_us https://docs.aws.amazon.com/quickstart/latest/vpc/architecture.html#best-practices   注意: VM インスタンスが AWS サービスにアクセスするには、パブリック IP アドレスが必要です。 この実践では懸念を生じてしまう可能性がありますが、AWS は、ファイアウォールのルールを使用して、これらの VM インスタンスへの受信トラフィックを制限することを推奨しています。   セキュリティポリシーで VM インスタンスが完全に内部化されていることが要求されている場合、ネットワークと対応するルートに手動で NAT プロキシを設定し、内部インスタンスがインターネットにアクセスできるようにする必要があります。 SSH を使用して、完全に内部化された VM インスタンスに直接接続することはできないことに注意しておくことが重要です。 そのような内部マシンに接続するには、外部 IP アドレスを持つ踏み台インスタンスをセットアップしてから、それを通過するトンネルをセットアップする必要があります。 外部に接する VPC へのエントリポイントを提供するため、踏み台ホストをプロビジョニングすることができます。  踏み台ホストの使用方法に関する詳細は、こちらを参照してください。 https://aws.amazon.com/blogs/security/controlling-network-access-to-ec2-instances-using-a-bastion-server/ https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html * * * 本番の構成 この例では、InterSystems IRIS データベースミラーリング機能を組み込んで高可用性と災害復旧をサポートする本番構成の例として、より大規模な構成を示しています。 この構成には、自動フェイルオーバーを行うために region-1 内で 2 つのアベイラビリティーゾーンに分割された InterSystems IRIS データベースサーバーの同期ミラーペアと、AWS リージョン全体がオフラインになるという稀なイベントで災害復旧を行うことを目的とした region-2 の 3 番目の DR 非同期ミラーメンバーが含まれます。 マルチ VPC 接続を含む複数リージョンの詳細は、こちらを参照してください。 InterSystems Arbiter と ICM サーバーは、レジリエンシーを高めるために、別の 3 番目のゾーンにデプロイされています。サンプルアーキテクチャには、Web 対応アプリケーションをサポートするためのオプションとして、オプションの負荷分散された Web サーバーのセットも含まれています。InterSystems Gateway を備えたこれらの Web サーバーは、必要に応じて個別に拡張することができます。   #### 本番構成のサンプル図 図 2.2.1-a のサンプル図は、図 2.2.1-b のリソーステーブルを示しています。ここに記載されているゲートウェイは単なる例であり、組織の標準的なネットワークプラクティスに合わせて調整できます。    図 2.2.1-a: 高可用性と災害復旧を備えたサンプルの本番アーキテクチャ   以下の AWS VPC 内のリソースは、Web アプリケーションの本番ワークロードをサポートするための最小推奨要件です。AWS リソースは必要に応じて追加または削除することができます。   本番構成の AWS リソース 以下の表に、本番構成の AWS リソースのサンプルを示しています。 .png) 図 2.2.1-b: 本番構成の AWS リソースの表（続き）   * * * 大規模な本番の構成 この例では、InterSystems IRIS の機能を拡張することで、InterSystems の Enterprise Cache Protocol（ECP）を使用したアプリケーションサーバーを導入してユーザーの大規模な水平スケーリングも提供できる、大規模な構成を示しています。ECP クライアントはデータベースインスタンスのフェイルオーバーが発生した場合でもセッション情報を保持するため、この例ではさらに高いレベルの可用性が実現されています。複数の AWS アベイラビリティーゾーンが、複数のリージョンにデプロイされた ECP ベースのアプリケーションサーバーとデータベースミラーメンバーの両方で使用されています。この構成では、毎秒数千万件のデータベースアクセスと数テラバイトのデータをサポートできます。  #### 本番構成のサンプル図 図 2.3.1-a のサンプル図は、図 2.3.1-b のリソースの表を示しています。ここに記載されているゲートウェイは単なる例であり、組織の標準的なネットワークプラクティスに合わせて調整できます。  この構成には、フェイルオーバーミラーペア、4 つ以上の ECP クライアント（アプリケーションサーバー）、およびアプリケーションサーバーにつき 1 つ以上の Web サーバーが含まれます。 フェイルオーバーデータベースミラーのペアは、同一のリージョン内で 2 つの異なる AWS アベイラビリティーゾーンで分割されており、3 番目のゾーンに個別にデプロイされた InterSystems Arbiter と ICM サーバーでフォールトドメインの保護を確立し、レジリエンシーを高めています。  災害復旧は、前の例と同様に、2 番目の AWS リージョンとアベイラビリティーゾーンに拡張されています。複数の DR リージョンは、必要に応じて複数の DR 非同期ミラーメンバーターゲットと共に使用できます。   図 2.3.1-a: ECP アプリケーションサーバーを使用したサンプルの大規模本番アーキテクチャ   以下の AWS VPC プロジェクト内のリソースは、シャードクラスタをサポートするための最小推奨要件です。AWS リソースは必要に応じて追加または削除することができます。    大規模な本番構成の AWS リソース 以下の表に、大規模な本番環境構成のサンプル AWS リソースを示しています。 図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表 図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表（続き） 図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表（続き）   * * *   InterSystems IRIS シャードクラスタを使用した本番構成 この例では、SQL を使用したハイブリッドワークロード向けに水平スケーリングされた構成を示しています。この構成には InterSystems IRIS の新しいシャードクラスタ機能が含まれており、複数のシステムをまたぐ SQL クエリとテーブルの大規模な水平スケーリングを提供しています。InterSystems IRIS のシャードクラスタとその機能の詳細については、この記事の第9章で説明します。   #### シャードクラスタを使用した本番構成のサンプル図 図 2.4.1-a のサンプル図は、図 2.4.1-b のリソーステーブルを示します。ここに記載されているゲートウェイは単なる例であり、組織の標準的なネットワークプラクティスに合わせて調整できます。  この構成には、4 つのミラーペアがデータノードとして含まれています。それぞれのフェイルオーバーデータベースミラーのペアは、同一のリージョン内で 2 つの異なる AWS アベイラビリティーゾーンで分割されており、3 番目のゾーンに個別にデプロイされた InterSystems Arbiter と ICM サーバーでフォールトドメインの保護を確立し、レジリエンシーを高めています。 この構成では、クラスタ内のあらゆるデータノードからすべてのデータベースアクセスメソッドを使用することができます。大規模な SQL テーブルのデータは、すべてのノード間で物理的に分割されているため、クエリ処理とデータ量の両方を大規模に並列化できます。これらすべての機能を組み合わせることで、大規模な分析 SQL クエリの実行と新しいデータの同時取り込みなどのあらゆる複雑なハイブリッドワークロードを単一の InterSystems IRIS データプラットフォーム内でサポートできるようになります。   図 2.4.1-a：高可用性を備えたシャードクラスタを使用した本番環境構成のサンプル     上の図と下のテーブルの「リソースタイプ」列にある「EC2」とは、このドキュメントのセクション 3.1 で説明されている AWS 仮想サーバーインスタンスを表す AWS の用語です。 第 9 章で説明されているクラスタアーキテクチャでの「計算ノード」の使用を表したり暗示するものではありません。 以下の AWS VPC 内のリソースは、シャードクラスタをサポートするための最小推奨要件です。AWS リソースは必要に応じて追加または削除することができます。    シャードクラスタを使用した本番構成の AWS リソース 以下のテーブルは、シャードクラスタを使用した本番構成の AWS リソースのサンプルを示しています。 図 2.4.1-b: シャードクラスタを使用したサンプル本番環境構成の AWS リソースの表   * * *   クラウドの基礎概念 Amazon Web Services（AWS）は、IaaS（サービスとしてのインフラストラクチャ）向けの機能性豊かなクラウド環境を提供しています。新しい InterSystems IRIS データプラットフォームによるコンテナベースの開発運用など、InterSystems の全製品に完全に対応していますが、 あらゆるプラットフォームやデプロイモデルと同様に、パフォーマンス、可用性、システム運用、高可用性、災害復旧、セキュリティ制御、およびその他の管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。この記事では、Compute、Storage、および Networking という、すべてのクラウドデプロイの 3 つの主要コンポーネントについて説明します。   Compute Engine（仮想マシン） AWS EC2 内には、仮想 CPU とメモリの仕様と関連するストレージオプションを数多く備えた Compute Engine リソースで利用できるオプションがいくつかあります。AWS EC2 ではあるマシンタイプの vCPU 数を参照する場合、1 つの vCPU はハイパーバイザー層にある物理ホスト上の 1 つのハイパースレッドに等しいことに注意する必要があります。  このドキュメントでは m5* および r5* EC2 インスタンスタイプが使用されています。これらは、ほとんどの AWS デプロイリージョンで最も広く利用できるインスタンスです。ただし、大量のデータをメモリにキャッシュする非常に大型の作業データセットにおいては、非常に大きなメモリを備えた x1* のような他の特殊なインスタンスタイプか、NVMe ローカルインスタンスストレージを備えた i3* を使用することが望ましいです。 AWS のサービスレベル契約（SLA）に関する詳細については、こちらを参照してください。   ディスクストレージ InterSystems 製品に最も直接関係しているストレージタイプは永続ディスクタイプですが、データ可用性の制限を理解して対応できる場合はローカルストレージを使用して高度なパフォーマンスを実現することができます。 S3（バケット）や Elastic File Store（EFS）といったその他のオプションもいくつかありますが、それらは InterSystems IRIS データプラットフォームの運用をサポートするというよりも、個別のアプリケーションの要件に特化したオプションです。  ほかのほとんどのクラウドプロバイダと同様に、AWS でも各 Compute Engine に関連付けられる永続ストレージの容量に制限があります。これらの制限には、各ディスクの最大サイズ、各 Compute Engine に接続される永続ディスクの数量、永続ディスク当たりの IOPS 量と各 Compute Engine インスタンスの総合的な IOPS 限界などがあります。さらに、ディスク容量 1 GB あたりの IOPS 制限もあるため、希望する IOPS レートを得るには、より多くのディスク容量をプロビジョニングする必要があります。  これらの制限は時間の経過とともに変化する可能性があるため、適宜 AWS に確認する必要があります。 ディスクボリュームの永続ストレージタイプには、EBS gp2（SSD）、EBS st1（HDD）、EBS io1（SSD）の 3 種類があります。予測可能な低レイテンシ IOPS とより高いスループットを必要とする本番ワークロードには、標準の EBS gp2 ディスクがより適しています。標準永続ディスクはより経済的なオプションで、非本番環境の開発やテスト、またはアーカイブタイプのワークロードに適しています。  さまざまなディスクタイプと制限の詳細については、こちらを参照してください。   VPC ネットワーキング InterSystems IRIS データプラットフォームの多様なコンポーネントのサポートと共に、適切なネットワークセキュリティコントロール、各種ゲートウェイ、ルーティング、内部 IP アドレス割り当て、ネットワークインターフェース分離、およびアクセス制御を提供するには、仮想プライベートクラウド（VPC）ネットワークの使用が強く推奨されます。VPC の例は、このドキュメント内の例で詳しく説明します。 VPC ネットワーキングとファイアウォールの詳細については、こちらを参照してください。   * * * 仮想プライベートクラウド（VPC）の概要 AWS VPC の詳細は、こちらを参照してください。 ほとんどの大規模なクラウドデプロイでは、複数の VPC をプロビジョニングしてさまざまなゲートウェイタイプをアプリケーション中心の VPC から分離し、インバウンドとアウトバウンドの通信に VPC ピアリングを活用しています。 勤務先で使用されているサブネットと組織のファイアウォールルールの詳細について、ネットワーク管理者に相談することを強くお勧めします。VPC ピアリングについては、このドキュメントでは説明していません。 このドキュメントに含まれる例では、3 つのサブネットを持つ単一の VPC を使用してさまざまなコンポーネントのネットワークを分離し、予測可能なレイテンシと帯域幅、およびさまざまな InterSystems IRIS コンポーネントのセキュリティ分離を実現しています。  ### ネットワークゲートウェイとサブネットの定義 このドキュメントでは、インターネットとセキュア VPN 接続をサポートするために、2 つのゲートウェイを使用した例を示しています。アプリケーションに適度なセキュリティを提供するために、各イングレスアクセスには、適切なファイアウォールとルーティングのルールが必要です。VPC ルートテーブルの使用方法に関する詳細については、こちらを参照してください。 InterSystems IRIS データプラットフォームで使用するための専用のアーキテクチャ例では、3 つのサブネットが使用されています。これらの個別のネットワークサブネットとネットワークインターフェースを使用することで、セキュリティコントロールと帯域幅の保護に柔軟性を持たせ、上記 3 つの主要コンポーネントをそれぞれ監視することができます。複数のネットワークインターフェースを備えた仮想マシンインスタンスの作成に関する詳細は、こちらを参照してください。   これらの例には、次のサブネットが含まれます。 インバウンド接続ユーザーとクエリ用のユーザースペースネットワーク シャードノード間通信用のシャードネットワーク 各データノードの同期レプリケーションと自動フェイルオーバーを使用して高可用性を実現するミラーリングネットワーク    注意: フェイルオーバー同期データベースミラーリングは、単一の AWS リージョン内で相互接続のレイテンシが低い複数のゾーンでのみ推奨されます。 リージョン間のレイテンシは非常に高いことが通例であるため、特に更新が頻繁に行われるデプロイメントにおいては、良好なユーザーエクスペリエンスを提供することができません。   ### 内部ロードバランサー ほとんどの IaaS クラウドプロバイダーには、自動データベースフェイルオーバー設計で一般的に使用される仮想 IP（VIP）アドレスに対応できる能力が欠けています。 この問題を解決するため、ミラー対応と自動化を行う VIP 機能に依存しないよう、InterSystems IRIS 内では最も一般的に使用されるいくつかの接続方法（特に ECP クライアントや Web ゲートウェイ）が強化されています。  xDBC、TCP/IP ソケットによる直接接続などの接続方法や、その他の直接接続プロトコルについては VIP 同様のアドレスを使用する必要があります。このようなインバウンドプロトコルをサポートするために、InterSystems のデータベースミラーリング技術では、mirror_status.cxw というヘルスチェックステータスページを使って、それらの接続方法の自動フェイルオーバーを AWS 内で提供できるようになっています。VIP のようなロードバランサーの機能性を達成するためにロードバランサーと対話し、アクティブなプライマリメンバーにのみトラフィックをダイレクトすることで、完全かつ堅牢な高可用性設計を AWS 内で作り上げています。  AWS Elastic Load Balancer（ELB）の詳細は、こちらを参照してください。   図 4.2-a: 仮想IPアドレスなしの自動フェイルオーバー   ロードバランサーを使用して VIP 同様の機能を提供する方法の詳細については、こちらを参照してください。    VPC トポロジの例 以下の図 4.3-a では、すべてのコンポーネントを組み合わせて、次の特性を持つ VPC のレイアウトを示しています。 高可用性を得るために、リージョン内の複数のゾーンを活用する 災害復旧を可能にするために、2 つのリージョンを提供する ネットワーク分離を実施するために、複数のサブネットを使用する VPC ピアリング、インターネット、および VPN 接続用の個別のゲートウェイを含める ミラーメンバーが IP フェイルオーバーを行えるように、クラウドロードバランサーを使用する AWS では、各サブネットは完全に 1 つのアベイラビリティーゾーン内に存在する必要があり、ゾーンをまたがることはできません。 したがって、以下の例では、ネットワークセキュリティまたはルーティングルールを適切に定義する必要があります。 AWS の VPC とサブネットの詳細は、こちらを参照してください。 図 4.3-a: VPC ネットワークトポロジの例   * * * 永続ストレージの概要 概要で説明したように、AWS Elastic Block Store（EBS）ボリューム、特に EBS gp2 ボリュームタイプの使用をお勧めします。読み取りと書き込みの IOPS レートがより高く、トランザクションと分析用のデータベースワークロードに必要なレイテンシが低いため、EBS gp2 ボリュームが推奨されています。特定の状況で ローカル SSD を使用できることもありますが、ローカル SSD のパフォーマンス向上には、可用性、耐久性、および柔軟性のトレードオフが伴うことに注意してください。  ローカル SSD データ永続性の詳細については、こちらを参照してください。ローカル SSD データが保持される場合とされない場合を理解することができます。   LVM PE ストライピング ほかのクラウドプロバイダと同様に、AWS においても、IOPS、容量、および仮想マシンインスタンス当たりのデバイス数に関してストレージに対する制限を課しています。AWS のドキュメントで現在の制限を確認してください。こちらから参照できます。 このような制限があるため、データベースインスタンスの単一ディスクデバイスの IOPS を超えて IOPS を最大化するには、LVM のストライピングが必要となります。提供されている仮想マシンインスタンスの例では、以下のディスクレイアウトが推奨されています。SSD 永続ディスクに関連するパフォーマンス制限については、こちらを参照してください。   注意: 現在は Linux EC2 インスタンスごとに最大 40 個の EBS ボリュームがありますが、AWS のリソース能力は頻繁に変更されますので、最新の制限については AWS のドキュメントを参照するようにしてください。   図 5.1-a: LVM ボリュームグループ割り当ての例   LVM ストライピングのメリットによって、ランダムな IO ワークロードをより多くのデバイスに分散し、ディスクキューを継承することができます。以下は、データベースボリュームグループに対して、Linux で LVM ストライピングを使用する方法の例を示しています。この例では、物理エクステント（PE）サイズが 4 MB の LVM PE ストライプで 4 つのディスクを使用しています。または、必要に応じてより大きな PE サイズを使用することもできます。   手順 1: 必要に応じて標準または SSD 永続ディスクを作成します。 手順 2: “lsblk -do NAME,SCHED” を使用し、各ディスクデバイスの IO スケジューラが NOOP であることを確認します。 手順 3: “lsblk -do KNAME,TYPE,SIZE,MODEL” を使用し、ディスクデバイスを識別します。 手順 4: 新しいディスクデバイスでボリュームグループを作成します。 vgcreate s 4M    例: <span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span> 手順 4: 論理ボリュームを作成します。 lvcreate n -L -i -I 4MB 例: <i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i> 手順 5: ファイルシステムを作成します。 mkfs.xfs K 例: <i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i> 手順 6: ファイルシステムをマウントします。 次のマウントエントリで /etc/fstab を編集します。 /dev/mapper/vg_iris_db-lv_irisdb01    /vol-iris/db    xfs defaults 0 0 mount /vol-iris/db 上記の表を使用すると、各 InterSystems IRIS サーバーに、SYS 用ディスク 2 個、DB 用ディスク 4 個、プライマリジャーナル用ディスク 2 個、および代替ジャーナル用ディスク 2 個を備えた以下の構成が作られます。   図 5.1-b: InterSystems IRIS の LVM 構成     LVM では運用を中断することなく、必要に応じてデバイスと論理ボリュームを拡張できます。LVM ボリュームの継続的な管理と拡張のベストプラクティスについては、Linux のドキュメントを参照してください。   注意: データベースと書き込みイメージジャーナルファイルの両方で非同期 IO を有効にすることを強くお勧めします。Linux での有効化に関する詳細については、コミュニティの記事を参照してください。   * * * ## プロビジョニング InterSystems IRIS には InterSystems Cloud Manager（ICM）という新しいツールがあります。ICM は多くのタスクを実行し、InterSystems IRIS データプラットフォームをプロビジョニングするためのオプションを多数提供しています。 ICM は Docker イメージとして提供され、堅牢な AWS クラウドベースのソリューションをプロビジョニングするために必要なすべての機能を含んでいます。 ICM は現在、以下のプラットフォームでのプロビジョニングをサポートしています。 GovCloud を含む Amazon Web Services（AWS / GovCloud） Google Cloud Platform（GCP） Government を含む Microsoft Azure Resource Manager（ARM / MAG） VMware vSphere（ESXi） ICM と Docker は、デスクトップ/ノートパソコンのワークステーションから実行することも、小規模な専用の集中型「プロビジョニング」サーバーと集中型リポジトリを持つことも可能です。  アプリケーションのライフサイクルにおける ICM の役割は、 定義 -> プロビジョン -> デプロイ -> 管理です。 ICM のインストールと Docker との使用に関する詳細は、こちらを参照してください。   注意: クラウドのデプロイでは、ICM を使用する必要はありません。tar 形式の配布物を使用する従来のインストールとデプロイの方法は完全にサポートされており、利用できます。ただし、クラウドのデプロイでプロビジョニングと管理を容易にするため、ICM の使用をお勧めします。   コンテナの監視 ICM には、コンテナベースの手プロ委に適した 2 つの基本的な監視機能（Rancher および Weave Scope）が含まれています。 どちらもデフォルトではデプロイされないため、defaults ファイルの Monitor フィールドを使用して指定する必要があります。ICM を使用した監視、オーケストレーション、およびスケジューリングに関する詳細は、こちらを参照してください。   Rancher の概要とドキュメントは、こちらを参照してください。 Weave Scope の概要とドキュメントは、こちらを参照してください。 * * * 高可用性 InterSystems のデータベースミラーリングは、あらゆるクラウド環境で最も高度な可用性を提供します。AWS は単一の EC2 インスタンスに対する可用性を保証していないため、データベースをミラーリングするには、負荷分散や自動スケールグループと組み合わせることもできるデータベース層が必要です。  前の方のセクションでは、クラウドロードバランサーがデータベースミラーリングを使用して仮想 IP（VIP のような）機能に自動 IP アドレスフェイルオーバーを提供する方法について説明しました。クラウドロードバランサーは、前の「内部ロードバランサー」セクションで述べた mirror_status.cxw というヘルスチェックステータスページを使用します。データベースミラーリングには、自動フェイルオーバー付きの同期ミラーリングと非同期ミラーリングとうい 2 つのモードがありますが、この例では、同期フェイルオーバーミラーリングについて説明しています。ミラーリングの詳細については、こちらを参照してください。 最も基本的なミラーリング構成は、アービター制御構成で一組のフェイルオーバーミラーメンバーを使用する構成です。アービターは同一リージョン内の 3 番目のゾーンに配置されており、アービターと片方のミラーメンバーに影響を与える可能性のあるアベイラビリティーゾーンの停止を防いでいます。 ネットワーク構成でミラーリングをセットアップする方法はたくさんありますが、この例では、このドキュメントの「ネットワークゲートウェイとサブネットの定義」セクションで定義したネットワークサブネットを使用します。IP アドレススキームの例は以下のセクションで提供しています。このセクションでは、ネットワークインターフェースと指定されたサブネットについてのみ示しています。   図 7-a: アービターを使用したミラー構成のサンプル   * * * 災害復旧 InterSystems のデータベースミラーリングは、高可用性機能を拡張することで、別の AWS 地理的リージョンへの災害復旧もサポートし、AWS の全リージョンがオフラインになるという万が一の事態に備え、運営のリジリエンシーをサポートします。アプリケーションがそのような停止にどのようにして耐えるかは、目標復旧時間（RTO）と目標復旧ポイント（RPO）によって異なります。これらは、適切な災害復旧計画を作成するために必要な分析の初期フレームを提供するものです。以下のリンクでは、アプリケーションの災害復旧計画を作成する際に検討すべき項目のガイドが提供されています。 https://aws.amazon.com/disaster-recovery/   非同期データベースミラーリング InterSystems IRIS データプラットフォームのデータベースミラーリングは、AWS アベイラビリティーゾーンとリージョン間のデータレプリケーションを非同期に実行する堅牢な機能を提供しているため、災害復旧計画の RTO と RPO の目標をサポートする上で役立ちます。非同期ミラーメンバーの詳細については、こちらを参照してください。 前の高可用性のセクションと同様に、クラウドロードバランサーは、自動 IP アドレスフェイルオーバーを仮想 IP（VIP のような）機能に提供して、前の「内部ロードバランサー」セクションで述べたのと同じ mirror_status.cxw ヘルスチェックステータスページを使用してDR 非同期ミラーリングも提供することができます。 この例では、InterSystems IRIS のデプロイが動作しているアベイラビリティーゾーンやリージョンに関係なく、上流システムとクライアントワークステーションに単一の DNS アドレスを提供する AWS Route53 DNS サービスの導入とともに DR 非同期フェイルオーバーミラーリングがカバーされるようになります。 AWS Route53 の詳細は、こちらを参照してください。   図 8.1-a: AWS Route53 でのDR非同期ミラーリングのサンプル   上の例では、InterSystems IRIS インスタンスのフロントエンドである両方のリージョンの Elastic Load Balancer（ELB）の IP アドレスに Route53 が提供されており、アベイラビリティーゾーンやリージョンに関係なく、有効なプライマリミラーであるミラーメンバーにのみトラフィックが転送されるようになります。   * * * ## シャードクラスタ InterSystems IRIS には包括的な機能セットが含まれており、ワークロードの性質とワークロードが直面している特定のパフォーマンスの課題に応じて、単独または組み合わせて適用できます。 機能セットの 1 つであるシャーディングは、データとその関連するキャッシュの両方を複数のサーバーに分割することで、クエリとデータの取り込みを行うための柔軟で安価なパフォーマンスの拡張を行いながら、リソースを非常に効率的に利用することで、インフラストラクチャの価値を最大化することができます。 InterSystems IRIS のシャードクラスタは、広範なアプリケーション、特に以下の 1 つ以上の項目を含むワークロードを使用するアプリケーションに、大きなパフォーマンスのメリットを提供できます。 大量または高速なデータの取り込み、またはその両方。 比較的大規模なデータセット、大量のデータを返すクエリ、またはその両方。 ディスク上の大量のデータをスキャンしたり、大規模な計算作業を必要としたりする、大量のデータ処理を行う複雑なクエリ。 このような要因は、それ自体がシャーディングから得られる潜在的なメリットに影響を与えますが、これらを組み合わせた場合はさらにメリットが高まる可能性があります。 たとえば、大量データの迅速な取り込み、大規模なデータセット、および大量のデータを取得して処理する複雑なクエリという 3 つのすべての要因が組み合わさった場合、今日の分析ワークロードの多くでシャーディングを利用する価値が非常に高くなります。 これらの特性はすべてデータに関係しています。InterSystems IRIS のシャーディングの主な機能は、データボリュームに対して拡張することだからです。 ただし、シャードクラスタには、一部またはすべてのデータ関連の要因が伴うワークロードで、多数のユーザーから非常に高いクエリ量が発生する場合に、ユーザーのボリュームに合わせて拡張する機能も含められます。 シャーディングは、垂直スケーリングと組み合わせることもできます。   運用の概要   シャードアーキテクチャの目的は、データとそれに関連するキャッシュを複数のシステム間で分割することにあります。 シャードクラスタは、データノードと呼ばれる複数の InterSystems IRIS インスタンス間で、大量のデータベーステーブルを物理的に水平に（行ごとに）分割します。その一方で、アプリケーションが任意のノードを介してこれらのテーブルに透過的にアクセスし、1 つの論理的な結合としてデータセット全体を捉えられるようにします。 このアーキテクチャには、次の 3 つのメリットがあります。   並列処理 クエリは、データノードで並列に実行され、結果は、アプリケーションが接続されたノードによってマージ、結合され、完全なクエリ結果としてアプリケーションに返されます。多くの場合、実行速度が大幅に改善されます。 分割されたキャッシュ 単一のインスタンスのキャッシュをデータセット全体で使用するのではなく、各ノードにそれが格納するシャーディングされたテーブルのデータ分割専用の独自キャッシュがあります。そのため、キャッシュのオーバーフローやパフォーマンスを低下するディスク読み取りのリスクが大幅に軽減されます。 並列読み込み データをデータノードに並列に読み込めるため、取り込みワークロードとクエリワークロード間のキャッシュとディスクの競合が緩和され、両者のパフォーマンスが改善されます。   InterSystems IRIS のシャードクラスタの詳細については、こちらを参照してください。   シャーディングの要素とインスタンスタイプ シャードクラスタは、少なくとも 1 つのデータノードと、特定のパフォーマンスやワークロード要件に必要な場合は、オプションの数の計算ノードで構成されます。 これら 2 つのノードタイプは単純なビルディングブロックで、シンプルで透過的かつ効果的なスケーリングモデルを提供しています。   データノード データノードはデータを格納します。 物理レベルでは、シャーディングされたテーブル [1] のデータはクラスタ内のすべてのデータノードに分散され、シャーディングされていないテーブルのデータは、最初のデータノードのみに物理的に格納されます。 この区別は、ユーザーに透過的です。最初のノードのストレージ消費量はほかのノードに比べてわずかに高いことがあるという唯一の例外がありますが、シャーディングされたテーブルデータは通常、シャーディングされていないテーブルデータをわずかに上回る程度であるめ、この差は無視することができます。 シャーディングされたテーブルデータは、必要に応じて、通常は新しいデータノードを追加した後で、クラスタ全体で再調整できます。 この調整により、分散するデータが均等になるようにノード間でデータの「バケツ」が移動されます。 論理レベルでは、シャーディングされていないテーブルデータとシャーディングされたテーブルのすべてのデータの結合はあらゆるノードから可視状態であるため、クライアントは接続しているノードに関係なく、データセット全体を見ることができます。 メタデータとコードも、すべてのデータノードで共有されます。 シャードクラスタの基本的なアーキテクチャ図は、クラスタ全体で均一に見えるデータノードで構成されています。 クライアントアプリケーションは、任意のノードに接続でき、データがローカルであるかのように処理されます。   図 9.2.1-a: 基本的なシャードクラスタの図   [1] 便宜上、ドキュメントを通して「シャーディングされたテーブルデータ」という用語によって、シャーディングとしてマークされる、シャーディングをサポートするデータモデルの「エクステント」データを表しています。 「シャーディングされていないテーブルデータ」と「シャーディングされていないデータ」は、シャーディング可能なエクステントにあり、そのようにマークされていないデータ、またはシャーディングをまだサポートしていないデータモデルのデータを指します。   計算ノード 低レイテンシが必要となる高度なシナリオでは、潜在的にデータの一定した流入が発生する可能性があるため、クエリを処理するための透過的なキャッシング層を提供するために計算ノードを追加することができます。 計算ノードはデータをキャッシュします。 各計算ノードは、対応するシャーディングされたテーブルデータをキャッシュするデータノードに関連付けられています。さらに、そのデータに加え、クエリを満たすために必要に応じてシャーディングされていないテーブルデータもキャッシュします。   図 9.2.2-a: 計算ノードを含むシャードクラスタ   計算ノードは物理的にデータを格納せず、クエリ実行をサポートすることを目的としているため、メモリと CPU に重点を置いてストレージを最小限に抑えるなどによって、そのハードウェアプロファイルをニーズに合わせて調整することができます。 取り込みは、ドライバー（xDBC、Spark）で直接、または計算ノードで「ベア」アプリケーションコードが実行されるときにシャーディングマネージャーコードによって暗黙的にデータノードに転送されます。   シャードクラスタの図説 シャードクラスタのデプロイにはさまざまな組み合わせがあります。以下の概要図は、最も一般的なデプロイメントモデルを説明しています。これらの図には、ネットワークゲートウェイと詳細は含まれておらず、シャードクラスタコンポーネントのみに焦点が当てられています。   基本的なシャードクラスタ 以下の図は、単一のリージョンと単一のゾーンにデプロイされた 4 つのデータノードを持つ最も単純なシャードクラスタです。クライアント接続をシャードクラスタノードに分散するために、AWS Elastic Load Balancer（ELB）が使用されています。   図 9.3.1-a: 基本的なシャードクラスタ        この基本モデルでは、単一の仮想マシンとそれに接続された SSD 永続ストレージに AWS が提供するものを超えるレジリエンシーや高可用性は提供されていません。インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィックとシャードクラスタ通信間の帯域幅分離の両方を実現するには、2 つのネットワークインターフェースアダプターを個別に用意することをお勧めします。   高可用性を備えた基本的なシャードクラスタ 以下の図は、単一のリージョンにデプロイされた 4 つのミラーデータノードとゾーン間で分岐した各ノードのミラーを持つ最も単純なシャードクラスタです。クライアント接続をシャードクラスタノードに分散するために、AWS Load Balancer が使用されています。  高可用性は、リージョン内のセカンダリゾーンで同期的に複製されたミラーを維持する InterSystems のデータベースミラーリングを使用して提供されています。 インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィック、シャードクラスタ通信、およびノードペア間の同期ミラートラフィック間の帯域幅分離を実現するには、3 つのネットワークインターフェースアダプターを個別に用意することをお勧めします。   図 9.3.2-a: 高可用性を備えた基本的なシャードクラスタ      このデプロイモデルでは、この記事の前のセクションで説明したミラーアービターも導入されています。     個別の計算ノードを持つシャードクラスタ 以下の図は、大規模なユーザー/クエリ同時実行向けに、個別の計算ノードと 4 つのデータノードを持つシャードクラスタを拡張しています。Cloud Load Balancer サーバープールには、計算ノードのアドレスのみが含まれます。更新とデータの取り込みは、以前と同様にデータノードに直接更新され続け、超低レイテンシパフォーマンスを維持し、リアルタイムデータ取り込みによるクエリ/分析ワークロード間のリソースの干渉と輻輳を回避します。 このモデルでは、計算/クエリと取り込みを個別にスケーリングできるようにリソースの割り当てを微調整することで、計算またはデータをスケーリングするためだけにリソースを不要に無駄にする代わりに、必要なときに「ジャストインタイム」でリソースを最適化し、経済的でありながらも単純なソリューションを維持することができます。  計算ノードは AWS 自動スケールグループ（自動スケーリング）を非常に簡単に使用できるため、負荷の増減に基づいて、管理されたインスタンスグループへのインスタンスの追加または削除を自動的に実行することができます。 自動スケーリングは、負荷が高まるとインスタンスグループにインスタンスを追加し（アップスケーリング）、インスタンスのニーズが低下するとインスタンスを削除（ダウンスケーリング）します。 AWS 自動スケーリングの詳細については、こちらを参照してください。   図 9.3.3-a: 計算ノードとデータノードが分離されたシャードクラスタ     自動スケーリングを使用すると、クラウドベースのアプリケーションは、トラフィックの増加を適切に処理し、リソースのニーズが低下するとコストを削減するのに役立ちます。 ポリシーを定義するだけで、オートスケーラーは測定された負荷に基づいて自動的にスケーリングを実行します。   * * *   バックアップ操作 バックアップ操作には、いくつかのオプションがあります。InterSystems IRIS を使用した AWS デプロイでは、次の 3 つのオプションを使用できます。 最初の 2 つのオプションは、以下で説明するとおり、スナップショットを作成する前にデータベースによるディスクへの書き込みを一時停止し、スナップショットに成功したら更新を再開するというスナップショットタイプの手順を使用しています。 いずれかのスナップショット方式を使用してクリーンなバックアップを作成するには、次のおおまかな手順を実行します。 データベースの External Freeze API を呼び出し、データベースへの書き込みを一時停止する。 OS とデータディスクのスナップショットを作成する。 External Thaw API を呼び出し、データベースの書き込みを再開する。 バックアップファシリティがバックアップ場所にアーカイブする。 External Freeze/Thaw API に関する詳細は、こちらを参照してください。   注意: このドキュメントにはバックアップのサンプルスクリプトは含まれていませんが、InterSystems 開発者コミュニティに掲載される例を定期的に確認してください。 www.community.intersystems.com   3 つ目のオプションは、InterSystems Online のバックアップです。これは、非常にシンプルな使用事例とインターフェースを備えたより小規模なデプロイメント向けのエントリーレベルのアプローチです。ただし、データベースのサイズが大きくなるにつれ、スナップショットテクノロジーを使った外部バックアップがベストプラクティスとして推奨されます。外部ファイルのバックアップ、より高速な復元時間、エンタープライズ全体のデータビューと管理ツールなどのメリットがあります。  クリーンで一貫したバックアップを確保するために、整合性チェックなどの追加手順を定期的に追加することができます。 どのオプションを使用するかは、組織の運用要件とポリシーによって決まります。さまざまなオプションをさらに詳しく検討するには、InterSystems にご相談ください。   AWS Elastic Block Store（EBS）スナップショットのバックアップ バックアップ操作は、AWS CLI コマンドライン API と InterSystems External Freeze/Thaw API 機能を使用して実行できます。 これにより、実質的に 24 時間 365 日の運用レジリエンシーとクリーンな定期バックアップを実現できます。AWS EBS スナップショットの管理と作成および自動化の詳細については、こちらを参照してください。   論理ボリュームマネージャー（LVM）のスナップショット 別の方法として、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VMそのものにバックアップエージェントを展開し、論理ボリュームマネージャ（LVM）のスナップショットと組み合わせてファイルレベルのバックアップを活用することができます。 このモデルには、Windows または Linux ベースの VM をファイルレベルで復元できるというメリットがあります。このソリューションで注意すべき点は、AWS やほとんどの IaaS クラウドプロバイダはテープメディアを提供しないため、すべてのバックアップリポジトリは、短期アーカイブ用のディスクベースであり、長期保管（LTR）には BLOB またはバケットタイプの低コストストレージを活用できるということです。このモデルを使用する場合は、ディスクベースのバックアップリポジトリを最も効率的に使用できるように、重複除去テクノロジーをサポートするバックアップ製品を使用することを強くお勧めします。 こういったクラウド対応のバックアップ製品には、Commvault、EMC Networker、HPE Data Protector、Veritas Netbackup などさまざまな製品があります。InterSystems では、これらの製品の比較検証や推奨は行っておりません。   Online Backup 小規模なデプロイでは、組み込みの Online Backup ファシリティもオプションとして考えられます。InterSystems のデータベースオンラインバックアップユーティリティは、データベース内のすべてのブロックをキャプチャしてデータベースファイルにデータをバックアップし、出力をシーケンシャルファイルに書き込みます。 この、InterSystems 独自のバックアップメカニズムは、本番システムのユーザーにダウンタイムを引き起こさないように設計されています。 Online Backup の詳細については、こちらを参照してください。 AWS では、オンラインバックアップが完了した後、バックアップ出力ファイルとシステムで使用中のほかのすべてのファイルを、その仮想マシンインスタンスの外部にあるほかのストレージの場所にコピーする必要があります。これには、バケット/オブジェクトストレージが適しています。   AWS Single Storage Space（S3）バケットを使用するには、2 つのオプションがあります。  AWS CLI スクリプト API を直接使用して、新しく作成したオンラインバックアップ（とほかの非データベース）ファイルをコピーして操作する。 詳細については、こちらを参照してください。 Elastic File Store（EFS）ボリュームをマウントし、永続ディスクと同様に低コストで使用する。 EFS の詳細は、こちらを参照してください。   * * *    

開発者の皆さんこんにちは！IRIS プログラミングコンテストも 6 回目を迎えました！ 今回のコンテストのテーマは 「InterSystems IRIS をバックエンドとし Web またはモバイル・ソリューションをフロントエンドとして使用する⚡️フル・スタック・アプリケーション⚡️」 です。日本からのご応募お待ちしております！ Open Exchange（アプリケーション登録／参考となる開発テンプレート）のページはこちら➡　⚡️ InterSystems Full Stack Contest ⚡️ 応募期間は 2020年9月21日～10月4日 です！ （投票期間は 2020年10月5日～11日、勝者発表は 10月12日を予定しています） 優勝特典 １、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 1位 - $2,000 🥈 2位 - $1,000 🥉 3位 - $500 2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。 🥇 1位 - $1,000 🥈 2位 - $500 複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。 参加資格 どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます） コンテストのスケジュール 9月21日～10月4日 応募期間（Open Exchange へ作成されたアプリケーションをアップロードいただける期間＝2週間です。この期間内であればアップロード後も自由に編集できます。） 10月5日～11日 投票（1週間） 10月12日 優秀者発表（US時間に発表します） コンテストのテーマ 💡 フル・スタック・アプリケーション 💡 InterSystems IRIS を使用したフルスタック・ソリューションを開発します。 フルスタックとは、REST API、Native API、JDBC、IRIS Web Gateway を介して InterSystems IRIS のデータを使用する Web またはモバイルのフロントエンド・アプリケーションを意味します。 アプリケーションは、IRIS Community Edition、IRIS for Health Community Edition、IRIS Advanced Analytics Community Edition のいずれかで動作する必要があります。 また、アプリケーションはオープンソースで、GitHub で公開いただきます。 アプリケーションに特別な技術実装を導入した場合は技術的なボーナスがあります。ボーナスの詳細については後日発表します！ Helpful resources 1. 以下の InterSystems IRIS を含む開発テンプレート（コンテナ）は、フル・スタックアプリケーションに適した開発環境を簡単に準備できます。 Basic InterSystems IRIS Docker template IRIS REST API template Native API template IntegratedML template IRIS Analytics template 2. コンテスト応募方法（このページ末尾のビデオをご参照ください） 3. オンラインコース（英語） Implementing RESTful Applications 4. ビデオ（英語） REST API design and Development REST API in 5 minutes Data-Driven Web Apps 5. ビデオ（日本語） 開発テンプレートで準備されるRESTサーバ作成環境について （ビデオの13分以降をご参照ください） IRIS で作成する REST サーバの仕組み 手動によるRESTディスパッチクラスの作成 APIファーストによるRESTディスパッチクラスの作成 IRISでのJSON操作 審査及び投票ルール（英語） インターシステムズ社のプロダクトマネージャ、Developer Communityのモデレータ、グローバルマスターアドボケイト（VIPレベル）等、Developer Community 内での投票も行われます。 コンテストの審査および投票ルールについて詳細はこちらをご覧ください。 ご応募方法について 以下の応募方法ビデオをご参照ください。 以下、コンテストに応募する迄の手順をご説明します。 コンテスト応募までの流れは以下の通りです（※ビデオでは、3番以降の内容をご紹介しています）。 1、IRISプログラミングコンテスト用テンプレートを使用して、開発環境を準備します。 2、コンテスト用アプリケーションを作成します。 3、コンテストの準備が完了したら、ソースコードをローカルのGitリポジトリへコミットします。 初回コミット時に、Gitの初期設定がないためコミットが失敗することがあります。その場合は、以下のコマンドでGitユーザ名とEmailを設定します。 git config --global user.name "ここにユーザ名"git config --global user.email "ここにメールアドレス” 4、ローカルのGitリポジトリのコミットが完了したら、リモートのGitリポジトリを作成します。 リポジトリ作成後、リモートリポジトリのURLをコピーします。 5、リモートのGitリポジトリへPushします。 git push ここにリモートのリポジトリのURL 6、OpenExchangeにログインし、アプリケーションを追加します。 ※事前にDeveloper communityでユーザアカウントを作成する必要があります。ログイン後、Profile→Applications　から　Application　をクリックし、4 でコピーしたリモートのGitリポジトリのURLを設定します。アプリケーションを登録すると、画面右上に「Send Approval」のボタンが表示されるので、クリックします。再度作成したアプリケーションを開くと、「Apply for Contest」ボタンが表示されるので、クリックすると応募が完了します。 皆さん、こんにちは！ コンテスト応募締め切りまで残り4日となりましたが、FullStack用開発テンプレート が追加されました！ 詳細は、日本語Readme をぜひご参照ください！ ↓以下、Readme の内容を一部ご紹介します↓ このリポジトリは「coffee-maker shop」デモ用の InterSystems IRIS REST API とフロントエンドアプリケーションで構成されたサンプルアプリケーションです。 このデモを通して、フロントエンドアプリケーションから InterSystems IRIS への接続方法がご確認いただけます。 リポジトリには、ユニットテストコードも含まれていて、インタラクティブに実行できるほか、ZPM を使ったり、GitHub CI（GitHub Actions) を介して実行することもできます。 Docker コンテナを使った開発方法のデモも含まれています また、ZPM モジュールでアプリケーションをパッケージ化する方法、ZPM を使ってデプロイする方法も含まれています。

皆さんこんにちは。 第5回 InterSystems IRIS プログラミングコンテスト（FHIRコンテスト） への応募は終了しました。コンテストへのご参加、またご興味をお持ちいただきありがとうございました。 今回のお知らせでは、見事受賞されたアプリケーションと開発者の方々を発表します！ 🏆 審査員賞　- 特別に選ばれた審査員から最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,500 は iris-fhir-portal を開発された Henrique Gonçalves Dias さんに贈られました！ 🥇 1位 - $1,500 は iris4health-fhir-analytics を開発された José Roberto Pereira さんに贈られました！ 🥉 3位 - $500 は fhir-chatbot を開発された Renato Banzai さんに贈られました！ 🏆 開発者コミュニティ賞　- 最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,000 は iris-fhir-portal を開発された Henrique Gonçalves Dias さんに贈られました！ 🥈 2位 - $500 は iris4health-fhir-analytics を開発された José Roberto Pereira さんに贈られました！ 🎊 受賞者の皆様、おめでとうございます！👏 このエキサイティングなプログラミングコンテストにご注目いただき、また開発いただきありがとうございました！ 見事 🥇 1位! に輝いた Henrique Gonçalves Dias さんの iris-fhir-portal についてですが、投票終了と同時にご本人による日本語の解説記事がUpされました！ Henriqueさん、ありがとうございます！　皆様、ぜひ、ご参照ください！ さて、次回はどんなコンテストでしょう？（全体スケジュールはこちらからご参照いただけます。） InterSystems IRIS プログラミングコンテストシリーズは、開発者の皆様をお待ちしております！ 次のコンテストは、まもなく発表されます。コンテスト最新情報のチェックもお忘れなく！

2023.2 の開発者プレビュープログラムの一環として、3番目の開発者プレビューを公開いたします。今回リリースされたのは、InterSystems IRIS と InterSystems IRIS for Health です。 本リリースの注目点 2023.2では、多くの機能修正と改善に加えて、時間認識モデリングや 強化された外部テーブル、読み込み専用の FEDERATED テーブルといった新機能が含まれる予定です。これら新機能の一部は、今回の開発者プレビュー版にはまだ含まれていません。ご注意ください。 2023.2の別の注目点は、プライベート・ウェブサーバ (PWS) がインストーラから削除されることです。このことは昨年に発表され、インターシステムズ製品のインストーラから削除予定ですが、今回のプレビュー版ではまだPWSは存在します。詳細はこちらのドキュメントをご覧ください。 --> PWSが含まれないインストーラにご興味のある方は、こちらのフォームからEAPに登録してください。その際、オプションで「No Private Web Server」をお選びください。このEAPに関する情報はこちらをご参照ください。 今後のプレビューリリースは、2週間ごとの発表を予定しており、新機能が完成次第、プレビュー版に追加されていきます。みなさまとよりよい製品にできるよう、ぜひ開発者コミュニティにみなさまのフィードバックをお寄せください。お待ちしております。 ドキュメントは以下のリンクからご覧いただけます。本バージョンが正式公開 (General Availability - GA) されるまで、数週間かけてドキュメントは更新される予定です。 InterSystems IRIS InterSystems IRIS for Health キットについて これまでと同じく、継続的デリバリ (CD) リリースは、すべてのサポート対象プラットフォーム向けに、従来のインストーラ形式と Docker コンテナ形式の両方でご提供します。サポート対象プラットフォーム一覧は、こちらのドキュメントをご覧ください。 インストーラとプレビュー用ライセンスキーは、WRC のプレビューダウンロードページ もしくは 評価サービスページ (2023.2を入手するには、"Show Preview Software" フラグをチェックしてください) から入手いただけます。 InterSystems IRIS / IRIS for Health の Enterprise Edition ならびに Community Edition、また関連コンポーネント、それら全てのコンテナイメージは、新しくなった InterSystems コンテナレジストリページから入手いただけます。docker コマンドに関する詳細な情報は、「InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ」の記事をご覧ください。 今回の開発者プレビューのビルド番号は 2023.2.0.202.0 です。 入手可能なイメージの一覧については, ICR に関するドキュメントをご覧ください。また、すべてのコンテナイメージの tarball 版は、WRC のプレビューダウンロードページから入手いただけます。

2023.2 の開発者プレビュープログラムの一環として、5番目の開発者プレビューを公開いたします。今回リリースされたのは、InterSystems IRIS と InterSystems IRIS for Health です。 本リリースの注目点 2023.2では、多くの機能修正と改善に加えて、時間認識モデリングや 強化された外部テーブル (まだ実験的な機能です) といった新機能が含まれる予定です。これら新機能の一部は、今回の開発者プレビュー版にはまだ含まれていません。ご注意ください。 2023.2の別の注目点は、プライベート・ウェブサーバ (PWS) がインストーラから削除されることです。このことは昨年に発表され、インターシステムズ製品のインストーラから削除予定ですが、今回のプレビュー版ではまだPWSは存在します。詳細はこちらのドキュメントをご覧ください。 --> PWSが含まれないインストーラにご興味のある方は、こちらのフォームからEAPに登録してください。その際、オプションで「No Private Web Server」をお選びください。このEAPに関する情報はこちらをご参照ください。 今後のプレビューリリースは、2週間ごとの発表を予定しており、新機能が完成次第、プレビュー版に追加されていきます。みなさまとよりよい製品にできるよう、ぜひ開発者コミュニティにみなさまのフィードバックをお寄せください。お待ちしております。 ドキュメントは以下のリンクからご覧いただけます。本バージョンが正式公開 (General Availability - GA) されるまで、数週間かけてドキュメントは更新される予定です。 InterSystems IRIS InterSystems IRIS for Health キットについて これまでと同じく、継続的デリバリ (CD) リリースは、すべてのサポート対象プラットフォーム向けに、従来のインストーラ形式と Docker コンテナ形式の両方でご提供します。サポート対象プラットフォーム一覧は、こちらのドキュメントをご覧ください。 インストーラとプレビュー用ライセンスキーは、WRC のプレビューダウンロードページ もしくは 評価サービスページ (2023.2を入手するには、"Show Preview Software" フラグをチェックしてください) から入手いただけます。 InterSystems IRIS / IRIS for Health の Enterprise Edition ならびに Community Edition、また関連コンポーネント、それら全てのコンテナイメージは、新しくなった InterSystems コンテナレジストリページから入手いただけます。docker コマンドに関する詳細な情報は、「InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ」の記事をご覧ください。 今回の開発者プレビューのビルド番号は 2023.2.0.210.0 です。 入手可能なイメージの一覧については, ICR に関するドキュメントをご覧ください。また、すべてのコンテナイメージの tarball 版は、WRC のプレビューダウンロードページから入手いただけます。

2023.2 の開発者プレビュープログラムの一環として、4番目の開発者プレビューを公開いたします。今回リリースされたのは、InterSystems IRIS と InterSystems IRIS for Health です。 本リリースの注目点 2023.2では、多くの機能修正と改善に加えて、時間認識モデリングや 強化された外部テーブル、読み込み専用の FEDERATED テーブルといった新機能が含まれる予定です。これら新機能の一部は、今回の開発者プレビュー版にはまだ含まれていません。ご注意ください。 2023.2の別の注目点は、プライベート・ウェブサーバ (PWS) がインストーラから削除されることです。このことは昨年に発表され、インターシステムズ製品のインストーラから削除予定ですが、今回のプレビュー版ではまだPWSは存在します。詳細はこちらのドキュメントをご覧ください。 --> PWSが含まれないインストーラにご興味のある方は、こちらのフォームからEAPに登録してください。その際、オプションで「No Private Web Server」をお選びください。このEAPに関する情報はこちらをご参照ください。 今後のプレビューリリースは、2週間ごとの発表を予定しており、新機能が完成次第、プレビュー版に追加されていきます。みなさまとよりよい製品にできるよう、ぜひ開発者コミュニティにみなさまのフィードバックをお寄せください。お待ちしております。 ドキュメントは以下のリンクからご覧いただけます。本バージョンが正式公開 (General Availability - GA) されるまで、数週間かけてドキュメントは更新される予定です。 InterSystems IRIS InterSystems IRIS for Health キットについて これまでと同じく、継続的デリバリ (CD) リリースは、すべてのサポート対象プラットフォーム向けに、従来のインストーラ形式と Docker コンテナ形式の両方でご提供します。サポート対象プラットフォーム一覧は、こちらのドキュメントをご覧ください。 インストーラとプレビュー用ライセンスキーは、WRC のプレビューダウンロードページ もしくは 評価サービスページ (2023.2を入手するには、"Show Preview Software" フラグをチェックしてください) から入手いただけます。 InterSystems IRIS / IRIS for Health の Enterprise Edition ならびに Community Edition、また関連コンポーネント、それら全てのコンテナイメージは、新しくなった InterSystems コンテナレジストリページから入手いただけます。docker コマンドに関する詳細な情報は、「InterSystemsコンテナレジストリ Webユーザインターフェースのお知らせ」の記事をご覧ください。 今回の開発者プレビューのビルド番号は 2023.2.0.204.0 です。 入手可能なイメージの一覧については, ICR に関するドキュメントをご覧ください。また、すべてのコンテナイメージの tarball 版は、WRC のプレビューダウンロードページから入手いただけます。

開発者の皆さん、こんにちは！ InterSystems 開発者コミュニティでは、2021/2/5（金）に、ウェビナーを開催致します。今回は、初めてインターシステムズのデータプラットフォーム製品をご覧になるソフトウェアエンジニアの方向けに、弊社のエンジニアが 30分でその特徴をご紹介します。 ウェビナー「InterSystems IRIS データプラットフォーム　概要」 日時：2021年2月5日（金）15：00～15：30 参加費：無料（事前登録制） 事前登録、ウェビナ配信はこちら(ON24を使用します）https://event.on24.com/wcc/r/2982378/17DE6BE0C44C34513F10A8D7C7B68FB0 以下のような開発者の方におすすめです。 初めてインターシステムズのデータプラットフォーム製品をお使いになる方、ご興味のある方 新しいデータプラットフォームを試してみたい方 Caché から IRIS への移行をご検討中の方 ぜひご視聴ください！

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。 この動画では、Caché/EnsembleからInterSystems IRISへの移行プロセスについてご説明しています。 Caché/Ensembleから InterSystems IRIS への移行を考えられている方は、まずこちらをご覧ください。「移行する際の注意点」、「移行の方法」、「必読ドキュメント」、「キットや評価ライセンスの入手方法」など、IRIS移行の際に必要となる情報をまとめてご案内しています。 もくじ 0:50～　InterSystemsIRIS の簡単な紹介 2:05～　サポートプラットフォームについて 2:55～　移行方法について（インプレース変換のご紹介）　　　　 ⇒インプレース変換：Caché/Ensembleから直接アップグレードが可能です(2016.2～) 5:35～　各種ドキュメントのご紹介 7:10～　キットや評価ライセンスの入手方法10:50～　新しいリリースサイクル(EM/CDリリース)12:25～　InterSystems IRIS 導入ガイドについて　　　　 ⇒レガシー機能の取り扱いや注意点など、内容を簡単にご紹介15:40～　インプレース変換の手順とデモ(デモは19:15～) 開発者向けまとめページでは、QuickStarts、ドキュメントや開発者コミュニティへのリンク、IRIS を簡単に始めることのできるクラウド（AWS／Azure／GCP）のマーケットプレイスへのリンクなどまとめています。こちらも是非ご覧ください。

 この記事には、IAM の基本概念を学習するための、教材、例、演習が含まれます。 すべてのリソースはこちらの git から入手できます: https://github.com/grongierisc/iam-training ソリューションは [training ブランチ](https://github.com/grongierisc/iam-training/tree/training)にあります。 この記事では、次の点について説明します。 - [1. 入門](#1-introduction) - [1.1. IAM とは？](#11-what-is-iam-) - [1.2. API 管理とは？](#12-what-is-an-api-management-) - [1.3. IAM ポータル](#13-iam-portal) - [1.4. このトレーニングの流れ](#14-flow-of-this-training) - [2. インストール](#2-installation) - [2.1. インストールには何が必要？](#21-what-do-you-need-to-install) - [2.2. IAM と IRIS の連携の仕組み](#22-how-iam-works-with-iris) - [2.3. セットアップ](#23-setup) - [2.4. IAM のインストール](#24-install-iam) - [2.4.1. Iris イメージ](#241-iris-image) - [2.4.2. IAM イメージ](#242-iam-image) - [2.4.3. Docker ファイルを更新する](#243-update-the-docker-file) - [2.4.4. docker-compose を更新する](#244-update-the-docker-compose) - [2.4.5. オプション: .env として IRIS_PASSWORD を追加する](#245-option--add-iris_passward-as-env) - [2.4.6. テストしよう！](#246-test-it-) - [3. その 1: サービス/ルート](#3-first-serviceroute) - [3.1. サービスを作成する](#31-create-a-service) - [3.2. ルートを作成する](#32-create-a-route) - [3.3. テストしよう！](#33-test-it-) - [4. その 2: プラグインの使用](#4-second-go-further-with-plugin) - [4.1. プラグインをサービスに追加する](#41-add-a-plugin-to-the-service) - [4.2. テストしよう！](#42-test-it-) - [5. その 3: 独自認証の追加](#5-third-add-our-own-authentication) - [5.1. コンシューマを追加する](#51-add-consumers) - [5.2. Basic 認証プラグインを追加する](#52-add-basic-auth-plugin) - [5.3. ACL プラグインを追加する](#53-add-acl-plugin) - [5.4. ACL とログイン情報で USER を構成する](#54-configure-user-with-acl-and-credentials) - [5.5. テストしよう！](#55-test-it-) - [6. 演習: レート制限](#6-exercice-rate-limiting) - [6.1. ソリューション](#61-solution) - [7. 開発者ポータル](#7-dev-portal) - [7.1. 概要](#71-overview) - [7.2. 有効にしよう！](#72-enable-it-) - [7.3. 最初の仕様を追加する](#73-add-your-first-spec) - [7.4. テストしよう！](#74-test-it-) - [7.5. 演習](#75-exercise) - [7.5.1. ソリューション](#751-solution) - [8. 開発者ポータル（その 2）: 認証](#8-dev-portal-part-two-authentication) - [8.1. Basic 認証を有効にする](#81-enable-basic-auth) - [8.2. アクセスを制限する](#82-limit-access) - [8.2.1. ロールを作成する](#821-create-a-role) - [8.2.2. 仕様にロールを追加する](#822-add-role-to-spec) - [8.2.3. テストしよう！](#823-test-it-) - [8.2.3.1. 新しい開発者を登録する](#8231-register-a-new-developer) - [8.2.3.2. この開発者を承認する](#8232-approve-this-developer) - [8.2.3.3. この開発者のロールを追加する](#8233-add-role-for-this-developer) - [8.3. 開発者の Oauth2 を追加する](#83-add-oauth2-for-developer) - [8.3.1. その 1: Basic 認証を削除する](#831-first-remove-basic-auth) - [8.3.2. その 2: application-registration プラグインを追加する](#832-second-add-application-registration-plugin) - [8.3.3. リンクサービスとドキュメント](#833-link-service-and-documentation) - [8.3.3.1. テストしよう！](#8331-test-it-) - [9. 安全な管理ポータル](#9-secure-management-portal) - [9.1. 管理者を作成する](#91-create-an-admin) - [9.2. Kong Manager の Basic 認証を有効にする](#92-enable-basic-auth-for-kong-manager) - [9.3. RBAC で Kong Admin API を使用する](#93-use-kong-admin-api-with-rbac) - [9.3.1. トークンで管理者ユーザーを作成する](#931-create-and-admin-user-with-a-token) - [10. プラグイン](#10-plugins) - [10.1. コミュニティプラグインをインポートする](#101-import-a-community-plugin) - [10.1.1. コミュニティプラグインで新しい Kong/IAM docker イメージを構築する](#1011-build-a-new-kongiam-docker-image-with-the-community-plugin) - [10.1.2. テストしよう！](#1012-test-it-) - [10.1.2.1. 使ってみよう！](#10121-use-it-) - [10.2. 新しいプラグインを作成する](#102-create-a-new-plugin) - [10.2.1. ファイル構造](#1021-file-structure) - [10.2.1.1. handler.lua](#10211-handlerlua) - [10.2.1.1.1. 例](#102111-example) - [10.2.1.2. schema.lua](#10212-schemalua) - [10.2.1.3. *.rockspec](#10213-rockspec) - [10.2.2. 構築しよう](#1022-build-it) - [10.2.3. ヒント](#1023-tips) - [11. CI/CD](#11-cicd) - [11.1. postman コレクションを作成する](#111-create-the-postman-collection) - [11.1.1. IAM が起動しているか](#1111-is-iam-startup-) - [11.1.2. 古いデータを削除する](#1112-delete-old-datas) - [11.1.3. サービス/ルートを作成する](#1113-create-serviceroute) - [11.1.3.1. ヒント](#11131-tips) - [11.2. newman で実行する](#112-run-it-with-newman) # 1. 入門  ## 1.1. IAM とは？ IAM は、InterSystems API Manager の略で、**Kong Enterprise Edition** が土台となっています。 このため、Kong Open Source エディションの他に、次の機能にアクセスすることができます。 * 管理者ポータル * 開発者ポータル * 高度プラグイン * Oauth2 * キャッシング * ...  ## 1.2. API 管理とは？ API 管理は、Web アプリケーションプログラミングインターフェース（API）の作成と公開、その使用ポリシーの適用、アクセスの制御、サブスクライバーコミュニティの育成、使用統計の収集と分析、およびパフォーマンスのレポート作成を行うプロセスです。 API 管理コンポーネントは、開発者とサブスクライバーのコミュニティをサポートする仕組みとツールをもたらします。  ## 1.3. IAM ポータル Kong と IAM は第一に API として設計されています。つまり、Kong/IAM で行われることすべては Rest 呼び出しまたは管理者ポータルで行えるということです。 この記事の中では、すべての例や演習は次のようにして提示されています。 | IAM ポータル | Rest API | | ----------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | |  |  | ## 1.4. このトレーニングの流れ この記事では、IAM を IRIS Rest API のプロキシとして使用することを狙いとしています。 この Rest API の定義は、次の場所にあります。 ```url http://localhost:52773/swagger-ui/index.html#/ ``` または次の場所にあります。 ```url https://github.com/grongierisc/iam-training/blob/training/misc/spec.yml ``` この記事は main ブランチから始めてください。 記事の最後に到達すると、training ブランチと同じ結果が得られるはずです。 # 2. インストール  ## 2.1. インストールには何が必要？ * [Git](https://git-scm.com/downloads) * [Docker](https://www.docker.com/products/docker-desktop)（Windows をお使いの方は、Docker インストールで「Linux コンテナ」が使用されるように設定してください）。 * [Docker Compose](https://docs.docker.com/compose/install/) * [Visual Studio Code](https://code.visualstudio.com/download) と [InterSystems ObjectScript VSCode 拡張機能](https://marketplace.visualstudio.com/items?itemName=daimor.vscode-objectscript) * InterSystems IRIS IAM 対応のライセンスファイル * IAM Docker イメージ ## 2.2. IAM と IRIS の連携の仕組み Kong/IAM の起動時に、コンテナは curl 呼び出しによって、Kong/IAM のライセンスをチェックします。 この呼び出しのエンドポイントは、IRIS コンテナの Rest API です。 参考: Kong ライセンスは IRIS のライセンスに組み込まれています。  ## 2.3. セットアップ Git clone によって、次のリポジトリのクローンを作成します。 git clone https://github.com/grongierisc/iam-training 次のようにして、最初の Rest API を実行します。 docker-compose up テストを行います。 ```url http://localhost:52773/swagger-ui/index.html#/ ``` ログイン/パスワード: SuperUser/SYS ## 2.4. IAM のインストール ### 2.4.1. Iris イメージ まず、Community エディションをライセンスエディションに切り替える必要があります。 これを行うには、InterSystems Container Registry へのアクセスをセットアップして、アクセス制限付きの IRIS イメージをダウンロードする必要があります。 [開発者コミュニティ](https://jp.community.intersystems.com)の「[InterSystems Container Registry のご紹介](https://jp.community.intersystems.com/node/496571)」をご覧ください。 * WRC ログイン情報を使って https://containers.intersystems.com/ にログインし、*トークン*を取得します。 * コンピュータに Docker ログインをセットアップします。 ```bash docker login -u="user" -p="token" containers.intersystems.com ``` * InterSystems IRIS イメージを取得します。 ```bash docker pull containers.intersystems.com/intersystems/irishealth:2020.4.0.524.0 ``` ### 2.4.2. IAM イメージ [WRC Software Distribution](https://wrc.intersystems.com/wrc/coDistribution.csp) を使用します。 * コンポーネント > ダウンロードに移動して *IAM-1.5.0.9-4.tar.gz* ファイルをダウンロードし、解凍（unzip & untar）してイメージを読み込みます。 ```bash docker load -i iam_image.tar ``` ### 2.4.3. Docker ファイルを更新する IRIS Community エディションをライセンスエディションに変更します。 * containers.intersystems.com/intersystems/irishealth:2020.4.0.524.0 * key フォルダにある iris.key を追加します。 dockerfile を編集して、その上に次の部分を追加します。 ```dockerfile ARG IMAGE=containers.intersystems.com/intersystems/irishealth:2020.4.0.524.0 # 第 1 ステージ FROM $IMAGE as iris-iam COPY key/iris.key /usr/irissys/mgr/iris.key COPY iris-iam.script /tmp/iris-iam.script RUN iris start IRIS \ && iris session IRIS < /tmp/iris-iam.script \ && iris stop IRIS quietly # 第 2 ステージ FROM iris-iam ``` この部分では、マルチステージの dockerfile を作成します。 * 第 1 ステージでは、IRIS が IAM ライセンスを提供できるようにします。 * 第 2 ステージは、REST API ビルド用です。 新しい IRIS イメージを構築して IAM エンドポイントとユーザーを有効にする新しい iris-iam.script ファイルを作成します。 ```objectscript zn "%SYS" write "Create web application ...",! set webName = "/api/iam" set webProperties("Enabled") = 1 set status = ##class(Security.Applications).Modify(webName, .webProperties) write:'status $system.Status.DisplayError(status) write "Web application "_webName_" was updated!",! set userProperties("Enabled") = 1 set userName = "IAM" Do ##class(Security.Users).Modify(userName,.userProperties) write "User "_userName_" was updated!",! halt ``` ### 2.4.4. docker-compose を更新する docker-compose ファイルを次のように更新します。 * db * IAM の postgres データベース * iam-migration * データベースのブートストラップ * iam * 実際の IAM インスタンス * 永続データ用のボリューム 次の部分を docker-compose ファイルの最後に追加します。 ```yml iam-migrations: image: intersystems/iam:1.5.0.9-4 command: kong migrations bootstrap up depends_on: - db environment: KONG_DATABASE: postgres KONG_PG_DATABASE: ${KONG_PG_DATABASE:-iam} KONG_PG_HOST: db KONG_PG_PASSWORD: ${KONG_PG_PASSWORD:-iam} KONG_PG_USER: ${KONG_PG_USER:-iam} KONG_CASSANDRA_CONTACT_POINTS: db KONG_PLUGINS: bundled,jwt-crafter ISC_IRIS_URL: IAM:${IRIS_PASSWORD}@iris:52773/api/iam/license restart: on-failure links: - db:db iam: image: intersystems/iam:1.5.0.9-4 depends_on: - db environment: KONG_ADMIN_ACCESS_LOG: /dev/stdout KONG_ADMIN_ERROR_LOG: /dev/stderr KONG_ADMIN_LISTEN: '0.0.0.0:8001' KONG_ANONYMOUS_REPORTS: 'off' KONG_CASSANDRA_CONTACT_POINTS: db KONG_DATABASE: postgres KONG_PG_DATABASE: ${KONG_PG_DATABASE:-iam} KONG_PG_HOST: db KONG_PG_PASSWORD: ${KONG_PG_PASSWORD:-iam} KONG_PG_USER: ${KONG_PG_USER:-iam} KONG_PROXY_ACCESS_LOG: /dev/stdout KONG_PROXY_ERROR_LOG: /dev/stderr KONG_PORTAL: 'on' KONG_PORTAL_GUI_PROTOCOL: http KONG_PORTAL_GUI_HOST: '127.0.0.1:8003' KONG_ADMIN_GUI_URL: http://localhost:8002 KONG_PLUGINS: bundled ISC_IRIS_URL: IAM:${IRIS_PASSWORD}@iris:52773/api/iam/license volumes: - ./iam:/iam links: - db:db ports: - target: 8000 published: 8000 protocol: tcp - target: 8001 published: 8001 protocol: tcp - target: 8002 published: 8002 protocol: tcp - target: 8003 published: 8003 protocol: tcp - target: 8004 published: 8004 protocol: tcp - target: 8443 published: 8443 protocol: tcp - target: 8444 published: 8444 protocol: tcp - target: 8445 published: 8445 protocol: tcp restart: on-failure db: image: postgres:9.6 environment: POSTGRES_DB: ${KONG_PG_DATABASE:-iam} POSTGRES_PASSWORD: ${KONG_PG_PASSWORD:-iam} POSTGRES_USER: ${KONG_PG_USER:-iam} volumes: - 'pgdata:/var/lib/postgresql/data' healthcheck: test: ["CMD", "pg_isready", "-U", "${KONG_PG_USER:-iam}"] interval: 30s timeout: 30s retries: 3 restart: on-failure stdin_open: true tty: true volumes: pgdata: ``` ルートフォルダに .env ファイルを追加します。 ```env IRIS_PASSWORD=SYS ``` ちなみに、Kong ポートの定義は次のようになっています。 | ポート | プロトコル | 説明 | | ----- | ----- | -------------------------------------------------------- | | :8000 | HTTP | コンシューマからの HTTP 着信トラフィックを取り、上流のサービスに転送します。 | | :8443 | HTTPS | コンシューマからの HTTPS 着信トラフィックを取り、上流のサービスに転送します。 | | :8001 | HTTP | 管理 API。 HTTP によるコマンドラインからの呼び出しをリスンします。 | | :8444 | HTTPS | 管理 API。 HTTPS によるコマンドラインからの呼び出しをリスンします。 | | :8002 | HTTP | Kong Manager（GUI）。 HTTP トラフィックをリスンします。 | | :8445 | HTTPS | Kong Manager（GUI）。 HTTPS トラフィックをリスンします。 | | :8003 | HTTP | 開発者ポータル。 開発者ポータルが有効になっていることを前提に、HTTP トラフィックをリスンします。 | | :8446 | HTTPS | 開発者ポータル。 開発者ポータルが有効になっていることを前提に、HTTPS トラフィックをリスンします。 | | :8004 | HTTP | HTTP による開発者ポータルの /files トラフィック。開発者ポータルが有効になっていることが前提です。 | | :8447 | HTTPS | HTTPS による開発者ポータルの /files トラフィック。開発者ポータルが有効になっていることが前提です。 | ### 2.4.5. オプション: .env として IRIS_PASSWORD を追加する 使いやすいよう（またセキュリティの理由により）、IRIS dockerfile の .env ファイルを使用できます。 使用するには、docker-compose の iris サービスの部分を次のように編集します。 ```yml build: context: . dockerfile: dockerfile args: - IRIS_PASSWORD=${IRIS_PASSWORD} ``` そして、dockerfile を編集します（ビルドの第 2 または第 1 ステージ）。 ```dockerfile ARG IRIS_PASSWORD RUN echo "${IRIS_PASSWORD}" > /tmp/password.txt && /usr/irissys/dev/Container/changePassword.sh /tmp/password.txt ``` ### 2.4.6. テスト docker-compose -f "docker-compose.yml" up -d --build # 3. その 1: サービス/ルート  Kong/IAM の連携の仕組みを覚えていますか？  ここでは、次の項目を構築します。 * サービス * crud API 用 * ルート * このサービスにアクセスするためのルート ## 3.1. サービスを作成する IAM ポータル Rest API # サービスを作成する curl -i -X POST \ --url http://localhost:8001/services/ \ --data 'name=crud' \ --data 'url=http://iris:52773/crud/' ここで確認したこと: サービスの作成するには、その URL のみが必要です。 ## 3.2. ルートを作成する IAM ポータル Rest API # ルートを作成する curl -i -X POST \ --url http://localhost:8001/services/crud/routes \ --data 'name=crud-route' \ --data 'paths=/persons/*' \ --data 'strip_path=false' ルートの作成には、次の項目が必要です。 * サービス名 * RegEx が許可されているパス ## 3.3. テスト 元の API プロキシ API # レガシー curl –i --location --request GET 'http://localhost:52773/crud/persons/all' \ --header 'Authorization: Basic U3VwZXJVc2VyOlNZUw==' # KONG curl –i --location --request GET 'http://localhost:8000/persons/all' \ --header 'Authorization: Basic U3VwZXJVc2VyOlNZUw==' ここで確認したこと: * レガシー側は何も変わらない * Kong 側: * ポートを変更する * パスはルートに対応する * 依然として認証が必要 # 4. その 2: プラグインの使用 次に、IRIS エンドポイントに対して Kong の自動認証を行ってみましょう。 これを行うために、resquest-transformer というプラグインを使用します。  ## 4.1. プラグインをサービスに追加する IAM ポータル Rest API # プラグインを作成する curl -i -X POST \ --url http://localhost:8001/services/crud/plugins \ --data 'name=request-transformer' \ --data 'config.add.headers=Authorization:Basic U3VwZXJVc2VyOlNZUw==' \ --data 'config.replace.headers=Authorization:Basic U3VwZXJVc2VyOlNZUw==' ## 4.2. テスト 元の API プロキシ API # レガシー curl –i --location --request GET 'http://localhost:52773/crud/persons/all' # KONG curl –i --location --request GET 'http://localhost:8000/persons/all' ここで確認したこと: * 元の API にエラー 401 が発生する * 認証を行わずにデータに到達した # 5. その 3: 独自認証の追加 ここでは、元の API を損なうことなく、独自の認証を追加してみましょう。  ## 5.1. コンシューマを追加する IAM ポータル Rest API # コンシューマ anonymous を追加する curl -i -X POST \ --url http://localhost:8001/consumers/ \ --data "username=anonymous" \ --data "custom_id=anonymous" # コンシューマ user を追加する curl -i -X POST \ --url http://localhost:8001/consumers/ \ --data "username=user" \ --data "custom_id=user" ## 5.2. Basic 認証プラグインを追加する IAM ポータル Rest API # サービスの Basic 認証を有効にする curl -i -X POST http://localhost:8001/routes/crud-route/plugins \ --data "name=basic-auth" \ --data "config.anonymous=5cc8dee4-066d-492e-b2f8-bd77eb0a4c86" \ --data "config.hide_credentials=false" 説明: * config.anonymous = anonymous コンシューマの uuid ## 5.3. ACL プラグインを追加する IAM ポータル Rest API # ACL を有効にする curl -i -X POST http://localhost:8001/routes/crud-route/plugins \ --data "name=acl" \ --data "config.whitelist=user" ## 5.4. ACL とログイン情報で USER を構成する IAM ポータル Rest API # コンシューマグループを追加する curl -i -X POST \ --url http://localhost:8001/consumers/user/acls \ --data "group=user" # コンシューマのログイン情報を追加する curl -i -X POST http://localhost:8001/consumers/user/basic-auth \ --data "username=user" \ --data "password=user" ## 5.5. テスト 元の API プロキシ API # レガシー curl –i --location --request GET 'http://localhost:52773/crud/persons/all' \ --header 'Authorization:Basic dXNlcjp1c2Vy' # KONG curl –i --location --request GET 'http://localhost:8000/persons/all' \ --header 'Authorization:Basic dXNlcjp1c2Vy' # 6. 演習: レート制限 1. 認証されていないユーザーを有効にする 2. 認証されていないユーザーのレートを 1 分あたり 2 回の呼び出しに制限する ## 6.1. ソリューション 1. 認証されていないユーザーを有効にする IAM ポータル Rest API # コンシューマグループを追加する curl -i -X POST \ --url http://localhost:8001/consumers/anonymous/acls \ --data "group=user" 2. 認証されていないユーザーのレートを 1 分あたり 2 回の呼び出しに制限する IAM ポータル Rest API # レート制限のあるコンシューマを追加する curl -i -X POST \ --url http://localhost:8001/consumers/anonymous/plugins \ --data "name=rate-limiting" \ --data "config.limit_by=consumer" \ --data "config.minute=2" # 7. 開発者ポータル  ## 7.1. 概要 Kong Developer Portal（Kong 開発者ポータル）では以下が提供されます。 * すべての開発者が信頼できる唯一の情報源 * 直感的なドキュメントのコンテンツ管理 * 合理化された開発者オンボーディング * ロールベースのアクセス制御（RBAC）  ## 7.2. 有効化 IAM ポータル Rest API curl -X PATCH http://localhost:8001/workspaces/default --data "config.portal=true" ## 7.3. 最初の仕様を追加する IAM ポータル Rest API curl -X POST http://localhost:8001/default/files -F "path=specs/iam-training.yml" -F "contents=@misc/spec.yml" ## 7.4. テスト ```url http://localhost:8003/default/documentation/iam-training ``` 何が起こりましたか？ これを解決するには？ ## 7.5. 演習 1. CORS プラグインをルートに追加する ### 7.5.1. ソリューション IAM ポータル Rest API # CORS を有効にする curl -i -X POST http://localhost:8001/routes/crud-route/plugins \ --data "name=cors" # 8. 開発者ポータル（その 2）: 認証 ## 8.1. Basic 認証を有効にする IAM ポータル セッション構成（JSON） { "cookie_secure": false, "cookie_name": "portal_session", "secret": "SYS", "storage": "kong" } これで、開発者ポータルの認証が有効になりました。 ## 8.2. アクセスを制限する デフォルトでは、認証されていないユーザーがすべてにアクセスできるようになっています。 ロールを作成することで、アクセスを制限することができます。 例として、CRUD API ドキュメントへのアクセスを制限してみましょう。 ### 8.2.1. ロールを作成する IAM ポータル Rest API # ロールを有効にする curl -i -X POST http://localhost:8001/default/developers/roles \ --data "name=dev" ### 8.2.2. 仕様にロールを追加する IAM ポータル Rest API # ロールを有効にする curl 'http://localhost:8001/default/files/specs/iam-training.yml' -X PATCH -H 'Accept: application/json, text/plain, */*' --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Origin: http://localhost:8002' -H 'Referer: http://localhost:8002/default/portal/permissions/' --data-raw $'{"contents":"x-headmatter:\\n readable_by:\\n - dev\\nswagger: \'2.0\'\\ninfo:\\n title: InterSystems IRIS REST CRUD demo\\n description: Demo of a simple rest API on IRIS\\n version: \'0.1\'\\n contact:\\n email: apiteam@swagger.io\\n license:\\n name: Apache 2.0\\n url: \'http://www.apache.org/licenses/LICENSE-2.0.html\'\\nhost: \'localhost:8000\'\\nbasePath: /\\nschemes:\\n - http\\nsecurityDefinitions:\\n basicAuth:\\n type: basic\\nsecurity:\\n - basicAuth: []\\npaths:\\n /:\\n get:\\n description: \' PersonsREST general information \'\\n summary: \' Server Info \'\\n operationId: GetInfo\\n x-ISC_CORS: true\\n x-ISC_ServiceMethod: GetInfo\\n responses:\\n \'200\':\\n description: (Expected Result)\\n schema:\\n type: object\\n properties:\\n version:\\n type: string\\n default:\\n description: (Unexpected Error)\\n /persons/all:\\n get:\\n description: \' Retreive all the records of Sample.Person \'\\n summary: \' Get all records of Person class \'\\n operationId: GetAllPersons\\n x-ISC_ServiceMethod: GetAllPersons\\n responses:\\n \'200\':\\n description: (Expected Result)\\n schema:\\n type: array\\n items:\\n $ref: \'#/definitions/Person\'\\n default:\\n description: (Unexpected Error)\\n \'/persons/{id}\':\\n get:\\n description: \' Return one record fo Sample.Person \'\\n summary: \' GET method to return JSON for a given person id\'\\n operationId: GetPerson\\n x-ISC_ServiceMethod: GetPerson\\n parameters:\\n - name: id\\n in: path\\n required: true\\n type: string\\n responses:\\n \'200\':\\n description: (Expected Result)\\n schema:\\n $ref: \'#/definitions/Person\'\\n default:\\n description: (Unexpected Error)\\n put:\\n description: \' Update a record in Sample.Person with id \'\\n summary: \' Update a person with id\'\\n operationId: UpdatePerson\\n x-ISC_ServiceMethod: UpdatePerson\\n parameters:\\n - name: id\\n in: path\\n required: true\\n type: string\\n - name: payloadBody\\n in: body\\n description: Request body contents\\n required: false\\n schema:\\n type: string\\n responses:\\n \'200\':\\n description: (Expected Result)\\n default:\\n description: (Unexpected Error)\\n delete:\\n description: \' Delete a record with id in Sample.Person \'\\n summary: \' Delete a person with id\'\\n operationId: DeletePerson\\n x-ISC_ServiceMethod: DeletePerson\\n parameters:\\n - name: id\\n in: path\\n required: true\\n type: string\\n responses:\\n \'200\':\\n description: (Expected Result)\\n default:\\n description: (Unexpected Error)\\n /persons/:\\n post:\\n description: \' Creates a new Sample.Person record \'\\n summary: \' Create a person\'\\n operationId: CreatePerson\\n x-ISC_ServiceMethod: CreatePerson\\n parameters:\\n - name: payloadBody\\n in: body\\n description: Request body contents\\n required: false\\n schema:\\n type: string\\n responses:\\n \'200\':\\n description: (Expected Result)\\n default:\\n description: (Unexpected Error)\\ndefinitions:\\n Person:\\n type: object\\n properties:\\n Name:\\n type: string\\n Title:\\n type: string\\n Company:\\n type: string\\n Phone:\\n type: string\\n DOB:\\n type: string\\n format: date-time\\n"}' ここでは、次の箇所が重要です。 ```yml x-headmatter: readable_by: - dev ``` 次のドキュメントを参照してください: 「[readable_by attribute](https://docs.konghq.com/enterprise/1.5.x/developer-portal/administration/developer-permissions/#readable_by-attribute)」（readable_by 属性） ### 8.2.3. テスト #### 8.2.3.1. 新しい開発者を登録する  #### 8.2.3.2. この開発者を承認する  #### 8.2.3.3. この開発者のロールを追加する  curl 'http://localhost:8001/default/developers/dev@dev.com' -X PATCH --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Cache-Control: no-cache' -H 'Origin: http://localhost:8002' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://localhost:8002/default/portal/permissions/dev/update' -H 'Pragma: no-cache' --data-raw '{"roles":["dev"]}' ## 8.3. 開発者向け Oauth2 を追加する ここでは、開発者が安全に crud API を使用できるよう、Oauth2 認証を追加します。 このフローでは、開発者自身が登録を行い、crud API へのアクセス権を付与します。 ### 8.3.1. その 1: Basic 認証を削除する これを行うには、Basic 認証を BearToken 認証に置き換えます。 まず、Basic 認証/ACL を無効にします。 IAM ポータル Rest API # ACL プラグインを無効にする curl 'http://localhost:8001/default/routes/afefe836-b9be-49a8-927a-1324a8597a9c/plugins/3f2e605e-9cb6-454a-83ec-d1b1929b1d30' -X PATCH --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Cache-Control: no-cache' -H 'Origin: http://localhost:8002' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://localhost:8002/default/plugins/acl/3f2e605e-9cb6-454a-83ec-d1b1929b1d30/update' -H 'Pragma: no-cache' --data-raw '{"enabled":false,"name":"acl","route":{"id":"afefe836-b9be-49a8-927a-1324a8597a9c"},"config":{"hide_groups_header":false,"whitelist":["user","dev","crud"]}}' ### 8.3.2. その 2: application-registration プラグインを追加する IAM ポータル Rest API # application-registration プラグインを作成する curl -i -X POST \ --url http://localhost:8001/services/crud/plugins \ --data 'name=application-registration' \ --data 'config.auth_header_name=authorization' \ --data 'config.auto_approve=true' \ --data 'config.display_name=auth' \ --data 'config.enable_client_credentials=true' ### 8.3.3. リンクサービスとドキュメント IAM ポータル Rest API curl 'http://localhost:8001/default/document_objects' --compressed -H 'Content-Type: application/json;charset=utf-8' -H 'Cache-Control: no-cache' -H 'Origin: http://localhost:8002' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Referer: http://localhost:8002/default/services/create-documentation' -H 'Pragma: no-cache' --data-raw '{"service":{"id":"7bcef2e6-117c-487a-aab2-c7e57a0bf61a"},"path":"specs/iam-training.yml"}' #### 8.3.3.1. テスト dev@dev.com としてログインした開発者ポータルで、新しいアプリケーションを作成します。  client_id と client_secret を提供されます。 これらの情報は、Swagger 開発者ポータルで使用できます。 このアプリケーションを crud サービスに登録します。  トークンを取得する: curl --insecure -X POST https://localhost:8443/persons/oauth2/token \ --data "grant_type=client_credentials" \ --data "client_id=2TXNvDqjeVMHydJbjv9t96lWTXOKAtU8" \ --data "client_secret=V6Vma6AtIvl04UYssz6gAxPc92eCF4KR" トークンを使用する: curl --insecure -X GET https://localhost:8443/persons/all \ --header "authorization: Bearer u5guWaYR3BjZ1KdwuBSC6C7udCYxj5vK" # 9. セキュアな管理ポータル ## 9.1. 管理者を作成する シードパスワードなしでKong をブートしました。 そのため、RBAC を適用する前に、管理者を作成する必要があります。 これを行うために、次を行ってください。 * ［チーム］に移動します。 * 管理者を招待します。 * メールを設定します。 * ユーザー名を設定します。 * ロールをスーパー管理者に設定します。 * 招待します。 * ［招待された管理者］に移動します。 * 表示します。 * リンクを生成します。  ## 9.2. Kong Manager の Basic 認証を有効にする この機能を有効にするには、docker-compose ファイルに変更を加える必要があります。 次のコードを iam サービスの環境に追加します。 ```yml KONG_ENFORCE_RBAC: 'on' KONG_ADMIN_GUI_AUTH: 'basic-auth' KONG_ADMIN_GUI_SESSION_CONF: '{"secret":"${IRIS_PASSWORD}","storage":"kong","cookie_secure":false}' ``` コンテナを再起動します。 docker-compose down && docker-compose up -d 招待された管理者のリンクに移動します。 ```url http://localhost:8002/register?email=test.test%40gmail.com&username=admin&token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MTYzMzYzNzEsImlkIjoiY2JiZGE5Y2UtODQ3NS00MmM2LTk4ZjItNDgwZTI4MjQ4NWNkIn0.sFeOc_5UPIr3MdlQrgyGvmvIjRFvSn3nQjo2ph8GrJA ``` ## 9.3. RBAC で Kong Admin API を使用する RBAC が設定されたため、Kong Admin API は使用できません。 curl -s -X GET \ --url http://localhost:8001/routes このエラーが発生します。 ```json {"message":"Invalid credentials. Token or User credentials required"} ``` ### 9.3.1. トークンで管理者ユーザーを作成する * ［チーム］に移動します。 * RBAC ユーザー * 新しいユーザーを追加  curl -s -X GET \ --url http://localhost:8001/routes \ --header "Kong-Admin-Token: SYS" # 10. プラグイン  Kong には品質の高いプラグインが付属しています。 しかし、組み込まれていないプラグインが必要となった場合は、どうすればよいのでしょうか。 コミュニティプラグインを使用する場合はどうすればよいのでしょうか。 この章では、コミュニティプラグインとそのインポート方法について説明します。 その後で、独自のプラグインの構築方法を確認しましょう。 ## 10.1. コミュニティプラグインをインポートする このステップでは、jwt-crafter プラグインを使用することにします。 これは、Kong 自体で JWT トークンを生成できるようにするプラグインで、トーク生成を行う上流のサービスに頼る必要がなくなります。 このプラグインは次の場所にあります。 ``` https://github.com/grongierisc/kong-plugin-jwt-crafter ``` docker バージョンを使用しているため、このプラグインをインストールするには、プラグインを組み込む新しいイメージを構築する必要があります。 ### 10.1.1. コミュニティプラグインで新しい Kong/IAM docker イメージを構築する 1. この Git のルートに「iam」というフォルダを作成します。 2. この新しいフォルダに dockerfile を作成します。 3. 「plugins」というフォルダを作成します。 1. すべてのコミュニティプラグインを追加する場所です。 4. docker-compose ファイルを更新して、新しいプラグインを有効にします。 plugins フォルダで、コミュニティプラグインの git clone を実行します。 git clone https://github.com/grongierisc/kong-plugin-jwt-crafter dockerfile は次のようになります。 ```dockerfile FROM intersystems/iam:1.5.0.9-4 USER root COPY ./plugins /custom/plugins RUN cd /custom/plugins/kong-plugin-jwt-crafter && luarocks make USER kong ``` この dockerfile で何を確認できますか？ コミュニティプラグインをインストールするには、ルートフォルダ（rockspec のある場所）に移動して、luarocks make を呼び出しています。 それだけです。 これでプラグインをインストールできました。 docker-compose の方では次を行います。 1. iam イメージタグを編集します。 1. intersystems/iam:1.5.0.9-4 -> intersystems/iam-custom:1.5.0.9-4 2. ビルドコンテキストを追加します。 ```yml build: context: iam dockerfile: dockerfile ``` 3. 環境変数でプラグインを有効にします。 ```yml KONG_PLUGINS: 'bundled,jwt-crafter' ``` これで新しい IAM イメージをビルドします。 docker-compose build iam ### 10.1.2. テスト docker-compose up -d ［プラグイン］->［新規］に移動すると、リストの最後に jwt-crafter プラグインが表示されているはずです。  #### 10.1.2.1. 使ってみる 1. 新しいサービスを作成します。 IAM ポータル Rest API # サービスを作成する curl -i -X POST \ --url http://localhost:8001/services/ \ --data 'name=crud-persons' \ --data 'url=http://iris:52773/crud/persons/' 2. ルートを作成します。 IAM ポータル Rest API # ルートを作成する curl -i -X POST \ --url http://localhost:8001/services/crud-persons/routes \ --data 'name=crud-route-jwt' \ --data 'paths=/crud/persons/*' \ --data 'strip_path=true' 3. 自動認証を再利用します。 IAM ポータル Rest API # プラグインを作成する curl -i -X POST \ --url http://localhost:8001/services/crud-persons/plugins \ --data 'name=request-transformer' \ --data 'config.add.headers=Authorization:Basic U3VwZXJVc2VyOlNZUw==' \ --data 'config.replace.headers=Authorization:Basic U3VwZXJVc2VyOlNZUw==' これで完了です。 jwt-crafter の実際の使用は次のようになります。 ```bash # acl をルートに追加する curl -i -X POST http://localhost:8001/routes/crud-route-jwt/plugins \ --data "name=acl" \ --data "config.whitelist=test" \ --data "config.hide_groups_header=false" # サービスを作成する curl -i -X POST \ --url http://localhost:8001/services/ \ --data 'name=jwt-login' \ --data 'url=http://neverinvoked/' # ルートを作成する curl -i -X POST \ --url http://localhost:8001/services/jwt-login/routes \ --data 'name=jwt-login-route' \ --data 'paths=/jwt/log-in' # サービスの Basic 認証を有効にする curl -i -X POST http://localhost:8001/routes/jwt-login-route/plugins \ --data "name=basic-auth" \ --data "config.hide_credentials=false" # サービスの Basic 認証を有効にする curl -i -X POST http://localhost:8001/routes/jwt-login-route/plugins \ --data "name=jwt-crafter" \ --data "config.expires_in=86400" # コンシューマを追加する curl -i -X POST \ --url http://localhost:8001/consumers/ \ --data "username=test" # コンシューマグループを追加する curl -i -X POST \ --url http://localhost:8001/consumers/test/acls \ --data "group=test" # コンシューマのログイン情報を追加する curl -i -X POST http://localhost:8001/consumers/test/basic-auth \ --data "username=test" \ --data "password=test" curl -i -X POST http://localhost:8001/consumers/test/jwt \ --data "key=test" \ --data "algorithm=HS256" # JWT プラグイン curl -i -X POST http://localhost:8001/routes/crud-route-jwt/plugins \ --data "name=jwt" ``` テストしよう！ ```bash # test:test は base64 でエンコーディングされている curl -H 'Authorization: basic dGVzdDp0ZXN0' localhost:8000/jwt/log-in ``` ```bash curl --location --request GET 'http://localhost:8000/crud/persons/all' \ --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW0iOiJ0ZXN0Iiwic3ViIjoiODJiNjcwZDgtNmY2OC00NDE5LWJiMmMtMmYxZjMxNTViN2E2Iiwicm9sIjpbInRlc3QiXSwiZXhwIjoxNjE2MjUyMTIwLCJpc3MiOiJ0ZXN0In0.g2jFqe0hDPumy8_gG7J3nYsuZ8KUz9SgZOecdBDhfns' ``` ## 10.2. 新しいプラグインを作成する これは lua を学習する場所ではありませんが、IAM を素早く再起動して新しい開発をテストする方法などのヒントをいくつか紹介します。 ### 10.2.1. ファイル構造 ``` kong-plugin-helloworld ├── kong │ └── plugins │ └── helloworld │ ├── handler.lua │ └── schema.lua └── kong-plugin-helloworld-0.1.0-1.rockspec ``` 表記法により、Kong プラグインには kong-plugin のプレフィックスを付ける必要があります。 この例では、プラグインの名前を helloworld とします。 次の 3 つのファイルは必須ファイルです。 * handler.lua: プラグインのコアです。 実装のインターフェースで、各関数は、リクエスト/接続のライフサイクルにおいて希望する時点で実行されます。 * schema.lua: プラグインはおそらく、ユーザーが入力した構成を維持する必要があります。 このモジュールは、その構成のスキーマを保持し、ユーザーが有効な構成値のみを入力できるようにルールを定義します。 * *.rockspec: Rockspec: 仕様ファイルのパッケージです。宣言的な Lua スクリプトで、ロック *.rockspec （テーブルが含まれる Lua ファイル）を構築してパッケージ化する方法に関するルールが含まれます。 #### 10.2.1.1. handler.lua plugins インターフェースでは、handler.lua ファイル内の次のいずれかのメソッドをオーバーライドして、Kong の実行ライフサイクルのさまざまなエントリポイントにカスタムロジックを実装できます。 | 関数名 | フェーズ | 説明 | | ---------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | :init_worker() | init_worker | Nginx ワーカープロセスが起動するたびに実行されます。 | | :certificate() | ssl_certificate | SSL ハンドシェイクのSSL 証明書の配信フェーズで実行されます。 | | :rewrite() | rewrite | rewrite フェーズハンドラーとしてクライアントからリクエストを受信するたびに、そのリクエストに対して実行されます。 注意: このフェーズでは、サービスもコンシューマも識別されていないため、このハンドラーはプラグインがグローバルプラグインとして構成されている場合にのみ実行されます。 | | :access() | access | クライアントからのすべてのリクエストに対して、上流サービスにプロキシされる前に実行されます。 | | :response() | access | header_filter() と body_filter() の両方を置き換えます。 上流サービスからレスポンス全体を受信した後、その一部をクライアントに送信する前に実行されます。 | | :header_filter() | header_filter | 上流サービスからすべてのレスポンスヘッダーのバイトが受信されると実行されます。 | | :body_filter() | body_filter | 上流サービスからレスポンス本文のチャンクを受信するごとに実行されます。 レスポンスはクライアントにストリーミングされるため、バッファーサイズを超過し、チャンクごとにストリーミングされる場合があります。 そのため、レスポンスが大きければ、このメソッドが何度も呼び出されることがあります。 詳細は、lua-nginx-module のドキュメントをご覧ください。 | | :log() | log | レスポンスの最後のバイトがクライアントに送信されると実行されます。 | ##### 10.2.1.1.1. 例 ```lua local BasePlugin = require "kong.plugins.base_plugin" local HelloWorldHandler = BasePlugin:extend() function HelloWorldHandler:new() HelloWorldHandler.super.new(self, "helloworld") end function HelloWorldHandler:access(conf) HelloWorldHandler.super.access(self) if conf.say_hello then ngx.log(ngx.ERR, "============ Hello World! ============") ngx.header["Hello-World"] = "Hello World!!!" else ngx.log(ngx.ERR, "============ Bye World! ============") ngx.header["Hello-World"] = "Bye World!!!" end end return HelloWorldHandler ``` #### 10.2.1.2. schema.lua ポータルで表示される構成ファイルです。 ```lua return { no_consumer = true, fields = { say_hello = { type = "boolean", default = true }, say_hello_body = { type = "boolean", default = true } } } ``` #### 10.2.1.3. *.rockspec ```rockspec package = "kong-plugin-helloworld" -- hint: rename, must match the info in the filename of this rockspec! -- as a convention; stick to the prefix: `kong-plugin-` version = "0.1.0-1" -- hint: renumber, must match the info in the filename of this rockspec! -- The version '0.1.0' is the source code version, the trailing '1' is the version of this rockspec. -- whenever the source version changes, the rockspec should be reset to 1. The rockspec version is only -- updated (incremented) when this file changes, but the source remains the same. -- TODO: This is the name to set in the Kong configuration `plugins` setting. -- Here we extract it from the package name. local pluginName = package:match("^kong%-plugin%-(.+)$") -- "myPlugin" supported_platforms = {"linux", "macosx"} source = { url = "https://github.com/grongierisc/iam-training", branch = "master", -- tag = "0.1.0" -- hint: "tag" could be used to match tag in the repository } description = { summary = "This a demo helloworld for Kong plugin", homepage = "https://github.com/grongierisc/iam-training", license = "Apache 2.0" } dependencies = { "lua >= 5.1" -- other dependencies should appear here } build = { type = "builtin", modules = { ["kong.plugins."..pluginName..".handler"] = "kong/plugins/"..pluginName.."/handler.lua", ["kong.plugins."..pluginName..".schema"] = "kong/plugins/"..pluginName.."/schema.lua", } } ``` ### 10.2.2. 構築 ここでは、次の章と同じことを行います: [11.1.1. コミュニティプラグインで新しい Kong/IAM docker イメージを構築する](#1111-build-a-new-kongiam-docker-image-with-the-community-plugin) ただし、このプラグインに適応させています。 Dockerfile : ```dockerfile FROM intersystems/iam:1.5.0.9-4 USER root COPY ./plugins /custom/plugins RUN cd /custom/plugins/kong-plugin-jwt-crafter && luarocks make RUN cd /custom/plugins/kong-plugin-helloworld && luarocks make #USER kong #Stay with root use, we will see why later ``` 環境変数でプラグインを有効にします。 ```yml KONG_PLUGINS: 'bundled,jwt-crafter,helloworld' ``` これで新しい IAM イメージをビルドします。 docker-compose build iam そして docker-compose を起動してテストします。 ### 10.2.3. ヒント IAM コンテナを「デバッグモード」で実行し、コンテナの停止/再開を簡単に行えるようにするには、dockerfile を変更して、プラグインの追加/削除など行います。 iam サービスを次のようにして停止できます。 docker-compose stop iam そして、シェルを使用して実行モードで起動します。 docker-compose run -p 8000:8000 -p 8001:8001 -p 8002:8002 iam sh コンテナでは次のように行います。 ./docker-entrypoint.sh kong コーディングをお楽しみください :) # 11. CI/CD  この記事も残り少なくなりました。 最後に、DevOps/CI/CD について話しましょう。 この章は、IAM/Kong 向けの CI/CD を実装/スクリプト化する方法について、いくつかのアイデアを提供することを目的としています。 Kong は第一に API であるため、すべての Rest 呼び出しをスクリプト化して、各環境で実行させるという考え方です。 postman とその親友の newman（postman のコマンドラインバージョン）を使用すると、Rest 呼び出しのスクリプト化を最も簡単に行うことができます。 ## 11.1. postman コレクションを作成する postman が便利な理由の 1 つは、Rest 呼び出しの前後でスクリプトを実行できるところにあります。 ほとんどの場合、この機能を使用します。 ### 11.1.1. IAM が起動しているか 最初のスクリプトでは、IAM が稼働しているかどうかを確認します。  ```javascript var iam_url = pm.environment.get("iam_url"); var iam_config_port = pm.environment.get("iam_config_port"); var url = "http://" + iam_url + ":" + iam_config_port + "/"; SenReq(20); async function SenReq(maxRequest) { var next_request = "end request"; const result = await SendRequest(maxRequest); console.log("result:",result); if(result == -1) { console.error("IAM starting .... failed !!!!"); } } function SendRequest(maxRequest) { return new Promise(resolve => { pm.sendRequest(url, function (err) { if (err) { if (maxRequest > 1) { setTimeout(function () {}, 5000); console.warn("IAM not started...retry..next retry in 5 sec"); SendRequest(maxRequest - 1); } else { console.error("IAM starting .... failed"); resolve(-1); } } else { console.log("IAM starting .... ok"); resolve(1); } } ); }); } ``` ### 11.1.2. 古いデータを削除する ```javascript var iam_url=pm.environment.get("iam_url"); var iam_config_port=pm.environment.get("iam_config_port"); pm.sendRequest("http://"+iam_url+":"+iam_config_port+"/plugins", function (err, res) { if (err) { console.log("ERROR : ",err); } else { var body_json=res.json(); if(body_json.data) { for( i=0; i < body_json.data.length; i++) { // Example with a full fledged SDK Request route_id = body_json.data[i].id; const delete_route = { url: "http://"+iam_url+":"+iam_config_port+"/plugins/" + route_id, method: 'DELETE', }; pm.sendRequest(delete_route, function(err, res){ console.log(err ? err : res); }); } } } }); ``` ルート、サービス、およびコンシューマでも同じように行ってください。 ルートのあるサービスは削除できないため、この実行順序は重要です。 ### 11.1.3. サービス/ルートを作成する ルートはサービスに依存しています。 この種のケースでは、postman の Test 関数を使用してデータを取得することができます。  画面 スクリプト var id = pm.response.json().id; var name = pm.response.json().name; pm.globals.set("service_crud_id", id); pm.globals.set("service_crud_name", name); ここで、レスポンスから、新しいサービスの ID と名前を保存します。 次に、次のルートの作成でそれらを使用します。 画面 スクリプト service_crud_name = pm.globals.get("service_crud_name"); ここで、グローバル変数「service_crud_name」を取得します。 次に、それを実際の呼び出しで使用します。 画面 スクリプト { "paths": [ "/persons/*" ], "protocols": [ "http" ], "name": "crud-persons", "strip_path": false, "service": { "name": "{{service_crud_name}}" } } #### 11.1.3.1. ヒント * ペイロードは json または form-data のいずれかです。 * form-data:  * json:  json 形式を簡単に取得するには、管理者ポータルに移動し、json を表示してコピーします。  ## 11.2. newman で実行する docker run --rm -v "`pwd`/ci/":"/etc/newman" \ --network="iam-training_default" \ -t postman/newman run "DevOps_IAM.postman_collection.json" \ --environment="DevOps_IAM.postman_environment.json"

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。 現在使用している Caché/Ensemble システムから InterSystems IRIS に移行する場合、マイグレーション(インプレース変換)を行うのでなければ現行環境と新環境を一時的に並行稼働させる必要があるかもしれません。 この動画では、そのような場合のインストールや構成についての注意点やデータ移行にどのような技術が利用可能かについてご紹介します。 Caché/Ensemble から IRIS へのマイグレーションについては、こちらもご覧ください。

これは、InterSystems FAQサイトの記事です。以下の7つの技術を用いて、VB.NETからInterSystems IRISへ接続し使用することができます。 (A) InterSystems IRIS ADO.NET Managed Provider を利用するInterSystems ADO.NET Managed Provider では、ADO.NET 準拠データベースとして InterSystems IRIS にアクセスでき、データへの簡単なリレーショナル・アクセスを提供します。特に ADO.NET を以前に使用したことのあるユーザにお勧めです。詳細は、以下ドキュメントをご参照ください。InterSystems IRIS ADO.NET Mnaged Providerについて (B) XEP を利用する。.NETアプリケーションで作成したオブジェクトをそのまま InterSystems IRISへオブジェクトとして保存できます（オブジェクトをテーブルに変換する処理は行われません）。また、登録対象オブジェクトが格納された配列全体を１度に更新することもできるため、シンプルなオブジェクトの構造であれば、データの大量更新に優れたパフォーマンスを発揮します。詳細は、以下ドキュメントをご参照ください。InterSystems IRIS XEP による.NETオブジェクトの永続化について (C) Native APIを利用するテーブルでもなくオブジェクトでもない、グローバル変数に対するダイレクトなアクセスを行う場合に利用できます。 (D) Entity Frameworkを利用する.NET側で Entity Franeworkを利用した複雑なオブジェクトモデルを利用している場合は、Entity Frameworkによる接続が最適です。Entity FrameworkはADO.NETの拡張機能であるため、.NET側でオブジェクトからの変換が行われInterSystems IRISへはSQLが渡されます。同じオブジェクトを利用するXEPと比較して複雑なオブジェクトモデルを簡単に処理できる利点がありますが、リアルタイムに大量データを更新する処理には向いていません。詳細は、以下ドキュメントをご参照ください。InterSystems IRIS Entity Framework Provider の使用法について (E) WebServiceを使用するSOAP (Simple Object Access Protocol) に対する完全なサポートを提供していますので、.NETからも利用できます。詳細は、以下ドキュメントをご参照ください。WebサービスおよびWebクライアントの作成について (F) RESTを使用するInterSytsems IRISにRESTインターフェースを提供するためのディスパッチクラスの作成すれば.NETからも利用できます。詳細は、以下ドキュメントをご参照ください。InterSYstems IRISでのRESTインターフェースの開発について (G) ODBC経由で接続する他の技術からの接続と同様に、ODBC経由での接続ができます。