#InterSystems IRIS for Health

はじめに

システム開発では、集計作業や他システムとの連携など、数十秒ごとにバックグラウンドで処理を実行する、常駐プロセスが必要になるケースが多々あるかと思います。

Cachéでは、Jobコマンドを使って常駐プロセスを作成しますが、実際にシステムを安定稼働させるには、以下の監視の仕組みが必要でした。

• 常駐プロセスの監視 常駐プロセス起動時にロックをかけ、二重起動を防止したり、プロセスが起動しているかどうかを監視する
• ログ 常駐プロセスの処理状況や発生したエラーを記録し、処理が行われているどうかを監視する

IRISの場合、Interoperabilityにはこれらの機能が装備されています。したがって、Interoperabilityの機能を使えば、簡単に常駐プロセスを起動、監視することができます。

常駐プロセスの作り方

常駐プロセスの作成には以下の作業を行います。

1. ビジネスサービスの作成 定期的に処理を行うビジネスサービスと呼ばれるクラスの作成
2. 常駐プロセスの処理の記述 作成したビジネスサービスに、実施したい処理を記述
3. プロダクションの作成 起動したい常駐プロセスを設定、監視するプロダクションの作成

１．ビジネスサービスの作成

スタジオを起動、常駐プロセスを実行するネームスペースに接続し、「ファイル」メニューの「新規作成.

皆さんこんにちは。

第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に基づいて作成したアプリケーション定義を使用してディスパッチクラスを作成する手順を解説します）

このビデオには、以下の関連ビデオがあります。

• IRISの基本操作についてのビデオ（索引ページ）
• InterSystems開発者コミュニティ biginnerタグ一覧

もくじ

最初～　復習ビデオ／関連ビデオについて など

• IRIS で 作成する REST サーバの仕組み
• IRISでのJSON操作について
• 手動によるRESTディスパッチクラスの作成

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の設定（管理ポータルでの設定）＋　実演

13:23～  curd2.

IRIS で作成する REST サーバの仕組みを解説します。

このビデオには、以下の関連ビデオがあります。

• IRISの基本操作についてのビデオ（索引ページ）
• InterSystems開発者コミュニティ biginnerタグ一覧

もくじ

0:55～　今回の説明内容解説と関連ビデオについて

• IRISでのJSON操作について
• 手動によるRESTディスパッチクラスの作成
• APIファーストによるRESTディスパッチクラスの作成

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 IRIS データ・プラットフォーム
https://docs.intersystems.com/iris20202/csp/docbook/DocBook.UI.Page.

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）を使ってそのプロセスを簡素化する方法を説明します。

セットアップ

まず、IRISをベースにしたシンプルなREST APIアプリケーションから紹介します。

この記事では、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é サーバ用に生成されます。

マニフェストを定義するには、ターゲット構成の詳細な説明を含む新しいXDataブロックを作成してから、このXDataブロックのCaché ObjectScriptコードを生成するメソッドを実装します（このコードは常に同じです）。

前回はシンプルな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 

一般的なAWSリソースと同様に、EKSは無料ではありません 。 ただし、無料利用枠のアカウントを作成して、AWSの機能を試すことができます。 ただし、試してみたい機能のすべてが無料枠に含まれているわけではないことに注意してください。

​​​​​​この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチを紹介し、説明したいと思います。以下のようなトピックについて取り上げます。

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 
• ICMを使用したCD 
• コンテナアーキテクチャ 

この記事では、独自のコンテナを構築してデプロイ展開する方法について説明します。 

Durable %SYS 

コンテナは一時的なものなので、アプリケーションデータを保存するべきではありません。Durable %SYS の機能により設定、構成、 %SYSデータなどをホストボリュームに保存することができます。

• iris.cpfファイル 
• /cspディレクトリ：Webゲートウェイの構成とログファイルが含まれています。 
• /httpd/httpd.confファイル：インスタンスのプライベートWebサーバーの構成ファイル。 
• /mgrディレクトリ： 
  • IRIS.DATおよびiris.

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けていくつかの可能性のあるアプローチをを紹介し、議論したいと思います。 今回は以下のようなトピックを取り上げます。 

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 
• ICMを使用したCD 

この記事では、InterSystems Cloud Managerを使用して継続的デリバリーを構築ドします。 ICMは、InterSystems IRISをベースとしたアプリケーション用のクラウドプロビジョニングおよびデプロイメントソリューションです。これにより、 必要なデプロイ構成を定義することができ、ICMが自動的にプロビジョニングします。 詳細については、First Look: ICM をご覧ください。

 ワークフロー

継続的デリバリーの構成では、次のようになります。

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。

• Git 101 
• Gitフロー（開発プロセス） 
• GitLabのインストール 
• GitLabワークフロー 
• 継続的デリバリー 
• GitLabのインストールと構成 
• GitLab CI/CD 
• コンテナを使用する理由 
• コンテナインフラストラクチャ 
• コンテナを使用したCD 

第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。

第2回の記事では、ソフトウェアのライフサイクルの完全なプロセスであるGitLabワークフローについて説明しています。

第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。

第4回の記事では、CDの構成を説明しています。

第5回の記事では、コンテナとその使用方法（および使用する理由）について説明しています。

第6回の記事では、コンテナを使用して継続的デリバリーのパイプラインを実行する必要がある主なコンポーネントと、それらすべての連携の仕組みについて説明しています。

IRIS 2019.4以降の製品には、Prometheus形式でIRISのメトリックを公開する/api/monitorサービス機能が実装されています。 IRISのメトリックを監視・警告ソリューションの一部として使用したい人にとっては大きなニュースです。 このAPIは、IRISの次期バージョンでリリースされる予定の新しいIRIS System Alerting and Monitoring (SAM) ソリューションのコンポーネントです。 

ただし、IRISインスタンスを監視するためにSAMがこのAPIの計画と実証実験を開始するのを待つ必要はありません。 今後の投稿では利用可能なメトリックとその意味についてさらに掘り下げ、対話型ダッシュボードの例を示します。 しかし、まずは背景の説明といくつかの質問と回答から始めましょう。 

IRIS（およびCaché）は常に自分自身とその実行プラットフォームに関する数十のメトリックを収集しています。 これらのメトリックを収集し、CachéとIRISを監視する方法は常に複数存在します 。 また、IRISとCachéの組み込みソリューションを使用しているインストール環境はほとんどないことが分かっています。 例えば、History Monitorはパフォーマンスとシステムの使用状況に関するメトリックの履歴データベースとして長い間利用されてきました。

基本操作編ビデオシリーズ：その2

IRIS で開発を始めるために必要な準備について以下の内容をご説明します。

• 管理ポータルの起動方法
• ネームスペースの作成方法
• IDEからIRISへ接続する方法

もくじ

最初から　～　6:50　管理ポータルの開き方とメニューについて

7:03　～　12:50　ネームスペースとデータベースについて

12:50　～ 17:10　ネームスペース、データベースの作成実演

17:10　～　20:50　スタジオを使用する場合の設定内容

20:50　～　22:35　スタジオ：IRISへの接続実演

22:35　～　26:50　VS Codeを使用する場合の設定内容

26:52　～　VS Code：IRISへの接続実演

※YouTubeでご覧いただくと「もくじ」に記載の秒数クリックでビデオをジャンプできます。

その他ビデオ一覧は索引ページをご参照ください。

《2021/7/21 ビデオを更新しました》

VSCode の ObjectScript エクステンションを利用して IRIS に接続する説明を更新しました（settings.json に接続情報を設定する方法の解説に変更しました）。

IRIS でのクラス定義の作成、ObjectScript でインスタンスの生成と永続化（保存）の方法について解説します。

もくじ

最初～1:55　前回のビデオの学習

1:55～2:45　今回の説明内容解説

2:45～5:15　クラスの種類について

5:15～13:20　作成するクラスの説明、定義説明

13:20～18:44　スタジオでの作成実演

18:44～22:35　VS Codeでの作成実演

22:35～27:40　ObjectScriptでインスタンス生成

27:40～29:38　インスタンス生成～永続化の実演

29:38～34:54　データの確認

34:54～40:13　マルチモデル（永続クラス＝テーブル）の確認

40:13～51:25　JSONとXMLアダプタの操作実演

51:25～57:36　クラスメソッドの定義と実行

57:36～最後まで　まとめ

※　YouTubeでご覧いただくと「もくじ」の秒数クリックでビデオをジャンプできます。

その他ビデオ一覧は索引ページをご参照ください。

クラス定義例

Python から InterSystems IRIS へ接続する方法の1つである「Native API」(※)の使用方法ご説明します。

※ Python からのアクセスは、Native API の他に、PyODBC を利用した接続方法もあります。PyODBC の利用については別の記事でご説明します。

応募期間は 2020年6月29日～7月12日 です！

優勝特典

１、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。

🥇 1位 - $2,000 

🥈 2位 - $1,000 

🥉 3位 - $500

2、Developer Community で多く票を集めたソリューションには、以下の賞金が贈られます。

🥇 1位 - $1,000 

🥈 2位 - $500 

複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。

参加資格

どなたでもご参加いただけます。

コンテストのスケジュール

6月29日～7月12日 応募期間
7月13日～7月19日 投票
7月20日 優秀者発表

コンテストの課題

AI / ML
InterSystems IRIS を使った AI/ML ソリューションの開発。

InterSystems IRIS を使用して開発された AI/ML ソリューションの中から、優秀アプリケーションに賞が贈られます。
アプリケーションは、ライブラリ、パッケージ、ツール、または InterSystems IRIS を使用した AI/ML ソリューション等です。

VMware vSphereで実行する大規模な本番データベースのCPUキャパシティプランニングについて、お客様やベンダー、または社内のチームから説明するように頼まれることが良くあります。 

要約すると、大規模な本番データベースのCPUのサイジングには、いくつかの単純なベストプラクティスがあります。 

• 物理CPUコア当たり1つのvCPUを計画する。 
• NUMAを考慮し、CPUとメモリをNUMAノードに対してローカルに維持できるようVMの理想的なサイズを決定する。 
• 仮想マシンを適正化する。 vCPUは必要な場合にのみ追加する。 

このことから、通常いくつかの一般的な疑問が生まれます。 

• ハイパースレッディングにより、VMwareでは物理CPUの2倍の数でVMを作成できます。 これはキャパシティが2倍になるということか？ できるだけ多くのCPUを使ってVMを作成すべきではないのか？ 
• NUMAノードとは？ NUMAに配慮する必要があるのか？ 
• VMを適正化する必要があるが、どうすれば適正化されたことがわかるのか？ 

こういった疑問につては、下の例を使って答えることにします。 ただし、ベストプラクティスは決定事項ではありません。 ときには妥協することも必要です。 たとえば、大規模なデータベースVMはNUMAノードに収まらない可能性が高く、それはそれでも良いのです。

前回の記事では、pButtonsを使って履歴パフォーマンスメトリックを収集する方法を説明しました。 すべてのデータプラットフォームインスタンス（Ensemble、Cachéなど）にはpButtonsがインストールされていることがわかっているため、私はpButtonsを使用する傾向にありますが、 Cachéパフォーマンスメトリックをリアルタイムで収集、処理、表示する方法はほかにもあり、単純な監視や、それよりもさらに重要な、より高度な運用分析とキャパシティプランニングに使用することができます。 データ収集の最も一般的な方法の1つは、SNMP（簡易ネットワーク管理プロトコル）を使用することです。 

SNMPは、Cachéが管理・監視情報をさまざまな管理ツールに提供するための標準的な方法です。 Cachéのオンラインドキュメンテーションには、CachéとSNMP間のインターフェースに関する詳細が説明されています。 SNMPはCachéと「単純に連携」するはずですが、構成にはいくつかの技と罠があります。 私自身、はじめに何度も過ちを繰り返し、InterSystemsの同僚から助けを得ながらCachéをオペレーティングシステムのSNMPマスターエージェントにやっと接続できた経験から、皆さんが同じような困難を避けられるようにこの記事を書くことにしました。

この記事では、InterSystemsデータプラットフォームで実行するデータベースアプリケーションにおけるグローバルバッファ、ルーチンバッファ、gmheap、locksizeなどの共有メモリ要件のサイジングアプローチを説明し、サーバー構成時およびCachéアプリケーションの仮想化時に検討すべきパフォーマンスのヒントをいくつか紹介します。 これまでと同じように、Cachéについて話すときは、すべてのデータプラットフォーム（Ensemble、HealthShare、iKnow、Caché）を指しています。 

このシリーズの他の記事のリストはこちら 

最初にCachéを使い始めたころ、ほとんどの顧客オペレーティングシステムは32ビットで、Cachéアプリケーションのメモリは少なく、高価なものでした。 一般的に展開されていたIntelサーバーにはコアが数個しかなく、スケールアップするには、大型のサーバーを使用するか、ECPを使って水平方向にスケールアウトするしかありませんでした。 今では、基本製品グレードのサーバーでさえも、マルチプロセッサ、数10個のコア、TBにまで増設できる可能性も備わった128GBまたは256GBの最低メモリが搭載されています。

今週は、ハードウェアの主な”食品群” (^_^)  の1つであるCPUに注目します。お客様から、次のようなシナリオについてのアドバイスを求められました。お客様の本番サーバーはサポート終了に近づいており、ハードウェアを交換する時期が来ています。 また、仮想化によってサーバーを一元的に管理できるようにし、ベアメタルか仮想化によりキャパシティを適正化したいとも考えています。 今日はCPUに焦点を当てますが、後日の記事では、メモリやIOといったほかの主要食品群を適正化するアプローチについて説明したいと思います。 

では、質問を整理しましょう。 

• 5年前のプロセッサをもとに作られたアプリケーション要件を今日のプロセッサに変換するには？ 
• 現在ではどのプロセッサが適しているのか？ 
• 仮想化はCPUキャパシティプランニングにどのような影響を及ぼすのか？ 

2017年6月追記: 
VMware CPUに関する考慮事項と計画の詳細、および一般的な質問と問題の詳細については、「大規模データベースの仮想化 - VMware CPUのキャパシティ計画」の記事も参照してください。 

このシリーズの他の記事のリストはこちら 

spec.

前回の投稿では、pButtonsを使用してパフォーマンスメトリックを24時間収集する処理をスケジュールしました。 この投稿では、収集対象の主なメトリックのいくつかと、それらの土台となるシステムハードウェアがどのように関連しているかを見ていきます。 また、Caché（または任意のInterSystemsデータプラットフォーム）メトリックとシステムメトリックの関係についても調べます。 さらに、これらのメトリックを使用してシステムの毎日の健全性を把握し、パフォーマンスの問題を診断する方法もご紹介します。 

このシリーズの他の記事のリストはこちら 

2016年10月に編集... 

pButtonsデータを .csv ファイルに抽出するスクリプトの例はこちらで確認できます。 

2018年3月に編集... 

画像が消えていましたが、元に戻しました。 

ハードウェア食品グループ 

この連載を読み進めていくと、パフォーマンスに影響を与えるサーバーコンポーネントを次のように分類できることが分かってきます。 

- CPU 

- メモリ 

- ストレージIO 

- ネットワークIO 

これらのコンポーネントのいずれかに負荷がかかっている場合、システムのパフォーマンスとユーザーエクスペリエンスが低下する可能性があ

アプリケーションがデプロイされ、すべてが問題なく動作しています。 素晴らしいですね！ しかし、その後突然電話が鳴り止まなくなりました。アプリケーションが時々「遅くなる」というユーザーからの苦情の電話です。 これは一体どういうことなのでしょうか？ なぜ時々遅くなるのでしょうか？ このような速度低下を検出し、解決するにはどのようなツールと統計情報に注目すべきなのでしょうか？ お使いのシステムのインフラはユーザーの負荷に対応できていますか？ 本番環境を調べる前に、どのようなインフラ設計上の問題を問うべきなのでしょうか？ 新しいハードウェアのキャパシティプランニングを、必要以上の設備投資を行うことなく自信を持って行うにはどうすればよいのでしょうか？ どうすれば電話がかかってこなくなるのでしょうか？ そもそも電話がかかってこないようにするには、どうすればよかったのでしょうか？ 

このシリーズの他の記事のリストはこちら 

長い道のりの始まり 

これは、システムパフォーマンスの監視、確認、トラブルシューティングに使用できるツールとメトリック、およびパフォーマンスに影響を与えるシステムとアーキテクチャの設計上の考慮事項について説明する連載の最初の投稿です。

「データプラットフォームのキャパシティプランニングとパフォーマンス」シリーズの全記事をリストしました。 その下には私の一般的なその他の記事も記載しています。 このシリーズに新しい記事が追加されるたびに、このリストを更新する予定です。 

「キャパシティプランニングとパフォーマンス」シリーズ 

通常、各記事はその前の記事の続きとして書かれていますが、ほかの記事を飛び越して気になるものを読むこともできます。 

• パート1 - はじめの一歩、メトリックの収集 
• パート2 - 収集したメトリックの確認 
• パート3 - CPUに注目 
• パート4 - メモリの確認 
• パート5 - SNMPによる監視 
• パート6 - CachéストレージIOプロファイル 
• パート7 - パフォーマンス、スケーラビリティ、可用性のためのECP 
• パート8 - ハイパーコンバージドインフラストラクチャのキャパシティとパフォーマンス計画 
• パート9 - Caché VMwareのベストプラクティスガイド 
• パート10 - VMバックアップとCachéのFreeze/Thawスクリプト 
• パート11 - 大規模データベースの仮想化 - VMWareのCPUキャパシティプランニング 

その他の記事 

コミュニティに掲載中のアーキテクチャ全般の記事を集めたリストです。

次の手順で、/api/monitor サービスから利用可能なメトリックのサンプル一覧を表示することができます。 

前回の投稿では、IRISのメトリックをPrometheus形式で公開するサービスの概要を説明しました。 この投稿では、コンテナにIRISプレビューリリース2019.4 をセットアップして実行し、メトリックを一覧表示する方法をお伝えします。 

この投稿は、Dockerがインストールされた環境があることを前提としています。 そうでない場合は、今すぐお使いのプラットフォームにインストールしてください :) 

ステップ 1. dockerでIRISプレビューをダウンロードして実行する 

「プレビューの配布」のダウンロード手順に従い、プレビューライセンスキーとIRISのDockerイメージをダウンロードします。 この例では、InterSystems IRIS for Health 2019.4を選択しています。 

「機能紹介：Dockerコンテナ内のInterSystems製品について」の指示に従ってください。 すでにコンテナに精通している場合は、「InterSystems IRISのDockerイメージをダウンロードする」というタイトルのセクションに進んでください。 

次のターミナル出力は、私がDockerイメージの読み込みに使用している手順を示しています。

Cachéの優れた可用性とスケーリング機能の1つは、エンタープライズキャッシュプロトコル（ECP）です。 アプリケーション開発中に考慮することにより、ECPを使用した分散処理は、Cachéアプリケーションのスケールアウトアーキテクチャを可能にします。 アプリケーション処理は、アプリケーションを変更することなく、単一のアプリケーションサーバーから最大255台といった非常に高いレートにまで、アプリケーションサーバー処理能力を拡張できます。 

ECPは、私が関与していたTrakCareのデプロイメントで長年広く使用されていました。 10年前は、主要ベンダーの1つが提供する「大きな」x86サーバーは、合計で8つのコアしか備えていなかったかもしれません。 大規模なデプロイメントの場合、ECPは、高価な大型コンピュータを使う単一のエンタープライズサーバーではなく、コモディティサーバーでの処理をスケールアウトする方法でした。 コア数の多いエンタープライズサーバーでさえ制限があったため、ECPはそれらのサーバーへのデプロイメントのスケーリングにも使用されました。 

現在、ほとんどの新しいTrakCareのデプロイメントや主流ハードウェアへのアップグレードは、ECPでのスケーリングを必要としません。 現行の2ソケットx86プロダクションサーバーは、数十のコアと巨大なメモリを持つことができます。

私や他のテクノロジアーキテクトは、Caché IOの要件と、Cachéアプリケーションがストレージシステムを使用する方法を顧客とベンダーに説明しなければならないことがよくあります。以下の表は、一般的なCaché IOプロファイルと、トランザクションデータベースアプリケーションの要件を顧客やベンダーに説明するときに役立ちます。 オリジナルの表は、マーク・ボリンスキーが作成しました。 

今後の投稿ではストレージIOについて詳しく説明する予定なので、今後の記事の参考資料として、今回これらの表も公開します。 

このシリーズの他の記事のリストはこちら 

予測可能なディスクIOパフォーマンスを提供し、高可用性機能をサポートし、アプリケーションにストレージの冗長性、スケーラビリティ、および信頼性を提供するには、ストレージアレイなど、ストレージを適切に設定することが不可欠です。 

CachéストレージIOプロファイル 

選択したストレージアレイテクノロジーによっては、物理層のディスクストレージがプールまたはディスクグループに分離される場合があります。 可能であれば、可用性とパフォーマンスのために、予想されるIOプロファイルに基づいてストレージをパーティション化する必要があります。 たとえば、データとジャーナル（トランザクションログ）は別々の物理ディスクグループに存在する必要があります。