.png)
InterSystems IRIS for Health™は、世界で最も重要なデータを管理する医療アプリケーションの迅速な開発を目的に特別に設計された世界初、かつ唯一のデータプラットフォームです。 トランザクションの処理と分析、拡張可能な医療データモデル、FHIRベースのソリューション開発、医療情報の相互運用性に関わる標準規格への対応など、すぐに使える強力な機能を搭載しています。 これらすべての機能により、開発者は価値を実現し、画期的なアプリケーションをすばやく構築することができます。 詳細はこちらをご覧ください
これはInterSystems FAQ サイトの記事です。
テーブルチューニングを行った際に、フィールドに値がほとんど登録されていない（Null）場合や、特定の値がほとんどを占める場合、その値を[外れ値] として除外して選択性計算を行います。 また、外れ値が全レコードの何 % を占めているかの値は [外れ値の選択性] として記録されます。
InterSystems 製品のクエリオプティマイザは、選択性数値とエクステントサイズを使用してクエリの経路を決定しますが、クラスクエリ、埋め込み SQL に使用しているクエリに外れ値が含まれる場合は、外れ値の選択性が自動的に考慮され、インデックスの使用有無を決定しています。
ダイナミック SQL 、ODBC／JDBC 経由でのクエリについては、外れ値が Null である場合、自動的に外れ値の選択性が考慮されますが、Null 以外の特定の値が外れ値に検出される場合は、明示的に指示を与えるまで考慮しません。
詳細は、ドキュメント（異常値に対する述語条件【IRIS】／異常値に対する述語条件【Caché／Ensemble】）をご参照ください。
データベースシステムには非常に特殊なバックアップ要件があり、企業のデプロイメントでは、事前の検討と計画が必要です。 データベースシステムの場合、バックアップソリューションの運用上の目標は、アプリケーションが正常にシャットダウンされた時と同じ状態で、データのコピーを作成することにあります。 アプリケーションの整合性バックアップはこれらの要件を満たし、Cachéは、このレベルのバックアップ整合性を達成するために、外部ソリューションとの統合を容易にする一連のAPIを提供しています。
これらのAPIは**ExternalFreezeとExternalThaw**です。 _ExternalFreeze_は一時的にディスクへの書き込みを停止し、この期間にCaché はメモリ内の変更をコミットします。 この期間にバックアップ操作を完了させ、_ExternalThaw_の呼び出しを行う必要があります。 この呼び出しによって、書き込みのデーモンがグローバルバッファプール（データべースキャッシュ）で更新されたキャッシュをディスクに書き込むと、通常のCachéデータベースの書き込みデーモン操作が再開します。 このプロセスはCachéのユーザープロセスに対して透過的に行われます。 具体的なAPIクラスメソッドは次のとおりです。
##Class(Backup.General).ExternalFreeze()
##Class(Backup.General).ExternalThaw()
これらのAPIは、スナップショット操作のプリスクリプトとポストスクリプトを実行するAzure Backupの新機能と合わせて、Azure上のCachéのデプロイメントに対する包括的なバックアップソリューションを提供しています。 Azure Backupのプリスクリプトとポストスクリプト機能は現在、Linux VMでのみ利用できます。
Azure Backupを使用してVMをバックアップする前に、おおまかに3つのステップを実行する必要があります。
Recovery Servicesコンテナーは、バックアップの目標、ポリシー、および保護する項目を管理します。 Recovery Servicesコンテナーの作成は、Azure PortalまたはPowerShellを使ったスクリプトによって行います。 Azure BackupにはVMで実行する拡張機能が必要であり、Linux VMエージェントによって管理されています。また、最新バージョンのエージェントも必要です。 拡張機能はAzure StorageとRecovery Servicesコンテナーの外向きのHTTPSエンドポイントと対話します。 VMからこれらのサービスへのセキュアアクセスは、Azure Network Security Groupのプロキシとネットワークルールを使用して構成できます。
上記のステップに関する詳細は、「Prepare your environment to back up Resource Manager-deployed virtual machines」を参照してください。
バックアップ操作の前と後にスクリプトを呼び出す機能は、Azure Backup Extension（Microsoft.Azure.RecoveryServices.VMSnapshotLinux）の最新バージョンに含まれています。 この拡張機能のインストール方法については、機能に関する詳細なドキュメントを確認してください。
デフォルトでは、拡張機能には、Linux VMの次の場所に、サンプルのプリスクリプトとポストスクリプトが含まれます。
/var/lib/waagent/Microsoft.Azure.RecoveryServices.VMSnapshotLinux-1.0.9110.0/main/tempPlugin
そして、スクリプトをそれぞれ次の場所にコピーする必要があります。
/etc/azure/prescript.sh /etc/azure/postScript.sh
スクリプトテンプレートは、GitHubからもダウンロード可能です。
Cachéでは、ExternalFreeze APIを呼び出すprescript.shスクリプトを実装でき、postScript.shにはExternalThawを実行するコードが含まれている必要があります。
以下は、Cachéのprescript.shの実装例です。
#!/bin/bash # variables used for returning the status of the script success=0 error=1 warning=2 status=$success log_path="/etc/preScript.log"#path of log file printf "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalFreeze()" >> $log_path status=$?if [ $status -eq 5 ]; then echo "SYSTEM IS FROZEN" printf "SYSTEM IS FROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then echo "SYSTEM FREEZE FAILED" printf "SYSTEM FREEZE FAILED\n" >> $log_path status=$error csession <CACHE INSTANCE> -U%SYS "##Class(Backup.General).ExternalThaw()" fi exit $status
以下は、CachéのpostScript.shの実装例です。
#!/bin/bash # variables used for returning the status of the script success=0 error=1 warning=2 status=$success log_path="/etc/postScript.log"#path of log file printf "Logs:\n" > $log_path# TODO: Replace <CACHE INSTANCE> with the name of the running instance csession <CACHE INSTANCE> -U%SYS "##class(Backup.General).ExternalThaw()" status=$? if [ $status req 5]; then echo "SYSTEM IS UNFROZEN" printf "SYSTEM IS UNFROZEN\n" >> $log_pathelif [ $status -eq 3 ]; then echo "SYSTEM UNFREEZE FAILED" printf "SYSTEM UNFREEZE FAILED\n" >> $log_path status=$error fi exit $status
Azureポータルで、Recoveryサービスに移動して、最初のバックアップをトリガできます。 初回バックアップまたは後続のバックアップに関係なく、VMスナップショットの時間は数秒であることに注意してください。 最初のバックアップのデータ転送には時間がかかりますが、データ転送は、データベースのフリーズを解除するポストスクリプトの実行後に開始されるため、プリスクリプトとポストスクリプト間の時間に影響を与えることはありません。
データ保護操作が有効であることを確認するには、定期的に非本番環境にバックアップを復元してデータベースの整合性チェックを実行することを強くお勧めします。
バックアップのトリガ方法、およびバックアップスケジュールなどの関連トピックについては、「Back up Azure virtual machines to a Recovery Services vault」を参照してください。
開発者の皆さんこんにちは！IRIS プログラミングコンテスト 7 回目のテーマが発表されました！
今回のコンテストのテーマは ⚡️ InterSystems Interoperability（相互運用性） Contest ⚡️ です！
日本からのご応募お待ちしております！
（投票期間は 2020年11月16日～22日、勝者発表は 11月23日を予定しています）
優勝特典
１、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。
🥇 1位 - $2,000
🥈 2位 - $1,000
🥉 3位 - $500
2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。
🥇 1位 - $1,000
🥈 2位 - $500
複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。
参加資格
どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます）
コンテストのスケジュール
11月2日～15日 応募期間（Open Exchange へ作成されたアプリケーションをアップロードいただける期間＝2週間です。この期間内であればアップロード後も自由に編集できます。）
11月16日～22日 投票（1週間）
開発者の皆さん、こんにちは！
Interoperability（相互運用性）コンテストの続報の「テクノロジーボーナス」について紹介します。
対象となる技術は、以下の通りです。
それぞれの詳細については以下ご参照ください。
IRIS の Interoperability（相互運用性）プロダクションの特徴の1つである、BPL エディタで記述できるビジネス・プロセスがあります。また、ビジネス・ルールは、Interoperability プロダクション内で実行したい処理を、ノーコード/ローコードのアプローチで指定できる開発エディタです（ビジネス・ルールを利用するためには、構築済ビジネス・プロセスを使用します）。
以下参考ドキュメントをご参照ください。
これはInterSystems FAQ サイトの記事です。
1変数に最大 3,641,144 文字まで格納できます。
この制限は、InterSystems IRIS上で取り扱う全ての文字列が対象となるため、ローカル変数やメソッドの引数・戻り値も対象となります。
最大文字について詳しくは、以下ドキュメントをご参照ください。
これはInterSystems FAQ サイトの記事です。
起動時に、 CTELNETD startup error: bind(sock) failed Telnet23ポートは別ソフトでは使用していません。というエラーが発生する場合の対処法です。
現在、InterSystems製品と以下のソフトの組み合わせで、この現象が発生することがわかっています。
これらがインストールされていると、InterSystems製品の起動も、各GUIツールも正しく動作しません。
上記ソフトウェアについては、アンインストールをお願いいたします。
※1 IMONで、InterSystems製品の全実行ファイルを監視をしないように指定することで、正常に動作します。
これはInterSystems FAQ サイトの記事です。
以下のようにユーザ名、パスワードを引数に持ち、認証が成功した場合はユーザ名、失敗したときは""(NULL)を返すルーチン(SecTest^SecTest)を作成し、標準の認証システムを書き換えることができます。
このルーチンを$SYSTEM.SQL.SetSQLLoginOverride()関数を使用して置き換えます。
ただし標準の認証ができなくなりますので、パスワードを別に保管、参照する仕組みを記述する必要があります。
皆さん、こんにちは！
InterSystems IRIS には [Interoperability（相互運用性）]というメニューがあります。
このメニューには、システム統合を簡単に作成できる仕組み（アダプタ、レコードマップ、BPM、データ変換など）が用意されていて、異なるシステムを簡単に接続することができます。
例えば、普段繋がっていないシステムを繋げるために相手の仕様に合わせてデータを受信（または送信）したり、データ送信前に別システムから情報を取得して追加したり、データベース（IRIS でもそれ以外でも）から情報を取得したり更新したり、データ中継の流れの中に様々な処理を含むことができます。
この記事のシリーズでは、Interoperability（相互運用性）でシステム統合を行う際、どのような仕組みで動作するのか、またどのような開発が必要になってくるのか、をご理解いただくためにサンプルコードをご覧いただきながら以下の項目を解説します。
まずはこのシリーズで使用するテーマをご紹介します。
この記事はこちらの投稿の続きの内容です。
この記事では、Interoperability（相互運用性）メニューを利用してシステム統合を行う際、どのような仕組みで動作しているのかについて解説します。
図の左側は、外部システムから送信される情報の受け入れ窓口です。
情報の受信方法としては、ファイルを読むために指定ディレクトリを一定間隔で監視したり、データベースへ定期的に問い合わせを行ったり、入力を待機したり、または他システムのアプリケーションから直接呼び出して渡してもらうなど、様々な方法を用意しています。
IRIS の Interoperability（相互運用性）メニューで作成するシステム統合の仕組みの中では、受信した情報を メッセージ と呼ぶオブジェクトに格納し、次の処理を担当するコンポーネントへ メッセージ を送信します。
メッセージ は受信した情報を全て利用して作成することも、一部抜粋した情報のみを利用することも自由に選択できます。
メッセージ に含まれる情報を外部システムへ 送信したい場合は、外部システムへ処理を依頼する役割があるコンポーネント（図の右側）へメッセージ を送信します。メッセージ を受信したコンポーネントは、外部システムへ処理を依頼します。
この記事はこちらの投稿の続きの内容です。
前回の記事では、Interoperability（相互運用性）メニューを利用してシステム統合を行う際、どのような仕組みで動作しているのかについて解説しました。
今回の記事では、Interoperability（相互運用性）メニューを利用してでシステム統合を行うためにどのような開発を行うのか、について解説します。
最初に、どんな流れを作りたいのか？を考えながら、以下の内容を作成していきます。
プロダクション については、システム統合を行うために必要なコンポーネントの指定と、コンポーネントの設定を保存しておくため定義で、管理ポータルを使用して設定します（内部的にはプロダクション用クラス定義として保存されます）。
例えば、一定間隔で指定ディレクトリに置かれたファイルを処理するビジネス・サービスを作成している場合、「どのディレクトリを監視するのか」「どのファイルを処理したらいいのか」を具体的に設定します。この設定を保存するために用意するのが プロダクション です。
なお、設定内容はデータを送受信するコンポーネントが使用するアダプタにより異なります。
この記事はこちらの投稿の続きの内容です。
前回の記事では、プロダクションとは？について確認しました。また、サンプルコードを動かしながらプロダクションに流れるメッセージの中身をトレース画面で確認しました。
今回は記事では、システム統合を行うための必要な開発内容の中から、コンポーネント間のデータ送受信に使用される メッセージ について、作成するときの考え方や定義方法を確認していきます。
メッセージ を作成する前に、サンプルのテーマを再度確認しましょう。
ショッピングサイトを運営している会社があり、季節に合わせ商品情報の表示順を変更する作業を行っています。
ところが、季節を問わず良く売れるもの、想定しなかった時期に売れるものもあり、現在の表示順変更ルールにうまく合いません。
そこで、季節に合わせた表示順ではなく、そのときの気温にあわせた表示順に変更できないか検討した結果、購入物品に対してそのときの気温を調査する必要が出てきました。
気象情報の確認には、外部の Web API が利用できるため、購入されたタイミングで気象情報を収集し、後で確認できるようにデータベースに情報を登録していく予定です。
このテーマから、以下の内容が確認できます。
この記事はこちらの投稿の続きの内容です。
前回の記事では、システム統合に必要なコンポーネントの中から、ビジネス・オペレーションの作成について解説しました。
今回の記事では、確認した2つのビジネス・オペレーションを順番を守って呼び出しを行うビジネス・プロセスの作成について解説します。
ビジネス・プロセスは処理の調整役（司令塔）として働きます。
サンプルの中で行いたい処理の調整は、以下の内容です。
手順① 外部の Web API に都市名を渡し気象情報を問い合わせる
手順② ①の問合せ結果（気象情報）と、処理開始時に受信した購入商品名をDBへ登録する
サンプルのビジネス・プロセスでは、手順① の回答を待って手順② を動かすように調整します。
回答を待つ処理（＝同期を取る処理）ですが、例えば、手順① が数日返ってこない場合、どうなるでしょうか？
数日回答を待ち続けている間にビジネス・プロセスへ次々に新メッセージが渡された場合、メッセージは一旦キューに格納されるため消失しませんが、新メッセージの処理をビジネス・プロセスが実行できず処理に遅延が発生します。
メモ： ビジネス・プロセスとビジネス・オペレーションにはキューがあります。
この記事はこちらの投稿の続きの内容です。
前回の記事では、システム統合に必要なコンポーネントの中から、プロダクション内の処理の調整役となるビジネス・プロセスの作成について解説しました。
今回の記事では、プロダクションの情報入力窓口である、ビジネス・サービスの作成について解説します。
いよいよ「Interoperability（相互運用性）を使ってみよう！」の最後のコンポーネントです。
ビジネス・サービスは、IRIS 外部からの送信される情報の入力窓口で、外部 I/F に対してアダプタを使用する／しないを選択できます。
サンプルでは、3 種類のビジネス・サービスを用意しています（括弧内のリンクはサンプルコードへのリンク）。
これは、InterSystems FAQサイトの記事です
Windowsでは、以下イメージ名のプロセスを監視対象としてください。
[irisdb.exe]
重要なシステムプロセスが含まれています。
※ 監視対象にすべき重要なシステムプロセスを確認する方法は、添付をご参照ください。
[IRISservice.exe]
IRISインスタンスをサービス経由で扱う為のプロセスになります。
このプロセスが終了すると、IRISインスタンス自体には直接影響はありませんが、IRIS の停止(サービスの停止)ができなくなります。
[ctelnetd.exe]
%Service_Telnet サービスが有効になっている場合に起動し、Telnet 経由で IRIS へアクセスする為のデーモンプロセスになります。
このプロセスが終了すると、IRIS インスタンスへの Telnet アクセスができなくなります。
[iristrmd.exe]
%Service_Console サービスが有効(既定で有効)になっている場合に起動し、サーバのローカル端末(サーバの IRIS ランチャーからターミナル)より IRIS へアクセスする為のデーモンプロセスです。
このプロセスが終了すると、IRIS インスタンスへのローカル端末アクセスができなくなります。
これはInterSystems FAQ サイトの記事です。
IRIS の開始ができず、messages.log に以下のようなエラーが出力された場合の対処方法についてご説明します。
このメッセージは、ジャーナルファイルの破損による IRIS 開始時のリカバリ処理がエラーになっていることを示しています。
これはInterSystems FAQ サイトの記事です。
%Net.HttpRequest クラスの SSLConfiguration プロパティに SSL/TLS 構成の「クライアント」構成名が指定されているかご確認ください。
%Net.HttpRequest クラスを使用して、https の url にアクセスするためには、以下のドキュメントに記載されている SSL/TLS 構成 の「クライアント」構成を作成して指定した名前を SSLConfiguration プロパティに指定する必要があります。
管理ポータルの [システム管理] > [セキュリティ] > [SSL/TLS構成] メニューを開き、「構成名」に任意名を設定し、「保存」ボタンをクリックします（そのほかの構成パラメータは、デフォルト値で作成します）。
実行例は以下の通りです（https://www3.nhk.or.jp/news/ にアクセスしています）。
リモートや在宅での勤務が一般化しつつあります。
そのため、今までの集中型、オンサイトの開発体制を見直し、分散型の開発体制への移行を進めておられるユーザさんも多いのではないかと思います。
VSCodeを使用したIRISアプリケーションの開発が、コミュニティーを中心に広まり始めて久しいですが、Gitとの相性が良いこの開発ツールが今後さらに浸透していくことは間違いありません。あちらこちらで、その使いまわし方が語られていますが、ここでは、ソースコントロールとの関連を中心にご紹介したいと思います。
ObjectScript Extensionの使い方の基本については、こちらやこちらをご覧ください。
VSCode InterSystems ObjectScript Extensionのプロダクションリリース(V1.0.x)の配布が始まりました。
これに合わせて、今までのコミュニティーサポートに加え、InterSystemsによる公式サポートもアナウンスされています。よりいっそう安心してご利用いただけるようになりました。
これはInterSystems FAQ サイトの記事です。
DATE 型は InterSystems 製品のデータ型の %Date に、TIME 型は %Time に対応しています。
%Date は内部日付（特殊変数 $Horolog のカンマ区切り1番目）、%Time は内部時刻（$Horolog のカンマ区切り2番目）を登録するタイプであるため、サーバ側ロジックでは表示モードを切り替えない限り、内部（論理）形式の値が使用されます。
サーバ側ロジックで内部日付・時刻の表示形式を変更する方法は、操作方法により異なります。
以降の実行例では、Sample.Person テーブルを使用して解説します。
（コマンド実行例は SELECT 文で記載していますが、更新文に対しても同様に記述できます。）
IRIS／IRIS for Health でお試しいただく場合は、ドキュメント（InterSystems IRIS で使用するサンプルのダウンロード）から、
または 関連記事（サンプル（Sample.Person）のクラス定義ダウンロードとサンプルデータの作成について）から、
Sample.Person クラスのインポートとサンプルデータの作成を行ってからお試しください。
Caché／Ensembleでお試しいただく場合は、SAMPLESネームスペースのSample.Personをご利用ください。
これはInterSystems FAQ サイトの記事です。
この記事では「グローバルを誤って削除してしまった！.png)
」という場合の対処方法をご紹介します。
誤って削除してしまった特定のグローバルを復旧するためには、バックアップファイルとジャーナルを使用します。
復旧は、^ZJRNFILTユーティリティによるジャーナルリストアで条件を指定してジャーナルレコードをリストアする方法で行います。
この方法で、ある時点のデータベースのバックアップに対して、削除が含まれるジャーナルレコードについて特定グローバルを削除するまでのものを適用することができます。
^ZJRNFILTユーティリティの詳細については、以下のドキュメントをご参照ください。
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について【IRIS】
^ZJRNFILT を使用したジャーナル・レコードのフィルタ処理について
【実施例】
・2020/10/14 時点のバックアップが存在している（バックアップは2020/10/15 0:30に実行したとします）
ジャーナル：2020/10/15 の1日分が存在している(2020/10/14のバックアップ以降のもの)
・対象のグローバル：^TEST1
イメージは以下の通りです。
開発者の皆さんこんにちは！
第6回 InterSystems IRIS プログラミングコンテスト（Full Stackコンテスト） への応募、投票が全て終了しました。コンテストへのご参加、またご興味をお持ちいただきありがとうございました。
今回のお知らせでは、見事受賞されたアプリケーションと開発者の方々を発表します！
🏆 審査員賞 - 特別に選ばれた審査員から最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $1,500 は npm-iris を開発された Henrique Gonçalves Dias さんに贈られました！
🥈 2位 - $1,000 は apptools-admin を開発された Sergey Mikhailenk さんに贈られました！
🥉 3位 - $500 は realworld-intersystems-iris を開発された Dmitriy Maslenniko さんに贈られました！
🏆 開発者コミュニティ賞 - 最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $1,000 は npm-iris を開発された Henrique Gonçalves Dias さんに贈られました！
🥈 2位 - $250 は apptools-admin を開発された Sergey Mikhailenk さんに贈られました！
InterSystems IRIS データ・プラットフォーム および InterSystems IRIS for Health バージョン 2020.3 CD をリリースしました。
こちらはCD(continuous delivery)リリースになりますので、OCI(Open Container Initiative)と呼ばれるDockerコンテナー形式でのみ使用可能です。
リリースのビルド番号は 2020.3.0.221.0 です。
InterSystems IRIS Data Platform 2020.3 により、サイロ化したデータとアプリケーションをつなぐ、リアルタイム機械学習に対応したアプリケーションの迅速な開発と展開を可能にします。このバージョンでは、以下の多くの新機能が含まれます。
クラウド、オンプレミス双方での、開発および運用面の機能追加
・IKO - 新機能 InterSystems Kubernetes Operator (IKO) を使うことでKubernetesクラスタをより簡単に構成
・ICMにおける IAMデプロイのサポート
・非同期ミラーにおける シャードクラスタのサポート
・システム管理ポータルでの ワークキューの管理
これはInterSystems FAQ サイトの記事です。
DBLatency の Warning メッセージは、ヘルス・モニタプロセスが定期的にデータベースからのランダム読み取りが完了するまでに要した時間（ミリ秒）を計測していて、設定されている閾値（1000 msec）を超えた場合に出力されます。
上記例では、C:\xxx\IRIS.DAT（または C:\xxx\CACHE.DAT）へのディスク読み取り I/O に 1510 msec かかったことを示していて、メッセージ出力時のディスク I/O 応答速度が遅いことが考えられます。
ディスク I/O 応答速度が遅い原因としては、ディスク I/O 負荷が高いことが考えられます。
開発者の皆さんこんにちは！IRIS プログラミングコンテストも 6 回目を迎えました！
今回のコンテストのテーマは
「InterSystems IRIS をバックエンドとし Web またはモバイル・ソリューションをフロントエンドとして使用する⚡️フル・スタック・アプリケーション⚡️」
です。日本からのご応募お待ちしております！
Open Exchange（アプリケーション登録／参考となる開発テンプレート）のページはこちら➡ ⚡️ InterSystems Full Stack Contest ⚡️
（投票期間は 2020年10月5日～11日、勝者発表は 10月12日を予定しています）
優勝特典
１、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。
🥇 1位 - $2,000
🥈 2位 - $1,000
🥉 3位 - $500
2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。
🥇 1位 - $1,000
🥈 2位 - $500
複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。
参加資格
どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます）
コンテストのスケジュール
これはInterSystems FAQ サイトの記事です。
%Library.Routine （以降、%Routine）クラスのRoutineListクエリを使用して、プログラムからルーチンの日付やサイズを取得できます。
RoutineListクエリには、引数があり、検索対象となるルーチン名を前方一致や中間一致で指定できます。
（ワイルドカードには、* か ? を指定します。）
以下の例では、*.MAC を引数に指定して、検索をしています。
ルーチン一覧の他に、クラス定義一覧も取得できます。
これはInterSystems FAQ サイトの記事です。
言語バインディングなどのサーバクライアント型で接続した場合、クライアントのマシン名は以下の処理で取得できます。
クライアントのIPアドレスは以下の処理で取得できます。
* サーバーとクライアントが同一マシンの場合、上記で取得できるIPアドレスは、127.0.0.1になります。
これはInterSystems FAQ サイトの記事です。
コンソールログ(message.log/cconsole.log)に、以下のようなログが出力される場合があります。
このメッセージは、コントロールプロセスが出力しています。
このプロセスは、ライトデーモン(WriteDaemon)等の主要なシステムプロセスを監視しています。
Amazon Web Services（AWS）クラウドは、コンピューティングリソース、ストレージオプション、ネットワークなどのインフラストラクチャサービスの幅広いセットをユーティリティとしてオンデマンドかつ秒単位の従量課金制で提供しています。 新しいサービスは、先行投資なしで迅速にプロビジョニングできます。 これにより、大企業、新興企業、中小企業、公営企業の顧客は、変化するビジネス要件に迅速に対応するために必要なビルディングブロックにアクセスすることができます。
更新: 2019年10月15日
以下の概要と詳細は Amazon が提供しているものであり、こちらから参照できます。
AWS Cloud のインフラストラクチャは、リージョンとアベイラビリティーゾーン（AZ）を中心に構築されています。 リージョンは、世界中にある複数の AZ が存在する物理的な場所です。 それぞれの AZ は、別々の施設にある冗長電源、ネットワーク、接続機能を備えた 1 つ以上の異なるデータセンターで構成されています。 これらの AZ は、単一のデータセンターを使用する場合よりも高い可用性、耐障害性、拡張性を持つ本番アプリケーションとデータベースを運用する機能を提供します。
AWS グローバルインフラストラクチャの詳細は、こちらを参照してください。
クラウドのセキュリティはオンプレミスのデータセンターのセキュリティとほぼ同じですが、設備とハードウェアのメンテナンスにコストがかからないという点が異なります。 クラウドでは、物理サーバーやストレージデバイスを管理する必要はありません。 代わりに、ソフトウェアベースのセキュリティツールを使用して、クラウドリソースに出入りする情報のフローを監視および保護します。
AWS クラウドは、責任共有モデルを提供しています。 AWS はクラウドのセキュリティを管理しますが、クラウドのセキュリティはユーザーが責任を負います。 つまり、実際のデータセンターと同じように、自身が所有するコンテンツ、プラットフォーム、アプリケーション、システム、およびネットワークを保護するために導入することを選択したセキュリティを制御し続けることができます。
AWS クラウドのセキュリティの詳細は、こちらを参照してください。
AWS が顧客に提供する IT インフラストラクチャは、最良のセキュリティプラクティスとさまざまな IT セキュリティ標準に合わせて設計および管理されています。AWS が準拠している保証プログラムの完全なリストは、こちらを参照してください。
AWS は、ビジネスや組織のニーズに合わせて組み合わせて使用できる 多くのクラウドサービスで構成されています。 次のサブセクションでは、InterSystems IRIS のデプロイで一般的に使用される主な AWS サービスをカテゴリ別に紹介します。 他にも多くのサービスがあり、特定のアプリケーションに役立つ可能性があります。 必要に応じて必ず調査してください。
サービスにアクセスするには、AWS マネジメントコンソール、コマンドラインインターフェース、またはソフトウェア開発キット（SDK）を使用できます。
| コンポーネント |
|---|
| AWS マネジメントコンソール |
| AWS コマンドラインインターフェース |
| AWS ソフトウェア開発キット（SDK） |
| AWS コンピューティング |
| AWS ストレージ |
| AWS ネットワーキング |
この記事の一部では、アプリケーション固有のデプロイの出発点として、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: サンプルの小規模開発アーキテクチャ
.png)
以下の AWS VPC 内のリソースは、最低限の小規模構成としてプロビジョニングされています。AWS リソースは必要に応じて追加または削除することができます。
以下のテーブルは、小規模構成 AWS リソースのサンプルを示しています。
図 2.1.1-b: 小規模構成 AWS リソースのサンプルテーブル
.png)
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 インスタンスが完全に内部化されていることが要求されている場合、ネットワークと対応するルートに手動で NAT プロキシを設定し、内部インスタンスがインターネットにアクセスできるようにする必要があります。 SSH を使用して、完全に内部化された VM インスタンスに直接接続することはできないことに注意しておくことが重要です。 そのような内部マシンに接続するには、外部 IP アドレスを持つ踏み台インスタンスをセットアップしてから、それを通過するトンネルをセットアップする必要があります。 外部に接する VPC へのエントリポイントを提供するため、踏み台ホストをプロビジョニングすることができます。
踏み台ホストの使用方法に関する詳細は、こちらを参照してください。
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: 高可用性と災害復旧を備えたサンプルの本番アーキテクチャ
.png)
以下の AWS VPC 内のリソースは、Web アプリケーションの本番ワークロードをサポートするための最小推奨要件です。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 アプリケーションサーバーを使用したサンプルの大規模本番アーキテクチャ
.png)
以下の AWS VPC プロジェクト内のリソースは、シャードクラスタをサポートするための最小推奨要件です。AWS リソースは必要に応じて追加または削除することができます。
以下の表に、大規模な本番環境構成のサンプル AWS リソースを示しています。
図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表
.png)
図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表（続き）
.png)
図 2.3.1-b: ECP アプリケーションサーバーを使用した大規模構成の AWS リソースの表（続き）
この例では、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：高可用性を備えたシャードクラスタを使用した本番環境構成のサンプル
.png)
上の図と下のテーブルの「リソースタイプ」列にある「EC2」とは、このドキュメントのセクション 3.1 で説明されている AWS 仮想サーバーインスタンスを表す AWS の用語です。 第 9 章で説明されているクラスタアーキテクチャでの「計算ノード」の使用を表したり暗示するものではありません。
以下の AWS VPC 内のリソースは、シャードクラスタをサポートするための最小推奨要件です。AWS リソースは必要に応じて追加または削除することができます。
以下のテーブルは、シャードクラスタを使用した本番構成の AWS リソースのサンプルを示しています。
図 2.4.1-b: シャードクラスタを使用したサンプル本番環境構成の AWS リソースの表
.png)
Amazon Web Services（AWS）は、IaaS（サービスとしてのインフラストラクチャ）向けの機能性豊かなクラウド環境を提供しています。新しい InterSystems IRIS データプラットフォームによるコンテナベースの開発運用など、InterSystems の全製品に完全に対応していますが、 あらゆるプラットフォームやデプロイモデルと同様に、パフォーマンス、可用性、システム運用、高可用性、災害復旧、セキュリティ制御、およびその他の管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。この記事では、Compute、Storage、および Networking という、すべてのクラウドデプロイの 3 つの主要コンポーネントについて説明します。
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 ディスクがより適しています。標準永続ディスクはより経済的なオプションで、非本番環境の開発やテスト、またはアーカイブタイプのワークロードに適しています。
さまざまなディスクタイプと制限の詳細については、こちらを参照してください。
InterSystems IRIS データプラットフォームの多様なコンポーネントのサポートと共に、適切なネットワークセキュリティコントロール、各種ゲートウェイ、ルーティング、内部 IP アドレス割り当て、ネットワークインターフェース分離、およびアクセス制御を提供するには、仮想プライベートクラウド（VPC）ネットワークの使用が強く推奨されます。VPC の例は、このドキュメント内の例で詳しく説明します。
VPC ネットワーキングとファイアウォールの詳細については、こちらを参照してください。
AWS VPC の詳細は、こちらを参照してください。
ほとんどの大規模なクラウドデプロイでは、複数の VPC をプロビジョニングしてさまざまなゲートウェイタイプをアプリケーション中心の VPC から分離し、インバウンドとアウトバウンドの通信に VPC ピアリングを活用しています。 勤務先で使用されているサブネットと組織のファイアウォールルールの詳細について、ネットワーク管理者に相談することを強くお勧めします。VPC ピアリングについては、このドキュメントでは説明していません。
このドキュメントに含まれる例では、3 つのサブネットを持つ単一の VPC を使用してさまざまなコンポーネントのネットワークを分離し、予測可能なレイテンシと帯域幅、およびさまざまな InterSystems IRIS コンポーネントのセキュリティ分離を実現しています。
このドキュメントでは、インターネットとセキュア VPN 接続をサポートするために、2 つのゲートウェイを使用した例を示しています。アプリケーションに適度なセキュリティを提供するために、各イングレスアクセスには、適切なファイアウォールとルーティングのルールが必要です。VPC ルートテーブルの使用方法に関する詳細については、こちらを参照してください。
InterSystems IRIS データプラットフォームで使用するための専用のアーキテクチャ例では、3 つのサブネットが使用されています。これらの個別のネットワークサブネットとネットワークインターフェースを使用することで、セキュリティコントロールと帯域幅の保護に柔軟性を持たせ、上記 3 つの主要コンポーネントをそれぞれ監視することができます。複数のネットワークインターフェースを備えた仮想マシンインスタンスの作成に関する詳細は、こちらを参照してください。
これらの例には、次のサブネットが含まれます。
ほとんどの 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アドレスなしの自動フェイルオーバー
.png)
ロードバランサーを使用して VIP 同様の機能を提供する方法の詳細については、こちらを参照してください。
以下の図 4.3-a では、すべてのコンポーネントを組み合わせて、次の特性を持つ VPC のレイアウトを示しています。
AWS では、各サブネットは完全に 1 つのアベイラビリティーゾーン内に存在する必要があり、ゾーンをまたがることはできません。 したがって、以下の例では、ネットワークセキュリティまたはルーティングルールを適切に定義する必要があります。 AWS の VPC とサブネットの詳細は、こちらを参照してください。
図 4.3-a: VPC ネットワークトポロジの例
.png)
概要で説明したように、AWS Elastic Block Store（EBS）ボリューム、特に EBS gp2 ボリュームタイプの使用をお勧めします。読み取りと書き込みの IOPS レートがより高く、トランザクションと分析用のデータベースワークロードに必要なレイテンシが低いため、EBS gp2 ボリュームが推奨されています。特定の状況で ローカル SSD を使用できることもありますが、ローカル SSD のパフォーマンス向上には、可用性、耐久性、および柔軟性のトレードオフが伴うことに注意してください。
ローカル SSD データ永続性の詳細については、こちらを参照してください。ローカル SSD データが保持される場合とされない場合を理解することができます。
ほかのクラウドプロバイダと同様に、AWS においても、IOPS、容量、および仮想マシンインスタンス当たりのデバイス数に関してストレージに対する制限を課しています。AWS のドキュメントで現在の制限を確認してください。こちらから参照できます。
このような制限があるため、データベースインスタンスの単一ディスクデバイスの IOPS を超えて IOPS を最大化するには、LVM のストライピングが必要となります。提供されている仮想マシンインスタンスの例では、以下のディスクレイアウトが推奨されています。SSD 永続ディスクに関連するパフォーマンス制限については、こちらを参照してください。
図 5.1-a: LVM ボリュームグループ割り当ての例
.png)
LVM ストライピングのメリットによって、ランダムな IO ワークロードをより多くのデバイスに分散し、ディスクキューを継承することができます。以下は、データベースボリュームグループに対して、Linux で LVM ストライピングを使用する方法の例を示しています。この例では、物理エクステント（PE）サイズが 4 MB の LVM PE ストライプで 4 つのディスクを使用しています。または、必要に応じてより大きな PE サイズを使用することもできます。
<span style="color:#c0392b;"><i>vgcreate -s 4M vg_iris_db /dev/sd[h-k]</i></span><i>lvcreate -n lv_irisdb01 -L 1000G -i 4 -I 4M vg_iris_db</i><i>mkfs.xfs -K /dev/vg_iris_db/lv_irisdb01</i>上記の表を使用すると、各 InterSystems IRIS サーバーに、SYS 用ディスク 2 個、DB 用ディスク 4 個、プライマリジャーナル用ディスク 2 個、および代替ジャーナル用ディスク 2 個を備えた以下の構成が作られます。
図 5.1-b: InterSystems IRIS の LVM 構成
.png)
LVM では運用を中断することなく、必要に応じてデバイスと論理ボリュームを拡張できます。LVM ボリュームの継続的な管理と拡張のベストプラクティスについては、Linux のドキュメントを参照してください。
InterSystems IRIS には InterSystems Cloud Manager（ICM）という新しいツールがあります。ICM は多くのタスクを実行し、InterSystems IRIS データプラットフォームをプロビジョニングするためのオプションを多数提供しています。 ICM は Docker イメージとして提供され、堅牢な AWS クラウドベースのソリューションをプロビジョニングするために必要なすべての機能を含んでいます。
ICM は現在、以下のプラットフォームでのプロビジョニングをサポートしています。
ICM と Docker は、デスクトップ/ノートパソコンのワークステーションから実行することも、小規模な専用の集中型「プロビジョニング」サーバーと集中型リポジトリを持つことも可能です。
アプリケーションのライフサイクルにおける ICM の役割は、 定義 -> プロビジョン -> デプロイ -> 管理です。
ICM のインストールと Docker との使用に関する詳細は、こちらを参照してください。
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: アービターを使用したミラー構成のサンプル
.png)
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非同期ミラーリングのサンプル
.png)
上の例では、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 つのノードタイプは単純なビルディングブロックで、シンプルで透過的かつ効果的なスケーリングモデルを提供しています。
シャーディングされたテーブルデータは、必要に応じて、通常は新しいデータノードを追加した後で、クラスタ全体で再調整できます。 この調整により、分散するデータが均等になるようにノード間でデータの「バケツ」が移動されます。
論理レベルでは、シャーディングされていないテーブルデータとシャーディングされたテーブルのすべてのデータの結合はあらゆるノードから可視状態であるため、クライアントは接続しているノードに関係なく、データセット全体を見ることができます。 メタデータとコードも、すべてのデータノードで共有されます。
シャードクラスタの基本的なアーキテクチャ図は、クラスタ全体で均一に見えるデータノードで構成されています。 クライアントアプリケーションは、任意のノードに接続でき、データがローカルであるかのように処理されます。
図 9.2.1-a: 基本的なシャードクラスタの図
.png)
低レイテンシが必要となる高度なシナリオでは、潜在的にデータの一定した流入が発生する可能性があるため、クエリを処理するための透過的なキャッシング層を提供するために計算ノードを追加することができます。
計算ノードはデータをキャッシュします。 各計算ノードは、対応するシャーディングされたテーブルデータをキャッシュするデータノードに関連付けられています。さらに、そのデータに加え、クエリを満たすために必要に応じてシャーディングされていないテーブルデータもキャッシュします。
図 9.2.2-a: 計算ノードを含むシャードクラスタ
.png)
計算ノードは物理的にデータを格納せず、クエリ実行をサポートすることを目的としているため、メモリと CPU に重点を置いてストレージを最小限に抑えるなどによって、そのハードウェアプロファイルをニーズに合わせて調整することができます。 取り込みは、ドライバー（xDBC、Spark）で直接、または計算ノードで「ベア」アプリケーションコードが実行されるときにシャーディングマネージャーコードによって暗黙的にデータノードに転送されます。
シャードクラスタのデプロイにはさまざまな組み合わせがあります。以下の概要図は、最も一般的なデプロイメントモデルを説明しています。これらの図には、ネットワークゲートウェイと詳細は含まれておらず、シャードクラスタコンポーネントのみに焦点が当てられています。
以下の図は、単一のリージョンと単一のゾーンにデプロイされた 4 つのデータノードを持つ最も単純なシャードクラスタです。クライアント接続をシャードクラスタノードに分散するために、AWS Elastic Load Balancer（ELB）が使用されています。
図 9.3.1-a: 基本的なシャードクラスタ
.png)
この基本モデルでは、単一の仮想マシンとそれに接続された SSD 永続ストレージに AWS が提供するものを超えるレジリエンシーや高可用性は提供されていません。インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィックとシャードクラスタ通信間の帯域幅分離の両方を実現するには、2 つのネットワークインターフェースアダプターを個別に用意することをお勧めします。
以下の図は、単一のリージョンにデプロイされた 4 つのミラーデータノードとゾーン間で分岐した各ノードのミラーを持つ最も単純なシャードクラスタです。クライアント接続をシャードクラスタノードに分散するために、AWS Load Balancer が使用されています。
高可用性は、リージョン内のセカンダリゾーンで同期的に複製されたミラーを維持する InterSystems のデータベースミラーリングを使用して提供されています。
インバウンドクライアント接続のネットワークセキュリティ分離と、クライアントトラフィック、シャードクラスタ通信、およびノードペア間の同期ミラートラフィック間の帯域幅分離を実現するには、3 つのネットワークインターフェースアダプターを個別に用意することをお勧めします。
図 9.3.2-a: 高可用性を備えた基本的なシャードクラスタ
.png)
このデプロイモデルでは、この記事の前のセクションで説明したミラーアービターも導入されています。
以下の図は、大規模なユーザー/クエリ同時実行向けに、個別の計算ノードと 4 つのデータノードを持つシャードクラスタを拡張しています。Cloud Load Balancer サーバープールには、計算ノードのアドレスのみが含まれます。更新とデータの取り込みは、以前と同様にデータノードに直接更新され続け、超低レイテンシパフォーマンスを維持し、リアルタイムデータ取り込みによるクエリ/分析ワークロード間のリソースの干渉と輻輳を回避します。
このモデルでは、計算/クエリと取り込みを個別にスケーリングできるようにリソースの割り当てを微調整することで、計算またはデータをスケーリングするためだけにリソースを不要に無駄にする代わりに、必要なときに「ジャストインタイム」でリソースを最適化し、経済的でありながらも単純なソリューションを維持することができます。
計算ノードは AWS 自動スケールグループ（自動スケーリング）を非常に簡単に使用できるため、負荷の増減に基づいて、管理されたインスタンスグループへのインスタンスの追加または削除を自動的に実行することができます。 自動スケーリングは、負荷が高まるとインスタンスグループにインスタンスを追加し（アップスケーリング）、インスタンスのニーズが低下するとインスタンスを削除（ダウンスケーリング）します。
AWS 自動スケーリングの詳細については、こちらを参照してください。
図 9.3.3-a: 計算ノードとデータノードが分離されたシャードクラスタ
.png)
自動スケーリングを使用すると、クラウドベースのアプリケーションは、トラフィックの増加を適切に処理し、リソースのニーズが低下するとコストを削減するのに役立ちます。 ポリシーを定義するだけで、オートスケーラーは測定された負荷に基づいて自動的にスケーリングを実行します。
バックアップ操作には、いくつかのオプションがあります。InterSystems IRIS を使用した AWS デプロイでは、次の 3 つのオプションを使用できます。
最初の 2 つのオプションは、以下で説明するとおり、スナップショットを作成する前にデータベースによるディスクへの書き込みを一時停止し、スナップショットに成功したら更新を再開するというスナップショットタイプの手順を使用しています。
いずれかのスナップショット方式を使用してクリーンなバックアップを作成するには、次のおおまかな手順を実行します。
External Freeze/Thaw API に関する詳細は、こちらを参照してください。
3 つ目のオプションは、InterSystems Online のバックアップです。これは、非常にシンプルな使用事例とインターフェースを備えたより小規模なデプロイメント向けのエントリーレベルのアプローチです。ただし、データベースのサイズが大きくなるにつれ、スナップショットテクノロジーを使った外部バックアップがベストプラクティスとして推奨されます。外部ファイルのバックアップ、より高速な復元時間、エンタープライズ全体のデータビューと管理ツールなどのメリットがあります。
クリーンで一貫したバックアップを確保するために、整合性チェックなどの追加手順を定期的に追加することができます。
どのオプションを使用するかは、組織の運用要件とポリシーによって決まります。さまざまなオプションをさらに詳しく検討するには、InterSystems にご相談ください。
バックアップ操作は、AWS CLI コマンドライン API と InterSystems External Freeze/Thaw API 機能を使用して実行できます。 これにより、実質的に 24 時間 365 日の運用レジリエンシーとクリーンな定期バックアップを実現できます。AWS EBS スナップショットの管理と作成および自動化の詳細については、こちらを参照してください。
別の方法として、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VMそのものにバックアップエージェントを展開し、論理ボリュームマネージャ（LVM）のスナップショットと組み合わせてファイルレベルのバックアップを活用することができます。
このモデルには、Windows または Linux ベースの VM をファイルレベルで復元できるというメリットがあります。このソリューションで注意すべき点は、AWS やほとんどの IaaS クラウドプロバイダはテープメディアを提供しないため、すべてのバックアップリポジトリは、短期アーカイブ用のディスクベースであり、長期保管（LTR）には BLOB またはバケットタイプの低コストストレージを活用できるということです。このモデルを使用する場合は、ディスクベースのバックアップリポジトリを最も効率的に使用できるように、重複除去テクノロジーをサポートするバックアップ製品を使用することを強くお勧めします。
こういったクラウド対応のバックアップ製品には、Commvault、EMC Networker、HPE Data Protector、Veritas Netbackup などさまざまな製品があります。InterSystems では、これらの製品の比較検証や推奨は行っておりません。
小規模なデプロイでは、組み込みの Online Backup ファシリティもオプションとして考えられます。InterSystems のデータベースオンラインバックアップユーティリティは、データベース内のすべてのブロックをキャプチャしてデータベースファイルにデータをバックアップし、出力をシーケンシャルファイルに書き込みます。 この、InterSystems 独自のバックアップメカニズムは、本番システムのユーザーにダウンタイムを引き起こさないように設計されています。 Online Backup の詳細については、こちらを参照してください。
AWS では、オンラインバックアップが完了した後、バックアップ出力ファイルとシステムで使用中のほかのすべてのファイルを、その仮想マシンインスタンスの外部にあるほかのストレージの場所にコピーする必要があります。これには、バケット/オブジェクトストレージが適しています。
AWS Single Storage Space（S3）バケットを使用するには、2 つのオプションがあります。
Config.Configurationクラス、SYS.Databaseクラスのメソッドを使用して、ネームスペース・データベースの作成及び登録をターミナルから実行することができます。
以下はデータベースファル/CacheDB/AAA/cache.datを作成し、構成ファイル（cache.cpf）にデータベース AAA、及び、ネームスペースAAAの登録を行う一連の実行例です。 ＊実行は、%SYSネームスペースで行って下さい。＊
Set Directory="/CacheDB/AAA/"Setx=$ZF(-100, "/shell", "mkdir", Directory)
Set db=##Class(SYS.Database).%New()
Set db.Directory=Directory
Set status=db.%Save()
Set DBName="AAA"Set status=##class(Config.Configuration).AddDatabase(DBName,Directory)
Set NSName=DBName
Set status=##class(Config.Configuration).AddNamespace(NSName,DBName)これはInterSystems FAQ サイトの記事です。
InterSystemsでは、パフォーマンスの影響や動作不調を避けるために、データベースファイルを含む主要なコンポーネントをウイルススキャンの対象から除外していただくことを推奨しております。
具体的には、アンチウイルスソフトのスキャン対象から、以下のファイルを除外してください。
上記ファイルが、アンチウイルスソフトで除外設定されていない場合、「SERIOUS DISK WRITE ERROR...」のようなエラーが発生する場合があります。
このエラーは、実際にハード的なディスク障害が原因であることもありますが、それ以外にアンチウィルスソフトのウィルスチェックなどによって、ディスクへの書き込みが阻止された場合にも起こります。
詳細は、下記ドキュメントページをご参照ください。
インターシステムズ製品と連係して動作するようにサードパーティ・ソフトウェアを構成する方法【IRIS】
インターシステムズ製品と連係して動作するようにサードパーティ・ソフトウェアを構成する方法