検索

開発者の皆さんこんにちは！ 第7回 InterSystems IRIS プログラミングコンテスト（Interoperabilityコンテスト） への応募、投票が全て終了しました。コンテストへのご参加、またご興味をお持ちいただきありがとうございました。 今回のお知らせでは、見事受賞されたアプリケーションと開発者の方々を発表します！ 🏆 審査員賞　- 特別に選ばれた審査員から最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $2,000 は　Open API Client Gen を開発された Lorenzo Scalese さんに贈られました！ 🥈 2位 - $1,000 は OCR Service を開発された YURI MARX GOMES さんに贈られました！ 🥉 3位 - $250 は IRIS Interoperability Message Viewer を開発された Henrique Gonçalves Dias さんに贈られました！ 🥉 3位 - $250 は interoperability-integratedml-adapter を開発された José Roberto Pereira さんに贈られました！ 🏆 開発者コミュニティ賞　- 最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,000 は OCR Service を開発された YURI MARX GOMES さんに贈られました！ 🥈 2位 - $500 は IRIS Interoperability Message Viewer を開発された Henrique Gonçalves Dias さんに贈られました！ 🥉 3位 - $250 は Open API Client Gen を開発された Lorenzo Scalese さんに贈られました！ 🎊 受賞者の皆様、おめでとうございます！👏 今回の Interoperability コンテストにご注目いただきありがとうございます！ さて、次回のコンテストは・・・・・・？ InterSystems Analytics コンテストです！ 詳細については近日公開します！お見逃しなく！

開発者の皆さんこんにちは！IRIS プログラミングコンテスト 第7回の勝者が発表されたばかりですが、第8回のテーマが発表されました！ 今回のコンテストのテーマは 🏆 InterSystems Analytics Contest 🏆 です！ さぁ、年内最後のコンテストです！日本からのご応募お待ちしております！ 応募期間は 2020年12月7日～20日 です！ （投票期間は 2020年12月21日～27日、勝者発表は 12月28日を予定しています） 優勝特典 １、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 1位 - $2,000 🥈 2位 - $1,000 🥉 3位 - $500 2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。 🥇 1位 - $1,000 🥈 2位 - $500 複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。 参加資格 どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます） コンテストのスケジュール 12月7日～20日 応募期間（Open Exchange へ作成されたアプリケーションをアップロードいただける期間＝2週間です。この期間内であればアップロード後も自由に編集できます。） 12月21日～27日 投票（1週間） 12月28日 優秀者発表（US時間に発表します） コンテストのテーマ 💡 InterSystems IRIS を使用した分析ソリューションの開発 💡 1つ以上の InterSystems IRIS 分析機能（IRIS BI、IRIS NLP、IntegratedML、InterSystems Reports）を使用して、シンプルで説得力のある明確な可視化やストーリーを開発してください。 アプリケーションは、IRIS Community Edition、IRIS for Health Community Edition、IRIS Advanced Analytics Community Edition のいずれかで動作する必要があります。 また、アプリケーションはオープンソースであり、GitHubに公開していることも条件の一つです。 アプリケーションに特別な技術実装を導入した場合、技術的なボーナスを獲得できます。ボーナス詳細については後日発表します。 Helpful resources 1. アプリケーションの例（Open Exchange のアプリケーション） IRIS Analytics Template（テンプレートの使い方 日本語解説＋ビデオはこちら！） Samples BI Covid19 analytics Analyze This Game of Throne Analytics Pivot Subscriptions Samples Aviation Set Analysis Error Globals Analytics 2.コンテスト応募方法（このページ末尾のビデオをご参照ください） 3. オンラインコースや資料など（英語） DeepSee Overview DeepSee Analyzer Basics InterSystems Reports Resource guide iKnow First Look 4. ビデオ（英語） Creating InterSystems IRIS Analytics Solutions Using Docker & VSCode The Freedom of Visualization Choice: InterSystems BI A look at InterSystems Reports 5. サンプルデータ Adventure Works Synthea 審査及び投票ルール（英語） インターシステムズ社のプロダクトマネージャ、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」ボタンが表示されるので、クリックすると応募が完了します。

開発者の皆さん、こんにちは。 第9回 IRIS プログラミングコンテスト（マルチモデルコンテスト）の投票が開始されました！ 🔥 これだ！と思う一押し作品に投票お願いします！ 🔥 投票期間：1月25日～31日 （1週間） 投票方法は？Expert Nomination または Community Nomination を選択いただき、どの作品がどの順位になるかを指定しながら投票します。 Community Leaderboard： 順位 ポイント 1位 3点 2位 2点 3位 1点 そして、エキスパートノミネーションからの投票は以下の通りです（エキスパートのレベルが上がると獲得できるポイントも増えます！）。 Experts Leaderboard： エキスパートレベル 順位 1位 2位 3位 GM、モデレーター、プロダクトマネージャーのVIPレベル 9点 6点 3点 グローバルマスターズのエキスパートレベル 6点 4点 2点 グローバルマスターズのスペシャリストレベル 3点 2点 1点 エキスパートリーダーボードの投票はコミュニティリーダーボードにもポイント（1位3点、2位2点、3位1点）が加算されます。 投票方法について 投票は Open Exchange コンテストページで行われ、Open Exchange にサインインする必要があります。 投票期間であれば、一度投票した後も別のアプリケーションへ投票し直すこともできます（投票期間は1週間あります）。 なお、コンテスト参加者は投票週間の間にバグの修正やアプリケーションの改善を行うことができますので、アプリケーションのリリース情報についてもお見逃しなく！（サブスクリプション登録が行えます） ➡️ InterSystems オンラインコンテストの新しい投票ルールについて詳細はこちらをご参照ください。

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 を使ってデプロイする方法も含まれています。

開発者の皆さん、こんにちは！ 第9回のマルチモデルコンテストの 続報 📣 の「テクノロジーボーナス」についてご紹介します。 InterSystems Globals (key-value) InterSystems SQL InterSystems Objects Your data model ZPM Package deployment Docker container usage 詳細は以下ご参照ください。 InterSystems Globals (key-value) - 2 points InterSystems グローバルは、InterSystems IRIS に任意のデータを格納するために使用される多次元スパース配列です。各グローバル・ノードはキーとみなされ、値（バリュー）を設定することができます。InterSystems IRIS は、グローバルを管理するための ObjectScript のコマンドや Native API を含む一連の API を提供しています。 ObjectScript または Native API を介してグローバルを使用すると、2 ポイント獲得できます。 ツール： 管理ポータルでのグローバルの管理 ドキュメント: 多次元ストレージの使用法 (グローバル) グローバルの使用法 記事: グローバルはデータを保存するための魔法の剣です パート1 The art of mapping Globals to Classes ビデオ: Globals QuickStart InterSystems SQL (iKnow) - 2 points InterSystems IRISは、ObjectScript、REST API、xDBCを介してデータへのSQLアクセスを提供します。 アプリケーションで InterSystems SQL を使用すると、2 ポイント獲得できます。 ツール: VSCode SQL Tools DBeaver 管理ポータルの SQL インタフェースの使用法 Other SQL tools ドキュメント: SQL Access InterSystems SQL リファレンス 記事: InterSystems IRIS のクラスクエリ Your data model - 2 points InterSystems IRISは、独自のデータモデル API を公開するデータプラットフォームとして使用することができます。ObjectScript、REST API、Native API を利用して、時系列、空間、グラフ、RDF/トリプル、カラムストア、ドキュメントストアなどの特殊なデータモデルを提供する独自の API を公開することができます。 新しいデータモデル API を開発すると、2 ポイント獲得できます。 ZPM Package deployment - 2 points フルスタックアプリケーション用の ZPM(ObjectScript Package Manager) パッケージをビルドして公開し、それを使用してデプロイできるようにすると、2 ポイント獲得できます。 以下のコマンド実行例は、 IRIS に ZPM クライアントをインストールしパッケージをインストールしている例です。 zpm "install your-multi-model-solution" 詳しくは、ZPM client や ドキュメント をご参照ください。 Docker container usage - 2 points docker コンテナで動作する InterSystems IRIS を使用すると「Docker コンテナ」のボーナスポイントを獲得できます。 以下の docker コンテナを利用した開発環境テンプレートを使用しても、ボーナスポイントを獲得できます。 IRIS Interoperability Template Interoperability（相互運用性）については、Interoperabilityを使ってみよう！（日本語）の記事もぜひご参照ください（Interoperabilityの動作の仕組みやどんな開発が必要になるのか、などを7つの記事でご紹介しています）。 上記に掲載されている技術の使用方法についてご質問がありましたら、お気軽にコミュニティまでご質問ください！ コンテストへのご参加、お待ちしてます！ 注意：現在のテクノロジーボーナスリストはコンテスト開始前に変更される可能性もあります。予めご了承ください。

# はじめに データ分析は、急速に展開するこの時代において、ビジネス上の意思決定を行う上で欠かせない側面です。 組織はデータ分析に大きく依存して、十分な情報に基づく意思決定と競合優位の維持を行っています。 この記事では、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 の開発者プレビュープログラムの一環として、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 の開発者プレビュープログラムの一環として、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 のプレビューダウンロードページから入手いただけます。

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 のプレビューダウンロードページから入手いただけます。

[CI/CD シリーズ](https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-index)の新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。 今回は、相互運用性についてご紹介しましょう。 # 問題 アクティブな相互運用性プロダクションがある場合、2 つの個別のプロセスフローが存在します。メッセージを処理する稼動中のプロダクションと、コード、プロダクションの構成、および[システムデフォルト設定](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ECONFIG_other_default_settings)を更新する CI/CD プロセスフローです。 明らかに、CI/CD プロセスは相互運用性に影響しますが、 本題は次にあります。 - 更新中には実際に何が起きているのか？ - 更新中の本番停止を最小限に抑えるか失くしてしまうには、どうすればよいのか？ # 用語 - ビジネスホスト（BH）- 相互運用性プロダクションの構成可能な要素: ビジネスサービス（BS）、ビジネスプロセス（BP、BPL）、ビジネスオペレーション（BO）。 - ビジネスホストジョブ（ジョブ）- ビジネスホストのコードを実行し、相互運用性プロダクションによって管理される InterSystems IRIS ジョブ。 - プロダクション - 相互に接続されたビジネスホストのコレクション。 - システムデフォルト設定（SDS）- InterSystems IRIS がインストールされている環境に固有の値。 - アクティブメッセージ - 1 つのビジネスホストジョブによって現在処理されているリクエスト。 1 つのビジネスホストジョブに対するアクティブメッセージは最大 1 つです。 アクティブメッセージのないビジネスホストジョブはアイドルです。 # 何が起きているのか？ プロダクションのライフサイクルから見てみましょう。 ## プロダクションの起動 まず初めに、プロダクションを起動できます。 ネームスペースあたり 1 つのプロダクションのみを同時に実行でき、一般に（作業内容や過程を十分に理解していない限り）、ネームスペースごとに実行するプロダクションは 1 つ限りです。 1 つのネームスペース内で 2 つ以上の異なるプロダクションを切り替えるのは推奨されません。 プロダクションを起動すると、そのプロダクションに定義されたすべての有効なビジネスホストが起動します。 一部のビジネスホストが起動に失敗してもプロダクションの起動には影響しません。 ヒント: - システム管理ポータルから、または `##class(Ens.Director).StartProduction("ProductionName")` を呼び出してプロダクションを起動します。 - `OnStart` メソッドを実装して、プロダクションの起動時に（ビジネスホストジョブが起動する前に）任意のコードを実行します。 - プロダクションの起動は監査可能なイベントです。 誰がいつ起動したかを必ず監査ログで確認できます。 ## プロダクションの更新 プロダクションが起動した後、[Ens.Director](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Director) は実行中のプロダクションを継続的に監視します。 プロダクションの状態は 2 つあります。プロダクションクラスとシステムデフォルト設定に定義された _target state_ と、ジョブが作成されたときに適用された設定で現在実行しているジョブの _running state_ です。 希望する状態と現在の状態が同一である場合はすべて良好ですが、異なる場合にはプロダクションを更新する必要があります。 通常、この場合には、システム管理ポータルのプロダクション構成ページに赤い「更新」ボタンが表示されます。 プロダクションを更新すると、現在のプロダクションの状態をターゲットプロダクションの状態に一致させることになります。 プロダクションを更新するために `##class(Ens.Director).UpdateProduction(timeout=10, force=0)` を実行すると、各ビジネスホストにおいて以下が行われます。 1. アクティブな設定をプロダクション/SDS/クラスの設定と比較します。 2. (1) で不一致が生じた場合に限り、ビジネスホストは古いものとしてマークされ、更新が必要となります。 これを各ビジネスホストに対して実行した後、`UpdateProduction` は一連の変更をビルドします。 - ビジネスホストを停止 - ビジネスホストを起動 - プロダクション設定を更新 そしてその後で適用します。 このようにして、何も変更せずに設定を「更新」するとプロダクションが停止しません。 ヒント: - システム管理ポータルから、または `##class(Ens.Director).UpdateProduction(timeout=10, force=0)` を呼び出してプロダクションを更新します。 システム管理ポータルのデフォルトの更新タイムアウトは 10 秒です。 メッセージの処理がそれ以上かかることが分かっている場合は、タイムアウト時間がより長い `Ens.Director:UpdateProduction` を呼び出します。 - 更新タイムアウトはプロダクションの設定であり、より長い時間に値を変更できます。 この設定はシステム管理ポータルに適用されます。 ## コードの更新 `UpdateProduction` は古いコードで BH を更新することはありません。 これは安全を優先した動作ではありますが、根底にあるコードが変更した場合にすべての実行中の BH を自動的に更新する場合は、以下のように行います。 まず、以下のように読み込んでコンパイルします。 ```objectscript do $system.OBJ.LoadDir(dir, "", .err, 1, .load) do $system.OBJ.CompileList(load, "curk", .errCompile, .listCompiled) ``` `listCompiled` には、`u` フラグにより、実際にコンパイルされたすべての項目が含まれます（読み込まれるセットを最小限に抑えるには、[git diffs](https://github.com/intersystems-ru/GitLab/blob/master/isc/git/Diff.cls) を使用します）。 この `listCompiled` を使用して、コンパイルされたすべてのクラスの $lb を取得します。 ```objectscript set classList = "" set class = $o(listCompiled("")) while class'="" { set classList = classList _ $lb($p(class, ".", 1, *-1)) set class=$o(listCompiled(class)) } ``` その後で、再起動が必要な BH のリストを計算します。 ```sql SELECT %DLIST(Name) bhList FROM Ens_Config.Item WHERE 1=1 AND Enabled = 1 AND Production = :production AND ClassName %INLIST :classList ``` 最後に、`bhList` を取得した後に、影響のあるホストを停止して起動します。 ```objectscript for stop = 1, 0 { for i=1:1:$ll(bhList) { set host = $lg(bhList, i) set sc = ##class(Ens.Director).TempStopConfigItem(host, stop, 0) } set sc = ##class(Ens.Director).UpdateProduction() } ``` ## プロダクションの停止 プロダクションは停止可能です。つまり、すべての美自演すホストジョブにシャットダウンのリクエストを送信します（アクティブなメッセージがある場合はその処理が完了してから安全にシャットダウンされます）。 ヒント: - システム管理ポータルから、または `##class(Ens.Director).StopProduction(timeout=10, force=0)` を呼び出してプロダクションを停止します。 システム管理ポータルのデフォルトの停止タイムアウトは 120 秒です。 メッセージの処理がそれ以上かかることが分かっている場合は、タイムアウト時間がより長い `Ens.Director:StopProduction` を呼び出します。 - シャットダウンタイムアウトはプロダクションの設定です。 より長い時間に値を変更できます。 この設定はシステム管理ポータルに適用されます。 - `OnStop` メソッドを実装して、プロダクションの停止時に任意のコードを実行します。 - プロダクションの停止は監査可能なイベントであり、誰がいつ停止したのかを必ず監査ログで確認できます。 ここで重要なのは、プロダクションはビジネスホストの合計であることです。 - プロダクションを起動するとすべての有効なビジネスホストが起動します。 - プロダクションを停止するとすべての実行中のビジネスホストが停止します。 - プロダクションを更新すると、古いセットのビジネスホストが計算され、これらが先に停止されてからその直後にもう一度起動されます。 また、新たに追加されたビジネスホストは開始のみされ、プロダクションから削除されたビジネスホストは単に停止されます。 この流れで、ビジネスホストのライフサイクルに進みましょう。 ## ビジネスホストの起動 ビジネスホストは（プールサイズの設定値に応じて）同一のビジネスホストジョブで構成されています。 ビジネスホストを起動すると、すべてのビジネスホストジョブが起動します。 これらは並列して起動します。 個別のビジネスホストジョブは以下のように起動します。 1. 相互運用性はビジネスホストジョブになる新しいプロセスを JOB で起動します。 2. 新しいプロセスは相互運用性ジョブとして登録されます。 3. ビジネスホストコードとアダプターコードがプロセスメモリに読み込まれます。 4. ビジネスホストとアダプターに関連する設定がメモリに読み込まれます。 以下はその順序です。 a. プロダクション設定（システムデフォルトとクラス設定をオーバーライドします）。 b. システムデフォルト設定（クラス設定をオーバーライドします）。 c. クラス設定。 5. ジョブの準備が整い、メッセージを受け入れ始めます。 （4）が完了すると、ジョブは設定またはコードを変更できないため、新しい/同じコードと新しい/同じシステムデフォルト設定をインポートしても、現在実行中の相互運用性ジョブに影響しません。 ## ビジネスホストの停止 ビジネスホストジョブを停止すると、以下のようになります。 1. 相互運用性はジョブにメッセージ/入力の受け入れ停止を要求します。 2. アクティブなメッセージがある場合、ビジネスホストジョブにはそれを処理するための数秒のタイムアウトがあります（ジョブを完了、つまり BO の場合は `OnMessage` メソッド、BS の場合は `OnProcessInput` メソッド、BPL BP の場合は状態の `S` メソッド、BP の場合は `On*`メソッドを終了します）。 3. アクティブなメッセージがタイムアウトと `force=0` までに処理されていない場合、そのビジネスホストのプロダクションの更新は失敗します（SMP に赤い更新ボタンが表示されます）。 4. 以下のいずれかを満たす場合は停止します。 - アクティブなメッセージがない - アクティブなメッセージは `timeout` の前に処理された - アクティブなメッセージはタイムアウト前に処理されなかったが `force=1` で処理された 5. ジョブは 相互運用性から登録解除され停止します。 ## ビジネスホストの更新 ビジネスホストの更新では、ビジネスホストの現在実行中のジョブを停止し、新しいジョブを起動します。 ## ビジネスルール、ルーティングルール、DTL すべてのビジネスホストは、新しいバージョンのビジネスルール、ルーティングルール、および DTL が利用できるようになると直ちにそれらを使用し始めます。 この状況では、ビジネスホストの再起動は不要です。 # オフラインでの更新 とは言え、時にはプロダクションの更新には個別のビジネスホストの停止が必要です。 ## ルールは新しいコードで決まる この状況を考えてみてください。 任意の基準に基づいてメッセージをビジネスプロセス A または B にルーティングする現在のルーティングルール X があるとします。 新しいコミットにおいて、以下を同時に追加します。 - ビジネスプロセス C - メッセージを A、B、または C にルーティングする新しいバージョンのルーティングルール X このシナリオでは、先にルールを読み込んでからプロダクションを更新することはできません。 新しくコンパイルされるルールは、InterSystems IRIS がまだコンパイルしていないかもしれないビジネスプロセス C に直ちにルーティングし始めるか、相互運用性がまだ使用できるように更新されていないためです。 この場合、ルーティングルールでビジネスホストを無効に子、コードを更新し、プロダクションを更新して、ビジネスホストをもう一度有効にする必要がります。 注意: - [プロダクションデプロイファイル](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EGDV_deploying)を使用してプロダクションを更新する場合、影響されるすべての BH は自動的に無効化/有効化されます。 - InProc によって呼び出されたホストの場合、コンパイルによって呼び出し元が保持する特定のホストのキャッシュが無効になります。 ## ビジネスホスト間の依存関係 ビジネスホスト間の依存関係は重要です。 ビジネスプロセス A と B があり、A が B にメッセージを送信するとします。 新しいコミットにおいて、以下を同時に追加します。 - リクエストの新しいプロパティX を B に設定する新しいバージョンのプロセス A - 新しいプロパティ X を処理できる新しいバージョンのプロセス B このシナリオでは、プロセス B を先に更新してから A を更新する必要があります。 これは次のいずれかの方法で行えます。 - 更新の間、ビジネスホストを無効化する - 更新を 2 つに分ける: まずプロセス B のみを更新してから、その後の別の更新で、プロセス A から B にメッセージを送信し始める。 新しいバージョンのプロセス A と B に古いバージョンとの互換性がない場合のより困難な状況では、ビジネスホストの停止が必要となります。 ## キュー 更新後に、ビジネスホストが古いメッセージを処理できないことが分かっている場合、ビジネスホストキューが更新前に空になっていることを確認する必要があります。 これを行うには、ビジネスホストにメッセージを送信するすべてのビジネスホストを無効化し、そのキューが空になるのを待ちます。 ## BPL ビジネスプロセスにおける状態の変更 はじめに、BPL BP の仕組みから簡単に説明します。 BPL BP をコンパイルした後、2 つのクラスが完全な BPL クラス名と同じ名前でパッケージに作成されます。 - `Thread1` クラスはメソッド S1, S2, ... Sn を含み、BPL 内のアクティビティに対応します。 - `Context` クラスにはすべてのコンテキスト変数があり、BPL が実行する次の状態もあります（`S5`）・ また BPL クラスは永続であり、現在処理中のリクエストを格納します。 BPL は `Thread` クラスで `S` メソッドを実行し、それにおうじて BPL クラステーブル、`Context` テーブル、および `Thread1`テーブルを更新することによって機能します。ここで、「処理中」の 1 つのメッセージは BPL テーブル内の 1 行になります。 リクエストが処理されると、BPL は BPL、`Context`、および `Thread` エントリを削除します。 BPL BP は非同期であるため、1 つの BPL ジョブは `S` 呼び出しの間に情報を保存して異なるリクエストを切り替えることで、同時に多数のリクエストを処理できます。 たとえば、BPL は 1 つのリクエストが `sync` アクティビティに到達するまで処理し、BO からの応答を待ちます。 現在のコンテキストを `%NextState` プロパティ（`Thread1` クラス）をレスポンスアクティビティ `S` メソッドに設定してディスクに保存し、BO が応答するまで他のリクエストを処理します。 BO が応答したら、BPL はコンテキストをメモリに読み込んで、`%NextState` プロパティに保存された状態に対応するメソッドを実行します。 では、BPL を更新したらどうなるでしょうか？ まず、少なくとも以下の 2 つの条件の 1 つを満たしていることをチェックする必要があります。 - 更新中に、Context テーブルが空である。つまり、処理中のアクティブなメッセージがない。 - 新しい状態は古い状態と同じであるか、新しい状態は古い状態の後に追加されている。 少なくとも 1 つの条件を満たしている場合は、問題ありません。 更新後 BPL が処理する更新前リクエストが存在しないか、状態が最後に追加される、つまり古いリクエストもそこに含まれることが可能です（更新前リクエストが更新後 BPL アクティビティと処理に互換していることが前提です）。 ただし、処理中のアクティブなリクエストが存在し、BPL が状態の順序を変更した場合はどうでしょうか？ 理想的には、待機できるのであれば、BPL 呼び出し元を無効にしてキューが空になるまで待機します。 Context テーブルが空であることも確認します。 キューには未処理のリクエストのみが表示され、Context テーブルは処理中のリクエストを格納することを覚えておきましょう。つまり、非常にビジーな BPL のキューサイズが 0 となる場合があり、それは正常です。 その後、BPL を無効にし、更新を実行して、以前に無効にしたすべてのビジネスホストを有効にします。 それが可能でない場合は（通常、非常に時間のかかる BPL がある場合。リクエストの処理に約 1 週間かかった BPL の更新ケースや更新ウィンドウが短すぎたケースを覚えています）、[BPL バージョン管理](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=EBPLR_process)を使用します。 または、更新スクリプトを書くことができます。 この更新スクリプトでは、更新された BPL が古いリクエストを処理できるように、古い次の状態を新しい次の状態にマッピングして、`Thread1` テーブルで実行します。 もちろん更新期間中は BPL を無効にしておく必要があります。 とは言え、これは非常にまれな状況であり、通常は行う必要はありませんが、その必要性が生じた場合にはこれを使用することができます。 # まとめ 相互運用性は、根底にあるコードが変更した後でプロダクションを最新状態にするために必要となるアクションを最小限に抑えるために、洗練されたアルゴリズムを実装します。 SDS の更新ごとに安全なタイムアウトで UpdateProduction を呼び出せます。 それぞれのコードの更新については更新ストラテジーを決定する必要があります。 [git diffs](https://github.com/intersystems-ru/GitLab/blob/master/isc/git/Diff.cls) を使ってコンパイルされるコードの量を最小限に抑えると、コンパイル時間の軽減に役立ちますが、コードをそのコード自体で「更新」して再コンパイルするか、同じ値で設定を「更新」するとプロダクションの更新はトリガーされないか不要となります。 ビジネスルール、ルーティングルール、および DTL を更新してコンパイルすると、プロダクションを更新せずにすぐにアクセス可能になります。 最後に、プロダクションの更新は安全な操作であり、通常、停止は必要ありません。 # リンク - [Ens.Director](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Director) - [git diff のビルド](https://github.com/intersystems-ru/GitLab/blob/master/isc/git/Diff.cls) - [システムデフォルト設定](https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ECONFIG_other_default_settings) この記事の執筆において貴重な支援を提供してくださった @James.MacKeith、@Dmitry.Zasypkin、および @Regilo.Souza に感謝申し上げます。

[CI/CD シリーズ](https://jp.community.intersystems.com/node/476406)の新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。 今回も相互運用性について説明を続けますが、特に相互運用性デプロイの監視に焦点を当てます。 まだ[アラート]( https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=ECONFIG_alerts)をすべての相互運用性プロダクションにセットアップしていない場合は、それをセットアップしてエラーとプロダクションの状態についての一般的なアラートを取得できるようにしてください。 [非活動タイムアウト](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=ECONFIG_settings_busserv#ECONFIG_InactivityTimeout)は、すべての相互運用性ビジネスホストに共通する設定です。 ビジネスホストは、「Inactivity Timeout（非活動タイムアウト）」フィールドに指定された秒数以内にメッセージを受信しない場合に非アクティブステータスになります。 プロダクションの監視サービスはプロダクション内のビジネスサービスとビジネスオペレーションのステータスを定期的に確認し、非活動タイムアウト期間内にアクティビティがない場合にその項目を「非アクティブ」にマークします。 デフォルト値は 0（ゼロ）です。 この設定が `0` である場合、ビジネスホストはアイドル状態がどれほど続いても `Inactive` にマークされることはありません。 これはアラートを生成し、構成されたアラートと合わせてプロダクションの問題に関するリアルタイム通知を可能にするため、非常に便利な設定です。 ビジネスホストがアイドル状態である場合、プロダクション、統合、またはネットワーク接続に調べる価値のある問題がある可能性があります。 ただし、ビジネスホストには一定時間の非活動タイムアウトを 1 つしか設定できないため、夜間、週末、休日などのトラフィックの少ない既知の期間中に不要なアラートを生成する可能性があります。 この記事では、動的な非活動タイムアウトを実装するためのいくつかのアプローチを説明します。 機能する例（現在ある顧客サイトの本番環境で実行しているもの）を紹介していはいますが、この記事は独自の動的な非活動タイムアウトの実装を構築するためのガイドラインを紹介することを目的としているため、ここに提案するソリューションを唯一の代替手法と見なさないようにしてください。 # 構想 相互運用性エンジンは、各ビジネスホストをサブスクリプトとして、最新のアクティビティのタイムスタンプを値として含む特殊な HostMonitor グローバルを維持しています。 非活動タイムアウトを使用する代わりに、このグローバルを監視し、HostMonitor の状態に基づいてアラートを生成することにします。 HostMonitor は、非活動タイムアウト値が設定されているかに関係なく維持されます。常にオンの状態です。 # 実装 まず初めに、以下のようにして HostMonitor グローバルを反復処理します。 ``` Set tHost="" For { Set tHost=$$$OrderHostMonitor(tHost) Quit:""=tHost Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity) } ``` 監視サービスを作成するには、各ビジネスホストに対して以下のチェックを実行する必要があります。 1. ビジネスホストが完全に動的非活動タイムアウトのスコープで管理されるかを決定します（たとえば、トラフィックの多い hl7 インターフェースには通常の非活動タイムアウトを適用できます）。 2. ビジネスホストがスコープ内である場合、最後のアクティビティからの時間を計算する必要があります。 3. 次に、非活動時間といくつかの条件（日中/夜間、曜日）に基づいて、アラートを送信するかを決定する必要があります。 4. アラートレコードを送信する場合は、アラートを 2 回送信しないように、最後のアクティビティの時間を記録する必要があります。 すると、コードは以下のようになります。 ``` Set tHost="" For { Set tHost=$$$OrderHostMonitor(tHost) Quit:""=tHost Continue:'..InScope(tHost) Set lastActivity = $$$GetHostMonitor(tHost,$$$eMonitorLastActivity) Set tDiff = $$$timeDiff($$$timeUTC, lastActivity) Set tTimeout = ..GetTimeout(tDayTimeout) If (tDiff > tTimeout) && ((lastActivityReported="") || ($system.SQL.DATEDIFF("s",lastActivityReported,lastActivity)>0)) { Set tText = $$$FormatText("InactivityTimeoutAlert: Inactivity timeout of '%1' seconds exceeded for host '%2'", +$fn(tDiff,,0), tHost) Do ..SendAlert(##class(Ens.AlertRequest).%New($LB(tHost, tText))) Set $$$EnsJobLocal("LastActivity", tHost) = lastActivity } } ``` カスタムロジックを実際に格納している `InScope` と `GetTimeout` メソッドを実装したら、完了です。 この例では、日中のタイムアウト（Day Timeout、これはビジネスホストごとに異なる可能性がありますが、デフォルト値があります）と夜間のタイムアウト（Night Timeout、追跡されているすべてのビジネスホストに共通）があるため、ユーザーは以下の設定を指定する必要があります。 - スコープ: ビジネスホスト名（または名前の一部）とそれぞれのカスタムの DayTimeout 値を組み合わせた、行あたり 1 つのリスト。 スコープ内のビジネスホストのみが追跡されます（少なくとも 1 つのスコープに対して $find(host, scope) 条件を満たす必要があります）。 すべてのビジネスホストを監視する場合は空白のままにします。 例: `OperationA=120` - DayStart: 00:00:00 からの秒。日中はこの後に開始します。 DayEnd より少ない数値である必要があります。 すなわち、 06:00:00 AM は 6*3600 = 21600 となります。 - DayEnd: 00:00:00 からの秒。日中はこの後に終了します。 DayStart より大きな数値である必要があります。 すなわち、 08:00:00 PM は (12+8)*3600 = 72000 となります。 - DayTimeout: 日中にアラートを発生させるための秒単位のデフォルトのタイムアウト値。 - NightTimeout: 夜間にアラートを発生させるための秒単位のタイムアウト値。 - WeekendDays: 週末と見なされる曜日。 カンマ区切りです。 週末の場合、NightTimeout が 1 日 24 時間適用されます。 例: 1,7。日付の DayOfWeek 値は、`$SYSTEM.SQL.Functions.DAYOFWEEK(date-expression)` を実行してチェックします。 デフォルトでは、返される値は以下の曜日を表します: 1 — 日曜日、2 — 月曜日、3 — 火曜日、4 — 水曜日、5 — 木曜日、6 — 金曜日、7 — 土曜日。 [完全なコード](https://github.com/eduard93/Utils/blob/master/src/cls/Utils/InactivityWatchDogService.cls)を確認できますか、特に興味深い点はないと思います。 単に InScope と GetTimeout メソッドを実装しているだけです。 他の基準を使用して、InScope と GetTimeout メソッドを必要に応じて調整できます。 # 問題 言及する問題は 2 つあります。 - 非アクティブビジネスホストには黄色いアイコンがない（ホストの非活動タイムアウト設定値がゼロであるため）。 - Out-of-host 設定 - 開発者は新しいビジネスホストを追加するたびにこのカスタム監視サービスを更新して、動的な非活動タイムアウトを使用することを覚えておく必要があります。 # 代替手法 上記のソリューションを実装する前に、以下のアプローチを探りました。 1. 日中/夜間が開始するときに `InactivityTimeout` 設定を変更するビジネスサービスを作成する。 当初、この方法で進もうと考えましたが、主に、`InactivityTimeout` 設定を変更するたびに影響のあるすべてのビジネスホストを再起動しなければならないなど、多数の問題に遭遇しました。 2. カスタムアラートプロセッサーに、夜間の `InactivityTimeout` である場合にアラートを送信する代わりにアラートを抑止するというツールを追加する。 `Ens.MonitorServoce` からの非活動アラートが LastActivity を更新するため、カスタムアラートプロセッサーからは「実際の」最終アクティビティタイムスタンプを取得する方法がわかりません（`Ens.MessageHeader` をクエリする以外で）。 また「夜間」である場合、ホストの状態を OK に戻し、まだ夜間の `InactivityTimeout` でなければアラートを抑止します。 3. `Ens.MonitorService` を拡張する。これは、OnMonitor コールバック以外は可能に思えませんでしたが、他の目的には役立ちます。 # まとめ 必ず[アラート](https://docs.intersystems.com/iris20233/csp/docbook/Doc.View.cls?KEY=ECONFIG_alerts)をすべての相互運用性プロダクションにセットアップして、エラーやプロダクションの状態についての一般的なアラートを取得します。 静的な非活動タイムアウトで十分でなければ、動的な実装を簡単に作成できます。 # リンク - [非活動タイムアウト](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=ECONFIG_settings_busserv#ECONFIG_InactivityTimeout) - [アラート](https://docs.intersystems.com/iris20241/csp/docbookj/Doc.View.cls?KEY=ECONFIG_alerts) - [サンプルコード](https://github.com/eduard93/Utils/blob/master/src/cls/Utils/InactivityWatchDogService.cls)

約 4 年のギャップを経て、[私の CI/CD シリーズ](https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-index)が帰ってきました！ 長年にわたり、InterSystems の数社のお客様と連携し、様々なユースケースに対応する CI/CD パイプラインを開発してきました。 この記事で紹介する情報が誰かのお役に立てられれば幸いです。 この[連載記事](https://community.intersystems.com/post/continuous-delivery-your-intersystems-solution-using-gitlab-index)では、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。 取り上げたいトピックは広範にありますが、今回は、コードを超えた内容についてお話ししましょう。構成とデータについてです。 # 問題 前回はコードの昇格について話しました。ある意味ステートレスで、常に、（おそらく）空のインスタンスから完全なコードベースへと進めます。 ただし、時にはデータまたは状態を提供することも必要です。 データには様々なタイプがあります。 - 構成: ユーザー、ウェブアプリ、LUT、カスタムスキーマ、タスク、ビジネスパートナーなど - 設定: 環境固有の key-value ペア - データ: 参照テーブルとアプリが機能するために提供しなければならない場合があるテーブル これらすべてのデータタイプについて、およびソース管理にコミットしてからデプロイする方法について説明します。 # 構成 システム構成は多数のクラスに広がっていますが、InterSystems IRIS はほとんどを XML にエクスポートできます。 まず最初に、これは以下についての情報を含む[Securityパッケージ](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&PACKAGE=Security)です。 - Web アプリケーション - DocDB - ドメイン - 監査イベント - KMIPServers - LDAP 構成 - リソース - ロール - SQL 特権 - SSL 構成 - サービス - ユーザー これらのすべてのクラスは Exists、Export、および Import メソッドを提供しているため、環境間で移動することが可能です。 いくつかの欠点: - ユーザーと SSL 構成にはパスワードなどの機密情報が含まれる場合があります。 セキュリティ上の理由により、通常はこれらをソース管理に保存することは推奨されません。 1 回限りの転送を行うには Export/Import メソッドを使用します。 - Export/Import メソッドはデフォルトですべてを 1 つのファイルに出力するため、ソース管理には不便である場合があります。 ルックアップテーブル、カスタムスキーマ、ビジネスパートナー、タスク、認証情報、および SSL 構成のエクスポートとインポートを行える[ユーティリティクラス](https://gist.github.com/eduard93/3a9abdb2eb150a456191bf387c1fc0c3)があります。 これはファイル当たり 1 つの項目をエクスポートするため、LUT を含むディレクトリ、カスタムスキーマのディレクトリ、などを得ることができます。 SSL 構成の場合は、証明書やキーといったファイルもエクスポートします。 また、Export/Import の代わりに [%Installer](https://jp.community.intersystems.com/node/478966) または [Merge CPF](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=ACMF) を使用してこれらのほとんどを作成できることも覚えておくとよいでしょう。 いずれのツールもネームスペースとデータベースの作成をサポートしています。 Merge CPF はグローバルバッファーサイズなどのシステム設定を調整できます。 ## タスク [%SYS.Task](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYS.Task) クラスはタスクを保管し `ExportTasks` および `ImportTasks` メソッドを提供します。 また、タスクを 1 つずつインポート/エクスポートするには、上記のユーティリティクラスも確認してください。 タスクをインポートする際に `StartDate` またはその他のスケジュール関連のプロパティが過去の日時である場合、インポートエラー（`ERROR #7432: Start Date and Time must be after the current date and time`）が発生する可能性があることに注意しましょう。 ソリューションとして、`LastSchedule` を `0` に設定すると、InterSystems IRIS は新たにインポートしたタスクを最も近い未来に実行するようにスケジュールを設定し直します。 ## 相互運用性 相互運用性本番には以下が含まれます。 - ビジネスパートナー - システムのデフォルト設定 - 認証情報 - ルックアップテーブル 最初の 2 つは [Ens.Config](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&PACKAGE=Ens.Config) パッケージにあり、`%Export` と `%Import` メソッドを使用できます。 認証情報とルックアップテーブルは上記の[ユーティリティクラス](https://gist.github.com/eduard93/3a9abdb2eb150a456191bf387c1fc0c3)を使ってエクスポートします。 最近のバージョンでは、ルックアップテーブルは [$system.OBJ](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.OBJ) クラスでエクスポート/インポートできます。 # 設定 [システムデフォルト設定](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=ECONFIG_other_default_settings#ECONFIG_other_default_settings_purpose) - 環境固有の設定のデフォルトの相互運用性メカニズムです。 > システムデフォルト設定の目的は、本番定義を環境間でコピーするプロセスを単純化することにあります。 いずれのプロダクションにおいても、いくつかの設定の値はプロダクションの設計の一部として決定されます。そのためこれらの設定は通常すべての環境で同一です。 一方でその他の設定は、環境に合わせて調整する必要があり、これらの設定にはファイルパス、ポート番号などが含まれます。 > > システムデフォルト設定は、InterSystems IRIS がインストールされている環境に固有の値のみを指定する必要があります。 それに反し、プロダクションの定義では、すべての環境で同一となる設定の値を指定する必要があります。 これらを本番環境で使用することを非常にお勧めします。 システムデフォルト設定を転送するには、[%Export](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Config.DefaultSettings#%25Export) と [%Import](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Config.DefaultSettings#%25Import) を使用してください。 ## アプリケーション設定 アプリケーションもおそらく設定を使用します。 その場合、システムデフォルト設定を使用することをお勧めします。 これは相互運用性メカニズムではありますが、設定は `%GetSetting(pProductionName, pItemName, pHostClassName, pTargetType, pSettingName, Output pValue)`（[ドキュメント](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Config.DefaultSettings#%25GetSetting)）からアクセスできます。 必要でないデフォルト設定を設定するラッパーを書くことができます。例: ```objectscript ClassMethod GetSetting(name, Output value) As %Boolean [Codemode=expression] { ##class(Ens.Config.DefaultSettings).%GetSetting("myAppName", "default", "default", , name, .value) } ``` ほかにもカテゴリが必要な場合は、`pItemName` や `pHostClassName` 引数を公開することもできます。 設定は主に、インポート、システム管理ポータルの使用、`Ens.Config.DefaultSettings` クラスのオブジェクトの作成、または `^Ens.Config.DefaultSettingsD` グローバルの設定によって設定できます。 ここでの主なアドバイスは、設定を 1 か所にまとめておき（システムデフォルト設定またはカスタムソリューションのどちらでもかまいません）、アプリケーションは指定された API のみを使用して設定を取得するようにすることです。 この場合、アプリケーション自体は環境について認識せず、残っているのは環境固有の値を含む集中設定ストレージを提供することだけです。 これを行うには、リポジトリに環境ブランチ名と同じファイル名で設定ファイルを含む設定フォルダを作成します。 次に、CI/CD フェーズにおいて、`$CI_COMMIT_BRANCH` [環境変数](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)を使って正しいファイルを読み込みます。 ``` DEV.xml TEST.xml PROD.xml ``` 環境ごとに複数のファイルがある場合は、環境ブランチに因んだフォルダ名を使用してください。 InterSystems IRIS 内部から環境変数値を取得するには、`$System.Util.GetEnviron("name")` を[使用します](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.Util#GetEnviron)。 # データ 一部のデータ（参照テーブル、カタログなど）を使用できるようにするには、いくつかの方法があります。 - グローバルエクスポート。 バイナリ [GOF export](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=GGBL_managing#GGBL_managing_export) または新しい XML エクスポートをのいずれかを使用します。 GOF エクスポートの場合は、ソースとターゲットシステムのロケールが一致する（または少なくともグローバルこれ―ションがターゲットシステムで使用できる）必要があることに注意しましょう。 [XML エクスポート](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.OBJ) にはさらに多くの空き容量が必要です。 グローバルを `xml.gz` ファイルにエクスポートし、`$system.OBJ` メソッドが必要に応じて `xml.gz` ファイルを自動的にアーカイブ（アーカイブ解除）するようにすることで改善できます。 このアプローチの主なデメリットは、XML であってもほとんどが base64 でエンコードされるため、データを人間が読み取れないことです。 - CSV。 [CSV をエクスポート](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SQL.StatementResult#%25DisplayFormatted)して、[LOAD DATA](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=RSQL_loaddata) でインポートします。 CSV は最もストレージ効率が高く人間が読み取れる形式であるため、私の一番の優先オプションです。何にでもインポートできます。 - JSON。 クラスを [JSON 対応](https://docs.intersystems.com/iris20221/csp/docbookj/DocBook.UI.Page.cls?KEY=GJSON_adaptor)にします。 - XML。 オブジェクトを XML に投影するためにクラスを [XML 対応](https://docs.intersystems.com/iris20221/csp/docbookj/DocBook.UI.Page.cls?KEY=GXMLPROJ_intro)にします。 データに複合構造が含まれる場合に使用します。 どの形式を使用するかは、ユースケースによって異なります。 ここでは、ストレージ効率の順に形式をリストしていますが、データ量があまり多くない場合には考慮する点ではありません。 # まとめ 状態は、CI/CD デプロイパイプラインをさらに複雑にしますが、InterSystems IRIS ではそれを管理するためのツールを豊富に提供しています。 # リンク - [ユーティリティクラス](https://gist.github.com/eduard93/3a9abdb2eb150a456191bf387c1fc0c3) - [%Installer](https://jp.community.intersystems.com/node/478966) - [Merge CPF](https://docs.intersystems.com/iris20241/csp/docbookj/DocBook.UI.Page.cls?KEY=ACMF) - [$System.OBJ](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.OBJ) - [システムデフォルト設定](https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=ENSLIB&CLASSNAME=Ens.Config.DefaultSettings#%25GetSetting)

開発者の皆さん、こんにちは。 InterSystems ベクトル検索、GenAI、 ML コンテスト（USコミュニティ）の投票が始まりました！今回は新メンバーからの6作品を含め、16のアプリケーションが投稿されました。 🔥 ベストアプリケーションはこれだ！ 🔥と思う作品にぜひ投票をお願いします！ 投票方法は以下の通りです。 Experts nomination: インターシステムズの経験豊富な審査員がベストアプリを選び、Expert Nominationで賞品をノミネートします。 ⭐️ @Alvin.Ryanputra, Systems Developer⭐️ @Guillaume.Rongier7183, Sales Engineer⭐️ @Sylvain.Guilbaud, Sales Engineer⭐️ @akoblov, Senior Support Specialist⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Steve.Pisani, Senior Solution Architect⭐️ @Andreas.Dieckow, Principal Product Manager⭐️ @Aya.Heshmat, Product Manager⭐️ @Benjamin.DeBoe, Product Manager⭐️ @Robert.Kuszewski, Product Manager⭐️ @Carmen.Logue, Product Manager⭐️ @Luca.Ravazzolo, Product Manager⭐️ @Raj.Singh5479, Product Manager⭐️ @Patrick.Jamieson3621, Product Manager⭐️ @Stefan.Wittmann, Product Manager⭐️ @tomd, Product Manager⭐️ @Daniel.Franco, Senior Manager - Interoperability Product Management⭐️ @Timothy.Leavitt, Development Manager⭐️ @Evgeny.Shvarov, Senior Manager of Developer and Startup Programs⭐️ @Dean.Andrews2971, Head of Developer Relations⭐️ @Jeffrey.Fried, Director of Product Management Community nomination: 開発者コミュニティのメンバーは、お好みのアプリケーションに対して1位～3位を指定しながら投票できます。 Conditions Place 1st 2nd 3rd 開発者コミュニティに記事を掲載したり、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 へのサインインします（開発者コミュニティのアカウントを使用してください）。 投票ボタンは、開発者コミュニティ内で、質問／回答／記事の掲載／投稿に対するコメント など 記載いただいた方に対して有効になります。 ボタンが押せない場合は、コミュニティへのコメントやオリジナルの記事など、書き込みお願いします！詳細は、こちらの記事をご参照ください。 気が変わった場合は？　－　選択をキャンセルして別のアプリケーションに投票できます。 ぜひ🔥これだ🔥と思う作品に投票お願いします！ メモ：コンテストへ応募された作品は、投票週間中にバグを修正したり、アプリケーションを改良したりすることができますので、アプリケーションのリリースを見逃さずに購読してください

### Raspberry を FHIRserver として実行する 一年ほど前、 Raspberry Pi での HAPI FHIRserver のインストールに関する記事を書きました。 当時、FHIR 標準の基本しか知らず、FHIR サーバーの背後にあるテクノロジーや Raspberry についてほとんど知りませんした。 試して、失敗して、諦めて、もう一度試すことで、たくさんのことを学びました。1 年以上が経ち、いまだに「忍耐力に長けるアマチュア」ではありますが、その間、FHIR のフル環境を Raspberry で構築し、HTML/JavaScript/jQuery/Bootstrap によるアプリケーションや PHP アプリケーションを多数作成してきました。 Raspberry の認証サーバーや承認サーバーについてもいくらか経験し、SMART on FHIRを使った実験も行いました。 最後の機能しなかったバージョンと、明らかに私が作成した成功バージョンの違いが判らないまま動作することもありましたが、作業や実験のほとんどは動作しました。 今でも驚いています。 振り返ると、システム開発について適切に学習しておくべきだったと思います（私は山林学専攻で卒業し、現在はその分野を中心にボランティア活動を行っています。 まぁ、本題からは外れてしまいますが）。 Raspberry Pi は実験には十分ですが、本稼働には適していないことに注意してください。 したがって、信頼性、継続性、セキュリティ、プライバシーといった要素が必要である、または期待されているヘルスケアなどの分野で、Raspberry を本稼働システムとして使用しないでください。 実験目的では完璧で安価なコンピュータであり、幾度も私の期待を超えていますが、「産業耐久性」に欠けています。 ### InterSystems FHIRserver 入手しやすさと、非常に早い段階で結果を得られたことを理由に、当時 HAPI FHIR を選択しました。 以前の同僚で、現在では InterSystems に勤めている人から、InterSystems の FHIRserver でも試用することをすでに提案されていました。 InterSystems については非常によく知っており（というより、「i.know」と言うべきでしょうか 😉）、面白そうに思えましたが、当時、一年以上前は、ARM プロセッサ向けに適したバージョンの Iris は存在していませんでした（Raspberry は ARM で動作します）。 それとは別に、Iris の Community バージョンは Docker コンテナとして配布されていましたが、私には Docker に関する知識がまったくありませんでした。 ### Raspbian から Ubuntu へ それから 1 年が過ぎました。 現在では、さらに強力になった新しい Raspberry Pi が登場しています（在庫のある限り…）。 新しい Raspberry 4 は、Raspberry 3 と同様に、64 ビット Unix をサポートしています。 IRIS Community バージョンは ARM にも対応しており、コンテナと Docker についてもいくらかさらに学習しました。 こういった改善すべてを基に、昨年の年末にオランダで施行されたわけのわからない「ロックダウン」が、IRIS Community バージョンを Raspberry Pi で実行させる新しい実験を開始するチャンスとなりました。 振り返ると、これは非常に簡単なことでした。 実際、注意すべき点は 3 つしかありません。 1. 64 ビットをサポートする Raspberry が必要です。 つまり、Raspberry 3 または 4 が必要となります。 2. （64 ビット）Raspbian ではうまくいきませんでした（ちなみに非常に新しいものです）。 しかし、64 ビット Ubuntu では成功しました。 3. InterSystems FHIRserver は、HAPI FHIRserver よりも FHIR 呼び出しに関して厳格さが増しているようです。 これについては別の機会に説明しますが、これを悪いことだとは思っていません。 （ヘルス）ケア環境における中央リポジトリであるため、標準について厳格である必要があるためです。そうでなければ、「ガベージイン・ガベージアウト」になってしまうでしょう。 それでも、HAPI FHIRserver でうまく実行していたアプリケーションが IRIS では失敗することを理解するのには、いくらか時間がかかりました。 ネタバレ注意: 問題は私のアプリケーションにありました。 それにしても、Raspberry Pi のような、100 ユーロもかからない小さなコンピュータで、InterSystems IRIS フルプラットフォームが実行し、管理ポータル、Ensemble、Caché、そして FHIRserver が備わっているのを目の当たりにするのは、楽しく本当に価値以上の価値があります。 以降では、そこに至るまでに私が行ったことを、順を追って説明します。 Ubuntu の歴史、Docker の背後の意ある哲学など、長々とした話にはなりません。 そちらの方に関心のある方は、インターネットをご覧ください。 ここでは「楽しく進められるフロー」に焦点を当て、どこで初めて間違ったのかについて言及する場合にのみ、注釈したいと思います。 ### InterSystems FHIRserver のインストール #### フェーズ 1: Ubuntu 64 ビット 1. _SD カードをフォーマット_し、そこに ARM プロセッサ用 64 ビット Ubuntu を配置します。 私の場合、圧縮バージョンの名前は「ubuntu-20.04.3-preinstalled-server-arm64+raspi.img.xz」でした。これは http://cdimage.ubuntu.com にあります。 （もちろん、SD カードに置く前に、.img ファイルを解凍する必要があります！） RaspberryPi-imager は、誤ったバージョンを提供するため、使用しないでください。 私は Win32DiskImager を使用しました。 2. _新しいイメージで Raspberry を開始_します。 ubuntu-account のパスワードを変更します（そして記憶しましょう！）。 あくまでも ubuntu-account のパスワードです。 3. _この時点で Raspberry は Ubuntu で実行していますが、まだ準備はできていません_。 以下を見てください。  この Ubuntu-version はまだ 32 ビットになっています！ 今すぐこれを直しましょう。 1. Pi にログインします。 2. **sudo rpi-update** 3. **sudo reboot now** 5. **sudo copy /boot/config.txt /boot/config-ok.txt**（検出したエラーを逃してしまった場合に備えます） 6. **sudo nano /boot/config.txt**   [pi4] の下に次のテキストを追加します: arm_64bit=1 8. boot/config.txt を保存します。（nano で: <ctrl>O ） 9. nano を終了します。（<ctrl>X） 10. **sudo reboot now** これで、64 ビットで実行するようになりました。 自分で確認してみましょう:  Pi のIP アドレスをメモし（**sudo hostname -I**。I は大文字のアイです）、Ubuntu では SSH はデフォルトで有効になっているため、別の場所に保管しておきます。 #### フェーズ 2: Docker 1. **sudo curl -fsSL https://get.docker.com -o get-docker.sh** 2. **sudo sh get-docker.sh**  しばらくすると、これは、「non-priviledged user」として使用することに関する Docker の詳細な通知が得られます。 3. **sudo usermod -aG docker $USER** 4. ログオフしてから、もう一度ログインします。 5. **docker container run hello-world** Docker はシステム上の「hello-world」イメージを探すようになりました。 見つからない場合は、Docker リポジトリからダウンロードします。 その後、Docker はイメージを Pi 上のコンテナに配置し、「hello-world」イメージを開始します。 Docker の別のテキストブロックで、「Hello from Docker」のウェルカムメッセージと共に確認できます。 #### フェーズ 3: InterSystems の IRIS FHIRserver の Docker イメージ 1.  以下のコマンドを一度に発行します。 **sudo docker run --name my-iris -d --publish 9091:1972 --publish 9092:52773 containers.intersystems.com/intersystems/irishealth-community-arm64** 多数のイベントが順に発生します。 * Docker は Irishealthから「community edition」を取得し、それをローカルの Docker リポジトリに配置します。 * Docker は「my-iris」という Docker コンテナで Community エディションを起動します。 * Docker はコンテナで実行している IRIS のポート 1972 を Raspberry のポート 9091 にマッピングします。 * 同じパターンに従って、IRIS のポート 52773（コンテナ内）は Raspberry のポート 9092 になります。 以下のようにすると、何が起きたのかを確認できます。 2. **sudo docker container ls**  ただし、これを確認するには別のはるかに印象的な方法があります。 #### フェーズ 4: InterSystems IRIS for Health Fhirserver の起動 ネットワークで Web ブラウザを起動します。英語版 PC の場合は次の場所に移動してください。     _ <Raspberry の IP アドレス>_:9092/csp/sys/UtilHome.csp_ . IRIShealth の管理ポータルが表示されます。 このポータルは、自動的にPC の言語設定に調整されます。 標準アカウントは _SYSTEM（先頭のアンダースコアを含む）で、初回パスワードは SYS（アンダースコアはありません）です。 IRIS からすぐにパスワードを変更するように求められます。 これで、次に記載されている指示に従って IRIS for Health FHIRserver を構成し、起動できるようになりました。https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI.Page.cls?KEY=HXFHIR_server_install 「Foundation」を構成して「Endpoint」（FHIR 3 または 4）を定義する必要があります。 「Endpoint」は、FHIRserver にアクセスできる URI となります。 私の場合は、_http://192.168.1.29:9092/csp/healthshare/fhironpi/fhir/r4/Patient_ にある「Patient」リソースです（外部からはアクセスできません！）。 ### まとめ 手間を取る価値があったでしょうか？ そのとおり！それ以上の価値があります。 まず、それほどの手間はありませんでした。 Raspbian ではうまくいきませんでしたが、それは簡単に解決しました。 そして、IRIS-for-health プラットフォームを Raspberry Pi のようなデバイスで実行できるのは素晴らしいことです。 ダッシュボード（DeepSee）、データ変換ツール、Ensemble（Enterprise Service Bus とその他多数のツール）、CSP ページ、および Caché（多次元データベース）すべてを実験できるようですし、自然言語処理の I.know も管理ポータルに表示されています。 IRIS-for-health プラットフォームには、FHIRserver 単体よりもはるかに多くの機能が備わっており、1 つの記事ではとても説明しきれません。 私個人としては、ほぼリリース直後から Ensemble を使用してきましたし（アーキテクトとして）、それとは別に、IRIS-for-health の起源は 20 世紀後半だったため、思い入れがあります。 ヘルスケアアプリケーション向け MUMPS 開発環境（MUMPS/マンプス: マサチューセッツ総合病院ユーティリティマルチプログラミングシステム）は、ほとんどが Digital Corp の Vax コンピュータシステムで実行されていたのですが、私の IT キャリアが始まったのも同時期なのです。 MUMPS、Caché、Ensemble、そして今日には IRIS-for-Health プラットフォームの安定性は非常に高く、必要なサポートとメンテナンスは比較的控え目です。 InterSystems 製品のドキュメントは広範に用意されており、簡単に見つけることができます。 IRIS と FHIRserver での実験をさらに続ていく予定です。最低でも後 1 つ、FHIR 標準への厳格な準拠に対する私の「奮闘」に関する記事を絶対に公開いたします！ 健康を大切に、思考を繰り返して、実験し続けましょう！ Bob