.png)
InterSystems IRIS for Health™は、世界で最も重要なデータを管理する医療アプリケーションの迅速な開発を目的に特別に設計された世界初、かつ唯一のデータプラットフォームです。 トランザクションの処理と分析、拡張可能な医療データモデル、FHIRベースのソリューション開発、医療情報の相互運用性に関わる標準規格への対応など、すぐに使える強力な機能を搭載しています。 これらすべての機能により、開発者は価値を実現し、画期的なアプリケーションをすばやく構築することができます。 詳細はこちらをご覧ください
これはInterSystems FAQ サイトの記事です。
サーバ側ロジックの記載に使用する ObjectScript でのエラーが発生した場合の対処方法については「ObjectScriptでエラーが発生したら」にまとめています。
ぜひご参照ください！
開発者の皆さん、こんにちは。
今回の記事では前回の記事に引き続き、IRIS for Health上で、FHIRリポジトリ＋OAuth2認可サーバ/リソースサーバを構成する方法をご案内します。
(注意：2020.4以降のバージョンではこの記事に記載されているスコープ指定では正しくリソースが取得できません。詳細はこちらの記事をご覧ください。）
パート1では、事前準備と、OAuth2認可サーバを構成し、アクセストークンを取得するとこまでをご紹介しました。
このパート2では、FHIRリポジトリの構築方法と、OAuth2クライアント/リソースサーバの構成方法をご紹介していきます。
今日構成する、FHIRリポジトリおよび、OAuth2クライアント/リソースサーバの構成は、前回パート１で構成したOAuth2認可サーバのIRISインスタンスと分けることもできますし、同じインスタンスに同居させることもできます。
この記事の中では前回と同じインスタンス上に構成していきます。
FHIRリポジトリの構築方法は、過去の記事「Azure上でIRIS for Healthをデプロイし、FHIR リポジトリを構築する方法」で紹介しています。
開発者の皆さん、こんにちは。
今回の記事ではFHIRと組み合わせて使用されるケースが増えてきている、権限の認可（Authorization）を行うためのOAuth2について取り上げます。
まずこのパート１では、IRIS for HealthおよびApacheのDockerコンテナの起動と、IRIS for Health上で、OAuth2認可サーバ機能を構成し、REST開発ツールPostmanからアクセスし、アクセストークンを取得する方法について解説します。
さらにパート2以降では、IRIS for HealthにFHIRリポジトリ機能を追加し、OAuth2リソースサーバ構成を追加して、Postmanからアクセストークンを使用したFHIRリクエストの実行方法まで解説します。
InterSystems製品のOAuth2機能の解説については、すでにいくつかの記事が開発者コミュニティ上に公開されていますが、今回は改めて最新バージョンでの構成方法を解説したいと思います。
InterSystems IRIS Open Authorization Framework（OAuth 2.0）の実装 - パート1
皆さん、こんにちは！
FHIR コンテストで🎊優勝🎊された Henrique Gonçalves Dias さんの優勝作品 IRIS FHIR Portal をビデオでご紹介します。
Henrique Gonçalves Dias さんが日本語訳を付けてくれた IRIS FHIR Portal 概要ページもあります。ぜひご参照ください。
過去のコンテストも含めコードは全て OpenExchange で公開されています。
ダウンロードやコンテナ開始までの手順は、OpenExchange の IRIS FHIR Portal ページをご参照いただくか、コンテスト用テンプレートの使い方ビデオの 0:28～1:04／3:04～ をご参照ください（コンテスト用テンプレートをベースに開発いただいているので、基本的な手順は同じです）。
Henriqueさん、おめでとうございます！！
概要
私たちの目標は、 IRISでFHIR機能を使用し患者のカルテをいかに容易に見せるかです。
皆さんこんにちは。
第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 さんに贈られました！
InterSystems IRISをモニタリングする方法はいくつかあります。
本記事では上記に加えてAWSにIRISをデプロイする場合に自然な選択子となりうる方法として、CloudWatchを使用する方法をご紹介します。
AWSネイティブの各種サービスとIRISを連携させる方法の典型のご紹介を兼ねています。
内容は、Open Exchangeで公開されています。日本語のREADMEがありますのでそちらをご覧ください。
README.MDからの引用
InterSystems IRISの各種メトリクスとログをAWS CloudWatchに簡単に公開することができます。
これらメトリクスとログがあれば、IRISのデータをダッシュボードやアラートなどに統合することができます。
NoSQLデータベースという言葉を聞かれたことがあると思います。色々な定義がありますが、簡単に言えば、文字通りSQLを使わない、つまりリレーショナルデータベース(RDB)以外のデータベースのことを指すのが一般的です。
InterSystems IRIS Data Platformでは、テーブルを定義してSQLでデータにアクセスできます。ですから、InterSystems IRIS Data Platformは厳密にNoSQLデータベースというわけではありません。しかし、InterSystems IRISの高パフォーマンスを支える「グローバル」は、40年も前からInterSystemsのコア技術として、現代で言うNoSQLデータベースを提供してきました。本稿では、InterSystems IRISの「グローバル」でグラフ構造を作り、それをPythonでアクセスする方法を紹介します。
本稿で説明する内容は動画でも公開しています。ぜひご覧ください。
NoSQLに分類されるデータベースには様々なデータモデルを扱うものがあります。以下に代表的なものを挙げます。
ICM(InterSystems Cloud Manager)のセットアップは難しいものではありませんが、様々な理由でそもそもDockerが使いづらいという状況があり得ます。
また、セキュリティ的に堅固な環境を得るために、既存VPC内のプライベートサブネット上にIRISクラスタをデプロイする方法のひとつに、同VPC内でICM実行する方法があります。
本稿では、ICMをAWSにデプロイする作業を、CloudFormationで自動化する方法をご紹介します。ICMに関しては、こちらの記事をご覧ください。
更新: 2020年11月24日 デフォルトVPC以外でも動作するよう変更しました。
このたび、InterSystems IRIS 2020.1 の日本語ドキュメントが完成しました。それぞれ以下のWEBサイトで公開をしています。
ページ内の「すべてのドキュメント」アイコンをクリックすることで、各技術コンテンツを参照いただけます。
IRIS for Windows では、以下の設定を行うことで、キューブの[ドキュメント]をクリックしたときに、上記の日本語ドキュメントページを表示させることが可能となります。
たとえば、IRIS 2020.1 の場合、以下のように httpd-doc.conf を編集することで、
キューブの[ドキュメント]をクリックすると、日本語ドキュメントページが表示されるようになります。
ぜひ日本語ドキュメントをご活用いただき、IRIS製品をお使いくださいませ！
本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。 Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。
パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。
更新: 2020年11月20日 バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。
搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。
設定するにはiris停止状態で、iris.cpfファイル(IRISインストール先\mgr\iris.cpf)を変更します。下記はブロックサイズ8KB用(既定値です)のデータベースバッファサイズの自動構成を4096(MB)に変更する例です。
修正前
[config]
globals=0,0,0,0,0,0
修正後
[config]
globals=0,0,4096,0,0,0
詳細はこちらです。
また、Linuxの場合、ヒュージ・ページ有効化の設定を行ってください。設定値の目安ですが、IRIS起動時のメッセージから、確保される共有メモリサイズ(下記だと749MB)を読み取り、その値めがけて設定するのが簡単です。
コンテナバージョンは非rootで動作するため、ヒュージ・ページは利用できません
$ iris start iris
Starting IRIS
Using 'iris.cpf' configuration file
Starting Control Process
Allocated 749MB shared memory: 512MB global buffers, 64MB routine buffer
$ cat /proc/meminfo
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
ページサイズが2048kBですので、750MB(丸めました)を確保するには750/2=375ページ必要になります。構成を変えると必要な共有メモリサイズも変わりますので、再調整してください。
$ echo 375 > /proc/sys/vm/nr_hugepages
$ iris start iris
Starting IRIS
Using 'iris.cpf' configuration file
Starting Control Process
Allocated 750MB shared memory using Huge Pages: 512MB global buffers, 64MB routine buffer
メモリ関連の設定値は、パフォーマンスに大きく影響しますので、比較対象のDBMSが存在するのであればその設定値に見合う値を設定するようにしてください。
特にクラウド上でのベンチマークの場合、ストレージのレイアウトがパフォーマンスに大きな影響を与えます。クラウドではストレージごとのIOPSが厳格に制御されているためです。
こちらに細かな推奨事項が掲載されていますが、まずは下記のように、アクセス特性の異なる要素を、それぞれ別のストレージに配置することをお勧めします。
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 850G 130G 720G 16% /irissys/data (IRIS本体のインストール先、ユーザデータべース)
/dev/sdd 800G 949M 799G 1% /irissys/wij (ライトイメージジャーナルファイル)
/dev/sde 200G 242M 200G 1% /irissys/journal1 (ジャーナルファイル)
/dev/sdf 100G 135M 100G 1% /irissys/journal2 (予備のジャーナルファイル保存エリア)
サイズは用途次第です。WIJに割り当てているサイズが大きめなのは、IOPS性能がファイルシステムの容量に比例するクラウドを使用するケースを意識したためで、IOPSとサイズが連動しないオンプレミス環境では、これほどのサイズは必要ありません。
IRISのテーブルへのインデックス追加は一部のDWH製品のように自動ではありません。多くのRDBMS製品と同様に、CREATE TABLE命令の実行時に、プライマリキー制約やユニーク制約が指定されている場合、インデックが追加されますが、それ以外のインデックスはCREATE INDEX命令で明示的に追加する必要があります。
どのようなインデックスが有用なのかは、実行するクエリに依存します。 一般的に、ジョインの結合条件(ON句)となるフィールド、クエリやUPDATE文の選択条件(WHERE句)となるフィールド、グルーピングされる(GROUP BY)フィールドが対象となります。
インデックスの対象を参照ください。
IRISのデータベースファイルの初期値は1MBです。既定では、ディスク容量が許容する限り自動拡張を行いますので、エラーにはなりませんが、パフォーマンスは劣化します。ベンチマークプログラムでそのことに気づくことはありません。お勧めは、一度ベンチマークを実行して、必要な容量まで自動拡張を行い、データを削除(DROP TABLEやTRUNCATE TABLEを実行)した後に、再度ベンチマークを実行することです。
IRISはクエリの実行プランを最適化するために、テーブルデータに関する統計情報を使用します。 統計情報の取得処理(TuneTable/TuneSchema)は、初期データロード後に明示的に実行する必要があります。
IRISバージョン2022.1以降、統計情報の取得処理が一度も実行されていない場合、初回のクエリ実行時に自動実行されるようになりました。そのため、初回のクエリに若干のオーバヘッドが発生します。
TuneTable(テーブル対象)/TuneSchema(スキーマ対象)を実行すると、既存のクエリプランがパージされるので、次回の初回クエリ実行時はクエリ解析・プラン生成にかかる分だけ時間が多めにかかります。 また、TuneTable/TuneSchema実行後にインデックスを追加した場合には、そのテーブルに対してTuneTableを再実行してください。
これらを考慮すると、ベンチマークで安定した計測結果を得るには、テストデータのロード後に、明示的に下記を実施することが重要になります。
もちろん、これらの性能を計測したい場合は、その限りではありません。
TuneTable/TuneSchemaは、管理ポータル及びCLIで、手動で実行可能です。ベンチマーク測定時は、データの再投入やインデックスの追加や削除といった、統計情報の更新を繰り返し実行する必要性が高くなることを考慮すると、手動での更新は避けて、下記のObjectScriptのCLIやSQL文で実施するのが効果的です。
下記コマンドはスキーマMySchemaで始まる全てのテーブルの統計情報を取得します。
MYDB>d $SYSTEM.SQL.Stats.Table.GatherSchemaStats("MySchema")
下記コマンドは指定したテーブルのテーブルの統計情報を取得します。
MYDB>d $SYSTEM.SQL.Stats.Table.GatherTableStats("MySchema.MyTable")
あるいはSQL文として、データロード実行後にベンチマークプログラム内で実行する事も可能です。
TUNE TABLE MySchema.MyTable
更新: 2020年11月20日 使用方法を、SQL文の修正が不要な方法に変更しました
IRISバージョン2022.1以降、SQLのTimeStamp型の既定値が%PosixTimeに変更されました。この変更によりテーブルを新規作成した際のTimeStamp型は%PosixTimeになります。
create table TEST (ts TIMESTAMP)
これを、下記のように変更してください。
create table TEST (ts POSIXTIME)
デフォルトではSQLのTIMESTAMP型は、IRIS内部では%TimeStamp型で保持されます。 %TimeStamp型は、データを文字列として保存するのに対して、%PosixTimeは64bitの整数で保持します。その分、ディスクやメモリ上のデータサイズや比較演算処理などで有利になります。両者はxDBC上は、共にTIMESTAMP型となり、互換性がありますので、DML文の修正は不要です(敢えて指摘するとすれば、ミリ秒以下の精度が異なります)。以下は、実行例です。%PosixTimeに対するクエリのほうが、程度の差こそあれ、高速になっています。
create table TEST (ts TIMESTAMP, pt POSIXTIME)
create index idxts on TABLE TEST (ts)
create index idxpt on TABLE TEST (pt)
insert into TEST ... 100万レコードほどINSERT
select count(*),DATEPART(year,pt) yyyy from TEST group by DATEPART(year,pt)
平均 669ミリ秒
select count(*),DATEPART(year,ts) yyyy from TEST group by DATEPART(year,ts)
平均 998ミリ秒
select count(*) from TEST where DATEPART(year,pt)='1990'
平均 533ミリ秒
select count(*) from TEST where DATEPART(year,ts)='1990'
平均 823ミリ秒
select count(*) from TEST where pt>='1980-01-01 00:00:00' and pt<'1991-01-01 00:00:00'
平均 350ミリ秒
select count(*) from TEST where ts>='1980-01-01 00:00:00' and ts<'1991-01-01 00:00:00'
平均 381ミリ秒
TIMESTAMP型を%PosixTimeに変更するには、テーブルの作成を行う前、かつIRIS停止中に構成ファイル(IRISインストール先\mgr\iris.cpf)の下記を変更してください。以後、TIMESTAMP型で定義したカラムは%PosixTimeになります。
IRISバージョン2022.1以降、既定値がPosixTimeに変更されましたので、構成ファイルの変更は不要です。
[SQL]
TimePrecision=0 (修正前)
TimePrecision=6 (修正後)
[SqlSysDatatypes]
TIMESTAMP=%Library.TimeStamp (修正前)
TIMESTAMP=%Library.PosixTime (修正後)
バイナリデータを保存する場合、サイズの上限が指定できる場合はVARBINARYを使用してください。LONGVARBINARYはサイズ上限が無い代わりに、内部でストリーム形式で保存する機構を伴うためパフォーマンスが低下します。
CREATE TABLE TestTable (ts TIMESTAMP, binaryA VARBINARY(512), binaryB VARBINARY(256))
VARBINARY使用時には、行全体のサイズに注意が必要です。SQLの行は、IRIS内部では、既定では下記のフォーマットで、1つのノードのデータ部(IRISの内部形式の用語でKV形式のバリューに相当します)に格納されます。このノードのサイズ上限は3,641,144バイトです。
長さ|データタイプ|データ|長さ|データタイプ|データ|...
この長さを超えると、<MAXSTRING>という内部エラーが発生し、INSERTが失敗します。
実行プランがコード化されたものがソースコードとして保存されます。デフォルトでは無効です。本稿では扱っていませんが、後の解析で有用になることもありますので、念のため有効化しておきます。
[SQL]
SaveMAC=1 <== 既定値は0です
この時点での実行結果は思った結果が得られないかもしれません。 ベンチマークプログラムによるレコードのINSERTにより、ユーザデータベースの自動拡張、一時データべースの自動拡張、WIJの自動拡張が、クエリにより、クエリプランの作成、インデックスの不足によるテーブルフルスキャンなどが発生している可能性があるためです。
(ベンチマーク実施により蓄積したデータの消去後の)2回目以降は、インデックスの不足以外の問題は解消されているので、パフォーマンスが向上するかもしれません。 また、これとは逆にジャーナルは、随時蓄積していきますので、ベンチマーク実施を繰り返すうちに、いずれはディスクの空き容量を圧迫します。 適宜ジャーナルファイルを削除してください。運用環境では絶対禁止の方法ですが、データベースミラーリングを使用しておらず、データの保全が必要のないベンチマーク環境でしたら、最新のジャーナルファイル以外をO/Sシェルでrmしてしまって構いません。
これ以後の、細かな確認作業はさておき、まずは上記の項目の実施をスタートラインとすることをお勧めします。
この記事では、スナップショットを使用したソリューションとの統合の例を使って、_外部バックアップ_による Caché のバックアップ方法を紹介します。 このところ私が目にするソリューションの大半は、Linux の VMware にデプロイされているため、この記事の大半では、例として、ソリューションが VMware スナップショットテクノロジーをどのように統合しているかを説明しています。
Caché をインストールすると、Caché データベースを中断せずにバックアップできる Caché オンラインバックアップが含まれています。 しかし、システムがスケールアップするにつれ、より効率的なバックアップソリューションを検討する必要があります。 Caché データベースを含み、システムをバックアップするには、スナップショットテクノロジーに統合された_外部バックアップ_をお勧めします。
詳しい内容は外部バックアップのオンラインドキュメンテーションに説明されていますが、 主な考慮事項は次のとおりです。
「スナップショットの整合性を確保するために、スナップショットが作成される間、Caché はデータベースへの書き込みをfreezeする方法を提供しています。 スナップショットの作成中は、データベースファイルへの物理的な書き込みのみがfreezeされるため、ユーザーは中断されることなくメモリ内で更新を実行し続けることができます。」
また、仮想化されたシステム上でのスナップショットプロセスの一部によって、バックアップされている VM にスタンタイムと呼ばれる短い無応答状態が発生することにも注意してください。 通常は 1 秒未満であるため、ユーザーが気付いたり、システムの動作に影響を与えたりすることはありませんが、状況によってはこの無応答状態が長引くことがあります。 無応答状態が Caché データベースミラーリングの QoS タイムアウトより長引く場合、バックアップノードはプライマリに障害が発生したとみなし、フェイルオーバーします。 この記事の後の方で、ミラーリング QoS タイムアウトを変更する必要がある場合に、スタンタイムをどのように確認できるかについて説明します。
この記事では、Caché オンラインドキュメンテーション『Backup and Restore Guide（バックアップと復元ガイド）』も確認する必要があります。
ほかのソリューションがない場合は、ダウンタイム無しでバックアップを行えるこのソリューションが InterSystems データプラットフォームに同梱されています。 _Caché オンラインバックアップ_は、Caché データベースファイルのみをバックアップするもので、データに割り当てられたデータベースのすべてのブロックをキャプチャし、出力をシーケンシャルファイルに書き込みます。 Caché Online Backup は累積バックアップと増分バックアップをサポートしています。
VMware の文脈では、Caché Online Backup はゲスト内で発生するバックアップソリューションです。 ほかのゲスト内ソリューションと同様に、Caché Online Backup の動作は、アプリケーションが仮想化されていようが、ホストで直接実行していようが、基本的に変わりません。 Caché Online Backup は、システムバックアップと連携しながら Caché のオンラインバックアップ出力ファイルを、アプリケーションが使用しているその他すべてのファイルシステムとともに、バックアップメディアにコピーします。 最小限のシステムバックアップには、インストールディレクトリ、ジャーナルおよび代替ジャーナルディレクトリ、アプリケーションファイル、およびアプリケーションが使用する外部ファイルを含むすべてのディレクトリを含める必要があります。
Caché Online Backup は、Caché データベースやアドホックバックアップのみをバックアップする低コストのソリューションを実装したいと考えている小規模サイト向けのエントリレベルのアプローチとして捉えてください。ミラーリングをセットアップする際のバックアップなどに役立てられます。 しかし、データベースのサイズが増加したり、Caché が顧客のデータランドスケープの一部でしかない場合は、_外部バックアップ_にスナップショットテクノロジーとサードパーティ製ユーティリティを合わせたソリューションがベストプラクティスとして推奨されます。非データベースファイルのバックアップ、より高速な復旧時間、エンタープライズ全体のデータビュー、より優れたカタログと管理用ツールなど、さまざまなメリットが得られます。
VMware を例として使用します。VMware で仮想化すると、VM 全体を保護するための追加機能と選択肢が追加されます。 ソリューションの仮想化が完了した時点で、オペレーティングシステム、アプリケーション、データを含むシステムを .vmdk（とその他の）ファイル内に効果的にカプセル化したことになります。 これらのファイルの管理は非常に簡単で、必要となった場合にはシステム全体の復旧に使用できるため、オペレーティングシステム、ドライバ、サードパーティ製アプリケーション、データベースとデータベースファイルなどのコンポーネントを個別に復旧して構成する必要のある物理システムで同じような状況が発生した場合とは大きく異なります。
VMware の vSphere Data Protection（VDP）や、Veeam や Commvault などのサードパーティ製バックアップソリューションでは、VMware 仮想マシンスナップショットを使用してバックアップを作成しています。 VMware スナップショットの概要を説明しますが、詳細については、VMware ドキュメンテーションを参照してください。
スナップショットは VM 全体に適用されるものであり、オペレーティングシステムとすべてのアプリケーションまたはデータベースエンジンはスナップショットが発生していることを認識しないということに注意してください。 また、次のことにも注意してください。
VMware スナップショット自体はバックアップではありません！
スナップショットは、バックアップソフトウェアによるバックアップの作成を_可能にします_が、スナップショット自体はバックアップではありません。
VDP とサードパーティ製バックアップソリューションは、バックアップアプリケーションとともに VMware スナップショットプロセスを使用して、スナップショットの作成と、非常に重要となるその削除を管理します。 おおまかに見ると、VMware スナップショットを使用した外部バックアップのイベントのプロセスと順序は次のとおりです。
バックアップソリューションは、変更ブロック追跡（CBT）などのほかの機能も使用し、増分または累積バックアップを可能にして速度と効率性（容量節約において特に重要）を実現します。また、一般的に、データの重複解除や圧縮、スケジューリング、整合性チェックなどで IP アドレスが更新された VM のマウント、VM とファイルレベルの完全復元、およびカタログ管理などの重要な機能性も追加します。
適切に管理されていない、または長期間実行されたままの VMware スナップショットは、ストレージを過剰に消費し（データの変更量が増えるにつれ、差分ファイルが増加し続けるため）、VM の速度を低下させてしまう可能性があります。
本番インスタンスで手動スナップショットを実行する前に、十分に検討する必要があります。 なぜ実行しようとしているのか、 スナップショットが作成された時間に戻すとどうなるか、 作成とロールバック間のすべてのアプリケーショントランザクションはどうなるか、といったことを検討してください。
バックアップソフトウェアがスナップショットを作成し、削除しても問題ありません。 スナップショットの存続期間は、短期間であるものなのです。 また、バックアップ戦略においては、ユーザーやパフォーマンスへの影響をさらに最小限に抑えられるように、システムの使用率が低い時間を選ぶことも重要です。
スナップショットを作成する前に、保留中のすべての書き込みがコミットされ、データベースが一貫した状態になるように データベースを静止させる必要があります。 Caché は、スナップショットが作成される間、データベースへの書き込みをコミットして短時間フリーズ（停止）するメソッドと API を提供しています。 こうすることで、スナップショットの作成中は、データベースファイルへの物理的な書き込みのみがフリーズされるため、ユーザーは中断されることなくメモリ内で更新を実行し続けることができます。 スナップショットがトリガーされると、データベースの書き込みが再開し、バックアップはバックアップメディアへのデータのコピーを続行します。 フリーズからの復旧は、非常に短時間（数秒）で発生します。
書き込みを一時停止するのに加え、Caché Freeze は、ジャーナルファイルの切り替えとジャーナルへのバックアップマーカーの書き込みも処理します。 ジャーナルファイルは、物理データベースの書き込みがフリーズしている間、通常通りに書き込みを続けます。 物理データベースの書き込みがフリーズしている間にシステムがクラッシュした場合、データは、起動時に、通常通りジャーナルから復元されます。
以下の図は、整合性のあるデータベースイメージを使用してバックアップを作成するための、VMware スナップショットを使用した Freeze と Thaw の手順を示しています。
Freeze から Thaw の時間が短いところに注目してください。読み取り専用の親をバックアップターゲットにコピーする時間でなく、スナップショットを作成する時間のみです。
vSphere では、スナップショット作成のいずれか側で自動的にスクリプトを呼び出すことができ、この時に、Caché Freeze と Thaw が呼び出されます。 注意: この機能が正しく機能するために、ESXi ホストは _VMware ツール_を介してゲストオペレーティングシステムにディスクを静止するように要求します。
VMware ツールは、ゲストオペレーティングシステムにインストールされている必要があります。
スクリプトは、厳密な命名規則と場所のルールに準じる必要があります。 ファイルの権限も設定されていなければなりません。 以下は、Linux の VMware の場合のスクリプト名です。
# /usr/sbin/pre-freeze-script
# /usr/sbin/post-thaw-script
以下は、InterSystems のチームが内部テストラボインスタンスに対して、Veeam バックアップで使用する Freeze と Thaw のスクリプト例ですが、ほかのソリューションでも動作するはずです。 これらの例は、vSphere 6 と Red Hat 7 で検証され、使用されています。
これらのスクリプトは例として使用でき、方法を示すものではありますが、各自の環境で必ず検証してください！
#!/bin/sh
#
# Script called by VMWare immediately prior to snapshot for backup.
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Pre freeze script started" >> $SNAPLOG
exit_code=0
# Only for running instances
for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to freeze $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Freeze
csession $INST -U '%SYS' "##Class(Backup.General).ExternalFreeze(\"$LOGFILE\",,,,,,1800)" >> $SNAPLOG $
status=$?
case $status in
5) echo "`date`: $INST IS FROZEN" >> $SNAPLOG
;;
3) echo "`date`: $INST FREEZE FAILED" >> $SNAPLOG
logger -p user.err "freeze of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when freezing $INST"
exit_code=1
;;
esac
echo "`date`: Completed freeze of $INST" >> $SNAPLOG
done
echo "`date`: Pre freeze script finished" >> $SNAPLOG
exit $exit_code
#!/bin/sh
#
# Script called by VMWare immediately after backup snapshot has been created
# Tested on Red Hat 7.2
#
LOGDIR=/var/log
SNAPLOG=$LOGDIR/snapshot.log
echo >> $SNAPLOG
echo "`date`: Post thaw script started" >> $SNAPLOG
exit_code=0
if [ -d "$LOGDIR" ]; then
# Only for running instances
for INST in `ccontrol qall 2>/dev/null | tail -n +3 | grep '^up' | cut -c5- | awk '{print $1}'`; do
echo "`date`: Attempting to thaw $INST" >> $SNAPLOG
# Detailed instances specific log
LOGFILE=$LOGDIR/$INST-pre_post.log
# Thaw
csession $INST -U%SYS "##Class(Backup.General).ExternalThaw(\"$LOGFILE\")" >> $SNAPLOG 2>&1
status=$?
case $status in
5) echo "`date`: $INST IS THAWED" >> $SNAPLOG
csession $INST -U%SYS "##Class(Backup.General).ExternalSetHistory(\"$LOGFILE\")" >> $SNAPLOG$
;;
3) echo "`date`: $INST THAW FAILED" >> $SNAPLOG
logger -p user.err "thaw of $INST failed"
exit_code=1
;;
*) echo "`date`: ERROR: Unknown status code: $status" >> $SNAPLOG
logger -p user.err "ERROR when thawing $INST"
exit_code=1
;;
esac
echo "`date`: Completed thaw of $INST" >> $SNAPLOG
done
fi
echo "`date`: Post thaw script finished" >> $SNAPLOG
exit $exit_code
# sudo chown root.root /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
# sudo chmod 0700 /usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script
スクリプトが正しく動作することをテストするには、VM でスナップショットを手動で実行し、スクリプトの出力を確認することができます。 以下のスクリーンショットは、［Take VM Snapshot（VM スナップショットの作成）］ダイアログとオプションを示します。
選択解除- ［Snapshot the virtual machine's memory（仮想マシンのメモリをスナップショットする）］
選択 - ［Quiesce guest file system (Needs VMware Tools installed)（ゲストファイルシステムを静止する: VMware ツールのインストールが必要）］チェックボックス。スナップショットを作成する際にゲストオペレーティングシステムで実行中のプロセスを一時停止し、ファイルシステムのコンテンツが既知の整合性のある状態を保つようにします。
重要！ テストの後、スナップショットを必ず削除してください！！！！
スナップショットが作成される際に、静止フラグが真であり、仮想マシンがオンである場合、VMware ツールによって仮想マシンのファイルシステムが静止されます。 ファイルシステムの静止は、ディスク上のデータをバックアップに適した状態にするプロセスです。 このプロセスには、オペレーティングシステムのメモリ内キャッシュからディスクへのダーティバッファのフラッシュといった操作が含まれる場合があります。
以下の出力は、操作の一環としてスナップショットを含むバックアップを実行した後に、上記の Freeze/Thaw スクリプトの例で設定された $SNAPSHOT ログファイルのコンテンツを示しています。
Wed Jan 4 16:30:35 EST 2017: Pre freeze script started
Wed Jan 4 16:30:35 EST 2017: Attempting to freeze H20152
Wed Jan 4 16:30:36 EST 2017: H20152 IS FROZEN
Wed Jan 4 16:30:36 EST 2017: Completed freeze of H20152
Wed Jan 4 16:30:36 EST 2017: Pre freeze script finished
Wed Jan 4 16:30:41 EST 2017: Post thaw script started
Wed Jan 4 16:30:41 EST 2017: Attempting to thaw H20152
Wed Jan 4 16:30:42 EST 2017: H20152 IS THAWED
Wed Jan 4 16:30:42 EST 2017: Completed thaw of H20152
Wed Jan 4 16:30:42 EST 2017: Post thaw script finished
この例では、Freeze から Thaw までに 6 秒経過していることがわかります（16:30:36～16:30:42）。 この間、ユーザー操作は中断されていません。 _独自のシステムからメトリックを収集する必要があります_が、背景としては、この例は、IO ボトルネックがなく、平均 200 万 Glorefs/秒、17 万 Gloupds/秒、および毎秒あたり平均 1,100 個の物理読み取りと書き込みデーモン 1 サイクル当たりの書き込み 3,000 個の BM でアプリケーションベンチマークを実行しているシステムから得たものです。
メモリはスナップショットの一部ではないため、再起動すると、VM は再起動して復元されることに注意してください。 データベースファイルは整合性のある状態です。 バックアップを「再開」するのではなく、ファイルを既知の時点の状態にする必要があります。 その後で、ファイルが復元されたら、ジャーナルと、アプリケーションとトランザクションの整合性に必要なその他の復元手順をロールフォワードできます。
その他のデータ保護を追加するには、ジャーナルの切り替えを単独で実行することもでき、ジャーナルは、たとえば 1 時間ごとに別の場所にバックアップまたは複製されます。
以下は、上記の Freeze と Thaw スクリプトの $LOGFILE の出力で、スナップショットのジャーナルの詳細を示しています。
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Suspending system
Journal file switched to:
/trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:35: Backup.General.ExternalFreeze: Start a journal restore for this backup with journal file: /trak/jnl/jrnpri/h20152/H20152_20170104.011
Journal marker set at
offset 197192 of /trak/jnl/jrnpri/h20152/H20152_20170104.011
01/04/2017 16:30:36: Backup.General.ExternalFreeze: System suspended
01/04/2017 16:30:41: Backup.General.ExternalThaw: Resuming system
01/04/2017 16:30:42: Backup.General.ExternalThaw: System resumed
VM スナップショットの作成時、バックアップが完了してスナップショットがコミットされた後、VM を短時間フリーズする必要があります。 この短時間のフリーズは、VM のスタンと呼ばれることがよくあります。 スタンタイムについてよく説明されたブログ記事は、こちらをご覧ください。 以下に要約した内容を示し、Caché データベースの考慮事項に照らして説明します。
スタンタイムに関する記事より: 「VM スナップショットを作成するには、（i）デバイスの状態をディスクにシリアル化し、（ii）現在実行中のディスクを閉じてスナップショットポイントを作成するために、VM は「スタン」されます（無応答状態になります）。… 統合時、VM は、ディスクを閉じて統合に最適な状態にするために、「スタン」されます。」
スタンタイムは、通常数百ミリ秒です。ただし、コミットフェーズ中にディスクの書き込みアクティビティが非常に高い場合には、スタンタイムが数秒に長引くことがあります。
VM が、Caché データベースミラーリングに参加するプライマリまたはバックアップメンバーであり、スタンタイムがミラーのサービス品質（QoS）タイムアウトより長引く場合、ミラーはプライマリ VM に失敗としてレポートし、ミラーのテイクオーバーを開始します。
2018 年 3 月更新: 同僚の Pter Greskoff から指摘されました。バックアップミラーメンバーは、VM スタン中またはプライマリミラーメンバーが利用不可である場合には、QoS タイムアウトの半分超という短時間でフェイルオーバーを開始することがあります。
QoS の考慮事項とフェイルオーバーのシナリオの詳細については、「Quality of Service Timeout Guide for Mirroring（ミラーリングのサービス品質タイムアウトに関するガイド）」という素晴らしい記事を参照できますが、以下に、VM スタンタイムと QoS に関する要約を示します。
バックアップミラーが、QoS タイムアウトの半分の時間内にプライマリミラーからメッセージを受信しない場合、ミラーはプライマリが動作しているかどうかを確認するメッセージを送信します。 それからバックアップはさらに QoS タイムアウトの半分の時間、プライマリマシンからの応答を待機します。 プライマリからの応答がない場合、プライマリは停止しているとみなされ、バックアップがテイクオーバーします。
ビジー状態のシステムでは、プライマリからバックアップミラーにジャーナルが継続的に送信されるため、バックアップはプライマリが動作しているかどうかを確認する必要はありません。 ただし、バックアップが発生している可能性が高い静止時間中、アプリケーションがアイドル状態である場合、QoS タイムアウトの半分以上の時間、プライマリとバックアップミラーの間でメッセージのやり取りがない可能性があります。
これは Peter が提示した例ですが、このタイムフレームを、QoS タイムアウトが :08 秒で VM スタンタイムが :07 秒のアイドル状態にあるシステムで考えてみましょう。
上記のリンク先の記事にある「Pitfalls and Concerns when Configuring your Quality of Service Timeout（サービス品質タイムアウトを構成する際の落とし穴と考慮事項）」のセクションもお読みください。QoS を必要な期間だけ確保する際のバランスが説明されています。 QoS が長すぎる場合、特に 30 秒を超える場合も問題を引き起こす可能性があります。
2018 年 3 月更新の終了:
ミラーリングの QoS の詳細については、ドキュメンテーションを参照してください。
スタンタイムを最小限に抑える戦略には、データベースアクティビティが低い場合にバックアップを実行することと、ストレージを十分にセットアップすることが挙げられます。
上記で述べたように、スナップショットの作成時に指定できるオプションがいくつかあります。その 1 つは、スナップショットにメモリ状態を含めることです。_Caché データベースのバックアップにはメモリ状態は不要である_ことに注意してください。 メモリフラグが設定されている場合、仮想マシンの内部状態のダンプがスナップショットに含められます。 メモリスナップショットの作成には、もっと長い時間がかかります。 メモリスナップショットは、実行中の仮想マシンの状態を、スナップショットが作成された時の状態に戻すために使用されます。 これは、データベースファイルのバックアップには必要ありません。
メモリスナップショットを作成する場合、仮想マシンの状態全体が停止しますが、スタンタイムはさまざまです。
前述のとおり、バックアップでは、整合性のある使用可能なバックアップを保証するために、手動スナップショットで、またはバックアップソフトウェアによって、静止フラグを true に設定する必要があります。
ESXi 5.0 より、スナップショットのスタンタイムは、以下のようなメッセージで仮想マシンのログファイル（vmware.log）に記録されます。
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
スタンタイムはミリ秒単位であるため、上記の例にある 38123 us は 38123/1,000,000 秒または 0.038 秒となります。
スタンタイムが許容範囲内であることを確認するため、またはスタンタイムが長引くせいで問題が発生していると思われる場合にトラブルシューティングを実施するため、関心のある VM のフォルダから vmware.log ファイルをダウンロードして確認することができます。 ダウンロードしたら、以下の Linux コマンドの例を使うなどして、ログを抽出しソートできます。
vSphere 管理コンソールまたは ESXi ホストコマンドラインから VMware サポートバンドルを作成するなど、サポートログのダウンロードにはいくつかの方法があります。 全詳細については VMware ドキュメンテーションを参照できますが、以下は、スタンタイムを確認できるように、vmware.log ファイルを含む非常に小さなサポートバンドルを作成して収集する簡単な方法です。
VM ファイルが配置されているディレクトリの正式な名称が必要となります。 ssh を使用してデータベース VM が実行している ESXi ホストにログオンし、コマンド vim-cmd vmsvc/getallvms を使用して vmx ファイルとそれに関連付けられた一意の正式名称を一覧表示します。
たとえば、この記事で使用されているデータベース VM の正式な名称は次のように出力されます。 26 vsan-tc2016-db1 [vsanDatastore] e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0/vsan-tc2016-db1.vmx rhel7_64Guest vmx-11
次に、ログファイルのみを収集してバンドルするコマンドを実行します。vm-support -a VirtualMachines:logs
コマンドによって、以下の例のように、サポートバンドルの場所が表示されます。 To see the files collected, check '/vmfs/volumes/datastore1 (3)/esx-esxvsan4.iscinternal.com-2016-12-30--07.19-9235879.tgz'.
これで、sftp を使用してファイルをホストから転送し、さらに処理して確認できるようになりました。
この例では、サポートバンドルを解凍した後に、データベース VM の正式名称に対応するパスに移動します。 この場合は、 <bundle name>/vmfs/volumes/<host long name>/e2fe4e58-dbd1-5e79-e3e2-246e9613a6f0 というパスになります。
そこで番号付きの複数のログファイルが表示されます。最新のログファイルには番号は付きません。つまり、vmware.log と示されます。 ログはわずか数百 KB ですが、たくさんの情報が記載されています。ただし、注目するのは stun/unstun の時間のみで、grep を使うと簡単に見つけ出すことができます。 次は、その記載例です。
$ grep Unstun vmware.log
2017-01-04T21:30:19.662Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 1091706 us
---
2017-01-04T22:15:58.846Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 38123 us
2017-01-04T22:15:59.573Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 298346 us
2017-01-04T22:16:03.672Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 301099 us
2017-01-04T22:16:06.471Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 341616 us
2017-01-04T22:16:24.813Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 264392 us
2017-01-04T22:16:30.921Z| vcpu-0| I125: Checkpoint_Unstun: vm stopped for 221633 us
この例では、2つのグループのスタンタイムを確認できます。1 つはスナップショップ作成時、そしてもう 1 つは、各ディスクのスナップショットが削除/統合された 45 分後（バックアップソフトウェアが読み取り専用 vmx ファイルのコピーを完了したとき）のものです。 上記の例では、最初のスタンタイムは 1 秒をわずかに上回っていますが、ほとんどのスタンタイムは 1 秒未満であることがわかります。
短時間のスタンタイムは、エンドユーザーが気付くものではありませんが、 Caché データベースミラーリングなどのシステムプロセスは、インスタンスが「アライブ」であるかどうかを継続的に監視しています。 スタンタイムがミラーリング QoS タイムアウトを超える場合、ノードは接続不可能であり「停止」状態とみなされ、フェイルオーバーがトリガーされます。
ヒント: すべてのログを確認するか、トラブルシューティングを実行する場合には、grep コマンドが役立ちます。すべての vmware*.log ファイルに対して grep を使用し、異常値、またはスタンタイムが QoS タイムアウトに達しているインスタンスを探してください。 以下のコマンドは、出力をパイプ処理し、awk で書式設定しています。
grep Unstun vmware* | awk '{ printf ("%'"'"'d", $8)} {print " ---" $0}' | sort -nr
通常稼働時に定期的にシステムを監視し、スタンタイムと、ミラーリングなどの HA 向けの QoS タイムアウトへの影響を理解しておく必要があります。 前述のとおり、スタンタイムまたはスタン解除タイムを最小限に抑える戦略には、データベースとストレージのアクティビティが低い場合にバックアップを実行することと、ストレージを十分にセットアップすることが挙げられます。 常時監視の場合、ログは、VMware ログのインサイトなどのツールを使用して処理できるかもしれません。
InterSystems データプラットフォームのバックアップと復元操作について、今後の記事で再度取り上げる予定です。 それまでは、システムのワークフローに基づいたコメントや提案がある場合は、以下のコメントセクションに投稿してください。
開発者のみなさん、こんにちは！
InterSystems IRIS Data Platform を使用してオープンソースソリューションを作成するコンテストへようこそ！
今回のコンテスト用テンプレートはこちら！（8/10 更新） ➡️ IRIS-FHIR-Template ⬅️
（InterSystems IRIS for Health のプレビューリリース版：2020.3 が利用されている開発テンプレートです）
テンプレートの日本語 Readme をご用意しています。
優勝特典
１、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。
🥇 1位 - $2,000
🥈 2位 - $1,000
🥉 3位 - $500
2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。
🥇 1位 - $1,000
🥈 2位 - $500
複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。
参加資格
どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます）
コンテストのスケジュール
8月10日～23日 応募期間
8月24日～30日 投票
8月31日 優秀者発表
コンテストのテーマ
InterSystems IRISは、管理ポータルへのアクセス方法がデフォルトではhttpとなっており、クライアントが社内、サーバがクラウドという配置の場合、なんらかの方法でトラフィックを暗号化したいと考える方も多いかと思います。
そこで、AWS上にて稼働中のIRISの管理ポータル(あるいは各種RESTサービス)との通信を暗号化する方法をいくつかご紹介したいと思います。
本記事では、アクセスにIRIS組み込みのapacheサーバを使用しています。ベンチマーク目的や本番環境のアプリケーションからのアクセス方法としては使用しないでください。
短期間・少人数での開発・動作検証・管理目的でのアクセスを暗号化する事を想定しています。
ドメイン名とメジャーな認証局発行のSSLサーバ証明書を用意できればベストなのですが、上記のような用途の場合、コスト面でなかなか難しいと思います。
ですので、下記の証明書の使用を想定しています。
- 自己署名(いわゆるオレオレ証明書)
- 自分で建てた認証局で署名した証明書(いわゆるオレオレ認証局)
また、下記のような実行環境を想定しています。
開発者の皆さん、こんにちは。
今日はAzure上でIRIS for Healthをデプロイし、FHIRリポジトリを構築する方法をご紹介したいと思います。
AzureのMarketPlaceで「InterSystems」をキーワードに検索していただくと、以下のように複数のInterSystems製品がヒットします。
今日はこの製品の中から、InterSystems IRIS for Health Community Editionを選択し、FHIRリポジトリを構築します。
仮想マシンのサイズや、ディスク、ネットワーク等には特に制約や条件はありません。
Azureで提供されている最小の構成でもIRIS for Healthを動かすこともできます。
IRIS for Health Community Editionのデプロイに成功するとこのような画面に遷移します。
私の例では、コンピュータ名をIRIS4HFHIRSERVERとしています。
パブリックIPアドレスはマスクしていますが、このIPアドレスを使ってIRIS管理ポータルにアクセスしてみましょう。
http://<パブリックIPアドレス>:52773/csp/sys/UtilHome.csp
52773は管理ポータルにアクセスするためのポート番号であり、Azure上でデプロイするとこのポート経由でアクセスできるように既に構成が変更されています。
開発者のみなさん、こんにちは！
インターシステムズは、2020年7月21日（火）に オンラインにて開催された開発者向けイベント「Developers Summit 2020 Summer」（主催：翔泳社）に協賛し、セミナーで IRIS プログラミングコンテストについてご紹介しました。
ご紹介内容は、コンテストに限らず、コンテナを使用した開発環境の整備にも使えますので、セミナーを見逃された方もぜひご覧ください！
もくじ
※ YouTubeでご覧いただくと目次の秒数にジャンプできます。
0:00～ InterSystems が開催しているプログラミングコンテストの概要
2:38～ 本セッションの目標
4:21～ ≪腕試しの準備その1≫開発環境の「テンプレート」で何が提供されるか
8:26～ テンプレート起動迄の手順（各コンテスト共通）
10:02～ 優勝作品のご紹介（2020年5月分開催 Native APIの回）
11:40～ ≪腕試しの準備その２≫ご応募までの実際の流れ
RESTサーバ作成用のテンプレート
13:00～ テンプレートで準備されるREST サーバ作成環境について
16:47～ テンプレートの中身解説＋コンテナの開始とサンプルコードの実行（実演）
23:02～ GET要求 /test で動作する testMethod()の追加と実行
みなさん、こんにちは。
Open Exchangeで FHIRリポジトリに接続するFHIR Patient Browserが公開されました。
https://openexchange.intersystems.com/package/FHIR-Patient-Browser
Open-Source のJavaScriptライブラリであるfhir.jsを利用した、FHIRサーバに接続するためのFHIRクライアントアプリケーションです。
この記事では、このOpen Exchangeアプリケーション実行に必要なNode.jsのインストールや、コンパイルおよび実行方法について解説します。(筆者もNode.jsのインストールや実行は初めてです！)
上記Open Exchangeリンク先の「Download」をクリックすると、以下のGithubサイトへ移動します。
https://github.com/antonum/FHIRPatientBrowser
以下の画像のようにCodeからZIP形式でダウンロードし、展開します。（もちろんGitなどのツールを利用して入手してもOKです。）
Node.jsのインストーラーはこちらのサイトからダウンロード可能です。
システム開発では、集計作業や他システムとの連携など、数十秒ごとにバックグラウンドで処理を実行する、常駐プロセスが必要になるケースが多々あるかと思います。
Cachéでは、Jobコマンドを使って常駐プロセスを作成しますが、実際にシステムを安定稼働させるには、以下の監視の仕組みが必要でした。
IRISの場合、Interoperabilityにはこれらの機能が装備されています。したがって、Interoperabilityの機能を使えば、簡単に常駐プロセスを起動、監視することができます。
常駐プロセスの作成には以下の作業を行います。
スタジオを起動、常駐プロセスを実行するネームスペースに接続し、「ファイル」メニューの「新規作成...」をクリックします。
皆さんこんにちは。
第4回 InterSystems IRIS プログラミングコンテスト（AI／MLコンテスト） への応募は終了しました。コンテストへのご参加、またご興味をお持ちいただきありがとうございました。
この記事では、見事受賞されたアプリケーションと開発者の方々を発表します！
🏆 審査員賞 - 特別に選ばれた審査員から最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $2,000 は iris-integratedml-monitor-example を開発された José Roberto Pereir さんに贈られました！
🥈 2位 - $1,000 は iris-ml-suite を開発された Renato Banza さんに贈られました！
🥉 3位 - $500 は ESKLP を開発された Aleksandr Kalinin さんに贈られました！
🏆 開発者コミュニティ賞 - 最も多くの票を獲得したアプリケーションに贈られます。
🥇 1位 - $1,000 は iris-ml-suite を開発された Renato Banza さんに贈られました！
🥈 2位 - $250 は iris-integratedml-monitor-example を開発された José Roberto Pereir さんに贈られました！
IRIS で REST サーバを作成する際に準備する REST ディスパッチクラスを API ファーストの手順で作成する方法を解説します。
（OpenAPI 2.0に基づいて作成したアプリケーション定義を使用してディスパッチクラスを作成する手順を解説します）
このビデオには、以下の関連ビデオがあります。
もくじ
最初～ 復習ビデオ／関連ビデオについて など
2:36～ 作成するディスパッチクラスの内容
4:15～ RESTディスパッチクラス：APIファーストで作成する方法（手順説明）
5:55～ アプリケーションの仕様を定義する （例）
6:19～ IRISにアプリケーション仕様を登録する（説明）など
7:40～ POST要求の実行 (例)
8:24～ 実演
↓実演で使用したURL↓
http://localhost:52773/api/mgmnt/v2/user/crud2
10:32～ （POST要求の）実行結果
11:50～ ベースURLの設定（管理ポータルでの設定）＋ 実演
IRIS で作成する REST サーバの仕組みを解説します。
このビデオには、以下の関連ビデオがあります。
もくじ
0:55～ 今回の説明内容解説と関連ビデオについて
3:00～ RESTとは？
3:52～ 動作の仕組み
6:23～ RESTディスパッチクラスとは
8:04～ RESTディスパッチクラスの実装方法
8:34～ RESTディスパッチクラス：全て手動で作成する方法 概要
9:30～ RESTディスパッチクラス：APIファーストで作成する方法 概要
11:12～ 共通：ベースURLの設定（管理ポータルでの設定）
11:37～最後まで 確認できたこと
※YouTubeでご覧いただくと、もくじの秒数にジャンプできます。
この記事ではVMware ESXi 5.5以降の環境にCaché 2015以降を導入する場合の構成、システムのサイジング、およびキャパシティ計画のガイドラインを示します。
ここでは、皆さんがVMware vSphere仮想化プラットフォームについてすでに理解していることを前提としています。 このガイドの推奨事項は特定のハードウェアやサイト固有の実装に特化したものではなく、vSphereの導入を計画して構成するための完全なガイドとして意図されたものでもありません。これは、皆さんが選択可能なベストプラクティス構成をチェックリストにしたものです。 これらの推奨事項は、皆さんの熟練したVMware実装チームが特定のサイトのために評価することを想定しています。
InterSystems データプラットフォームとパフォーマンスに関する他の連載記事のリストはこちらにあります。
注意: 本番データベースインスタンス用のVMメモリを予約し、Cachéに確実にメモリを使用させてデータベースのパフォーマンスに悪影響を与えるスワップやバルーニングの発生を防ぐ必要があることを強調するため、この記事を2017年1月3日に更新しています。 詳細については、以下のメモリセクションを参照してください。
InterSystems IRIS データ・プラットフォーム および InterSystems IRIS for Health バージョン 2020.2 CD をリリースしました。
こちらはCD(continuous delivery)リリースになりますので、OCI(Open Container Initiative)と呼ばれるDockerコンテナー形式でのみ使用可能です。
リリースのビルド番号は 2020.2.0.211.0 です。
InterSystems IRIS データ・プラットフォームバージョン 2020.2 は、以下の拡張機能を備えた重要なセキュリティアップデートを提供します。
・TLS 1.3のサポート
・SHA-3のサポート
InterSystems IRIS for Health バージョン 2020.2 にはさら以下の機能が含まれます。
・FHIR R4データ変換
・FHIRサーバーの新しい構成UI
・IHE RMUプロファイルのサポート
・IHEコネクタソンの更新
InterSystems System Alerting and Monitoring (InterSystems SAM) の最初のバージョン v1.0 をリリースしました。
InterSystems SAM v1.0 は、InterSystems IRISベースの製品に最新の監視ソリューションを提供します。アラート通知に加え、クラスタの高レベル
ビューや単一ノードのドリルダウンしたメトリック可視化をおこないます。
この最初のバージョンでは100を超える InterSystems IRIS カーネルのメトリックを可視化し、デフォルトで提供される Grafana テンプレートを
好みに応じて拡張することができます。
v1.0 はシンプルで直感的なベースラインとなることを目的としています。ぜひお試しいただき、ご要望等のフィードバックをお寄せください。
InterSystems SAM は、バージョン 2020.1 以降のインターシステムズベース製品の情報を表示できます。
InterSystems SAM はコンテナ形式でのみ使用可能です。SAM Managerコンテナに加えて、追加のオープンソースコンポーネント(Prometheus と
Grafana)が必要です。これらの追加コンポーネントはコンポーズファイルで自動的に追加されます。
** 2018年2月12日改訂
この記事はInterSystems IRISに関するものですが、Caché、Ensemble、およびHealthShareのディストリビューションにも適用されます。
メモリはページ単位で管理されます。 Linuxシステムでは、デフォルトのページサイズは4KBです。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11、およびOracle Linux 6では、HugePageと呼ばれるシステム構成に応じて、ページサイズを2MBまたは1GBに増やす方法が導入されました。
第一に、HugePagesは起動時に割り当てる必要があり、適切に管理や計算が行われていない場合はリソースが浪費される可能性があります。 結果的に、さまざまなLinuxディストリビューションでTransparent HugePagesがデフォルトで有効になっているカーネル2.6.38が導入されました。 これは、HugePagesの作成、管理、使用を自動化することを意図したものでした。 旧バージョンのカーネルもこの機能を備えている可能性がありますが、[always] に指定されておらず、 [madvise] に設定されている可能性があります。
私たちのほとんどは、多かれ少なかれDockerに慣れ親しんでいます。 Dockerを使用している人たちは、ほとんどのアプリケーションを簡単にデプロイし遊んで、何かを壊してしまってもDockerコンテナを再起動するだけでアプリケーションを復元できる点を気に入っています。
InterSystems も Docker を気に入っています。
InterSystems OpenExchange プロジェクトには、InterSystems IRISのイメージを簡単にダウンロードして実行できるDockerコンテナで実行するサンプルが多数掲載されています。また、Visual Studio IRISプラグインなど、その他の便利なコンポーネントもあります 。
特定のユースケース用の追加コードを使ってDockerでIRISを実行するのは簡単ですが、ソリューションを他のユーザーと共有する場合は、コマンドを実行し、コードを更新するたびに繰り返し実行するための何らかの方法が必要になります。 この記事では、継続的インテグレーション／継続的デリバリー （CI / CD）を使ってそのプロセスを簡素化する方法を説明します。
セットアップ
この記事では、InterSystems Technologiesに基づく、堅牢なパフォーマンスと可用性の高いアプリケーションを提供するリファレンスアーキテクチャをサンプルとして提供します。Caché、Ensemble、HealthShare、TrakCare、およびDeepSee、iKnow、Zen、Zen Mojoといった関連する組み込みテクノロジーに適用可能です。
Azureには、リソースを作成して操作するための、Azure ClassicとAzure Resource Managerという2つのデプロイメントモデルがあります。 この記事で説明する情報は、Azure Resource Managerモデル（ARM）に基づきます。
Microsoft Azureクラウドプラットフォームは、InterSystems製品すべてを完全にサポートできるクラウドサービスとして、IaaS（サービスとしてのインフラストラクチャ）向けの機能の豊富な環境を提供しています。 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 この記事では、こういった各分野の詳細について説明しています。
InterSystemsのテクノロジースタックを使用して独自のアプリを開発し、顧客側で複数のデプロイを実行したいとします。 開発プロセスでは、クラスをインポートするだけでなく、必要に応じて環境を微調整する必要があるため、アプリケーションの詳細なインストールガイドを作成しました。この特定のタスクに対処するために、インターシステムズは、%Installer（Caché／Ensemble）という特別なツールを作成しました 。 続きを読んでその使用方法を学んでください。
%Installer
このツールを使用すると、インストール手順ではなく、目的のCaché構成を記述するインストールマニフェストを定義できます。作成したい Caché 構成を記述します。必要な内容を記述するだけで、環境を変更するために必要なコードが自動的に生成されます。
したがって、マニフェストのみを配布する必要がありますが、インストール・コードはすべてコンパイル時に特定の Caché サーバ用に生成されます。
前回はシンプルなIRISアプリケーション をGoogleクラウドにデプロイしました。 今回は、同じプロジェクトを Amazon Web Services（アマゾンウェブサービス） のElastic Kubernetes Service （EKS）を使って、デプロイします。
IRISプロジェクトをあなた自身のプライベート・リポジトリにすでにFORKしていると想定します。この記事では<username>/my-objectscript-rest-docker-templateという名前にしています。 <root_repo_dir>は、そのルートディレクトリです。
開始する前に、 AWSコマンドラインインターフェースと、Kubernetesクラスタ作成用のシンプルなCLIユーティリティeksctlをインストールします。 AWSの場合 aws2 の使用を試すことができますが、ここで説明するようにkube設定ファイルでaws2の使用法を設定する必要があります 。
AWS EKS
この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチを紹介し、説明したいと思います。以下のようなトピックについて取り上げます。
この記事では、独自のコンテナを構築してデプロイ展開する方法について説明します。
コンテナは一時的なものなので、アプリケーションデータを保存するべきではありません。Durable %SYS の機能により設定、構成、 %SYSデータなどをホストボリュームに保存することができます。