検索

クリアフィルター
記事
Mihoko Iijima · 2020年7月7日

InterSystems IRISソリューションを CircleCI を使用して GCP Kubernetes Cluster GKE へデプロイする

私たちのほとんどは、多かれ少なかれDockerに慣れ親しんでいます。 Dockerを使用している人たちは、ほとんどのアプリケーションを簡単にデプロイし遊んで、何かを壊してしまってもDockerコンテナを再起動するだけでアプリケーションを復元できる点を気に入っています。 InterSystems も Docker を気に入っています。 InterSystems OpenExchange プロジェクトには、InterSystems IRISのイメージを簡単にダウンロードして実行できるDockerコンテナで実行するサンプルが多数掲載されています。また、Visual Studio IRISプラグインなど、その他の便利なコンポーネントもあります 。 特定のユースケース用の追加コードを使ってDockerでIRISを実行するのは簡単ですが、ソリューションを他のユーザーと共有する場合は、コマンドを実行し、コードを更新するたびに繰り返し実行するための何らかの方法が必要になります。 この記事では、継続的インテグレーション/継続的デリバリー (CI / CD)を使ってそのプロセスを簡素化する方法を説明します。 セットアップ まず、IRISをベースにしたシンプルなREST APIアプリケーションから紹介します。アプリケーションの詳細は、ビデオ「InterSystems IRIS、ObjectScript および DockerでREST API を作成する」でご覧いただけます。では、CI/CDを使用して似たようなアプリケーションを他の人と共有できるのかを見てみましょう。 最初は、コードを個人用GitHubリポジトリにCloneします。GitHubにアカウントを持っていない場合は、サインアップしてアカウントを1つ作成してください。便利なようにSSH経由でアクセスできるようにしてできるようにしておくとPullまたPushするたびにパスワードを入力する必要がなくなります。次に、GitHubのプロジェクトページintersystems-community/objectscript-rest-docker-templateGitHubに移動して、[Use this template] ボタンをクリックし、テンプレートに基づいて独自バージョンのリポジトリを作成します。「my-objectscript-rest-docker-template」のような名前を付けます。 次に、プロジェクトをローカルマシンにPullします。 $ git clone git@github.com:<your_account>/my-objectscript-rest-docker-template.git 次に、「hello, world!」を表示するRESTエンドポイントを追加します。 エンドポイントは src/cls/Sample/PersonREST.cls クラスで定義されています。 エンドポイントは次のようになります(最初の<Route>に定義されています)。 <Route Url="/helloworld" Method="GET" Call="HelloWorld"/><Route Url="/all" Method="GET" Call="GetAllPersons"/>... HelloWorldメソッドを呼び出します。 ClassMethod HelloWorld() As %Status{ Write "Hello, world!" Quit $$$OK} ここで、リモートリポジトリにPushするときこれがどのように機能するかを考慮する必要があります。 考慮点は次のとおりです。 Dockerイメージをビルドする。 Dockerイメージを保存する。 このイメージに基づいてコンテナを実行する。 すでにGitHubに統合されているCircleCIサービスを使用して、Dockerイメージをビルドします。 また、Dockerイメージを保存し、保存したイメージを基にしたコンテナをKubernetesで実行できるGoogle Cloudを使用します。 これについて少し掘り下げましょう。 Google Cloudの前提条件 サービスの無料枠を提供するGoogle Cloudのアカウントに登録したとしましょう。「Development」という名前のプロジェクトを作成し、「Create cluster」ボタンをクリックしてKubernetesクラスタを作成します。 デモでは、左側にある「Clusters」を選択します。Kubernetesの新しいバージョンを選択し、n1-standard-1のマシンタイプを選択します。 この目的では、1台のマシンで十分です。 「Create」ボタンをクリックして、クラスターへの接続を設定します。kubectlおよびgcloudユーティリティを使用します。 $ gcloud init[2] Create a new configurationConfiguration name. “development”[2] Log in with a new accountPick cloud project to useconfigure a default Compute Region and Zone? (Y/n)? yHere europe-west-1b was chosen $ gcloud container clusters get-credentials dev-cluster --zone europe-west1-b --project <project_id> [Connect]をクリックすると、最後のコマンドを取得できます。 kubectlからステータスを確認します。 $ kubectl config current-contextgke_possible-symbol-254507_europe-west1-b_dev-cluster $ kubectl get nodesNAME STATUS ROLES AGE VERSIONgke-dev-cluster-pool-2-8096d93c-fw5w Ready <none> 17m v1.14.7-gke.10 次に、ルートプロジェクトディレクトリの下に k8s/という名前のディレクトリを作成し、Kubernetesの将来のアプリケーションを記述する次の3つのファイルを保持します:ワークスペース、デプロイメント、サービスを記述するNamespaceです。 $ cat namespace.yamlapiVersion: v1kind: Namespacemetadata: name: iris $ cat deployment.yamlapiVersion: apps/v1beta1kind: Deploymentmetadata: name: iris-rest namespace: irisspec: replicas: 1 strategy: type: Recreate selector: matchLabels: app: iris template: metadata: labels: app: iris spec: containers: - image: eu.gcr.io/iris-rest:v1 name: iris-rest ports: - containerPort: 52773 name: web $ cat service.yamlapiVersion: v1kind: Servicemetadata: name: iris-rest namespace: irisspec: selector: app: iris ports: - protocol: TCP port: 52773 targetPort: 52773 type: LoadBalancer これらの定義をk8s/ディレクトリからGoogle Kubernetes Engine(GKE)に送信します。 $ kubectl apply -f namespace.yaml$ kubectl apply -f deployment.yaml -f service.yaml まだDockerレジストリにeu.gcr.io/iris-rest:v1イメージを送信していないので正常に機能していません。そのため、エラーが表示されます。 $ kubectl -n iris get poNAME READY STATUS RESTARTS AGEiris-rest-64cdb48f78-5g9hb 0/1 ErrImagePull 0 50s $ kubectl -n iris get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEiris-rest LoadBalancer 10.0.13.219 <pending> 52773:31425/TCP 20s Kubernetesは、 LoadBalancerサービスを検出すると、Google Cloud環境でバランサーを作成しようとします。 成功した場合、サービスは外部IP = <pending>ではなく実際のIPアドレスを取得します。 Kubernetesから少し離れる前に、CircleCIにサービスアカウントを作成して、DockerイメージをレジストリにPushし、Kubernetesデプロイを再起動する機能を持たせてみましょう。プロジェクトにサービスアカウントの編集者権限を付与します。 サービスアカウントの作成と保存に関する情報はここにあります。   少し後でCircleCIでプロジェクトを作成して設定するとき、次の3つの環境変数を追加する必要があります。 これらの変数の名前はご覧のとおりです。 GCLOUD_SERVICE_KEYの値は、サービスアカウントの作成後に「CREATE KEY」ボタンを押してキーを選択した際にGoogleが送信するJSON構造体です。 CircleCI それでは、CircleCI に着目し、GitHubアカウントを使用して登録します([サインアップ]をクリックし、次に[GitHubでサインアップ]をクリックします)。 登録後、GitHubリポジトリのプロジェクトを含むダッシュボードが[Add Projects]タブに表示されます。 「my-objectscript-rest-docker-template」または、objectscript-rest-docker-templateリポジトリから作成された、任意の名前を付けたリポジトリの[Set Up Project]ボタンをクリックします。 注: すべてのCircleCIスクリーンショットは2019年10月の時点で作成されたものです。 新しいバージョンでは変更が加えられている場合があります。 開いたページに、プロジェクトをCircleCIで動作させる方法を説明しています。最初のステップは.circleciという名前のフォルダーを作成し、それにconfig.ymlという名前のファイルを追加することです。 この設定ファイルの構造は、公式ドキュメントで詳しく説明されています。 ファイルに含まれる基本的な手順は次のとおりです。 リポジトリをPullする Dockerイメージをビルドする Amazon Cloudで認証する Google Dockerレジストリにイメージをアップロードする このイメージに基づいてGKEでコンテナを実行する 運が良ければ、すでに作成された構成( orbsと呼ばれる)をいくつか見つけて使うことができます。 公認のorbとサードパーティのorbがあります。 公認のGCP-GKE orbには制限がいくつもあるので、私たちのニーズを満たすサードパーティのorb(duksis)を見てみましょう。これを使用すると、設定ファイルは次のようになります(クラスタ名などの名前を実装に適した名前に置き換えてください)。 $ cat .circleci/config.ymlversion: 2.1orbs: gcp-gke: duksis/gcp-gke@0.1.9workflows: main: jobs: - gcp-gke/publish-and-rollout-image: google-project-id: GOOGLE_PROJECT_ID gcloud-service-key: GCLOUD_SERVICE_KEY registry-url: eu.gcr.io image: iris-rest tag: ${CIRCLE_SHA1} cluster: dev-cluster namespace: iris deployment: iris-rest container: iris-rest publish-and-rollout-imageタスクの初期設定は、プロジェクトページで確認できます 。 この orb の最後の3つの通知ステップは、実際には必要ありませんが、理想的には一度作成した独自のorbを何度も使用できることができますが、ここではそれについて説明しません。 CircleCIの[Organization settings]タブで、サードパーティ製orbの使用を明確に許可する必要があることに注意してください。 最後に、すべての変更をGitHubとCircleCIに送信します。 $ git add .circleci/ k8s/ src/cls/Sample/PersonREST.cls$ git commit -m "Deploy project to GKE using CircleCI"$ git push CircleCIダッシュボードを確認してみましょう。 Googleサービスアカウントキーを追加するのを忘れた場合は、次のようになります。 ですから、Google Cloudの前提条件セクションの末尾で説明されているように、これらの環境変数を追加することを忘れないでください。 忘れた場合は、その情報を更新してから[Rerun workflow]をクリックしてください。 ビルドが成功すると、緑色のバーが表示されます。 CircleCI Web UIから別にKubernetesポッドの状態を確認することもできます。 $ kubectl -n iris get po -wNAME READY STATUS RESTARTS AGEiris-rest-64chdb48f78-q5sbw 0/1 ImagePullBackOff 0 15m…iris-rest-5c9c86c768-vt7c9 1/1 Running 0 23s その最後の行( 1/1ランニング)は良い兆候です。 テストしてみましょう。 あなたのIPアドレスは私のIPアドレスと異なることを忘れないでください。 また、HTTPを介したパスワードについては、この記事の範囲外であるため、独自に調べる必要があります。 $ kubectl -n iris get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEiris-rest LoadBalancer 10.0.4.242 23.251.143.124 52773:30948/TCP 18m $ curl -XGET -u _system:SYS 23.251.143.124:52773/person/helloworldHello, world! $ curl -XPOST -H "Content-Type: application/json" -u _system:SYS 23.251.143.124:52773/person/ -d '{"Name":"John Dou"}' $ curl -XGET -u _system:SYS 23.251.143.124:52773/person/all[{"Name":"John Dou"},] アプリケーションは動作しているようです。 プロジェクトページで説明されているテストを続行できます 。 要するに、GitHub、CircleCI、およびGoogle Cloud Kubernetes Engineの組み合わせは、完全に無料ではないとしても、IRISアプリケーションのテストとデプロイメントには非常に有望と思われます。また、Kubernetesクラスターを実行すると、仮想の(そして実際の)お金が徐々に消費される可能性があることを忘れないでください。 弊社はあなたに請求される可能性のある料金については責任を負わないものとします。
お知らせ
Mihoko Iijima · 2020年8月6日

第5回 InterSystems IRIS プログラミングコンテスト(IRIS for Health FHIR コンテスト)

開発者のみなさん、こんにちは! InterSystems IRIS Data Platform を使用してオープンソースソリューションを作成するコンテストへようこそ! 今回のコンテスト用テンプレートはこちら!(8/10 更新) ➡️ IRIS-FHIR-Template ⬅️(InterSystems IRIS for Health のプレビューリリース版:2020.3 が利用されている開発テンプレートです) テンプレートの日本語 Readme をご用意しています。 応募期間は 2020年8月10日~23日 です! 優勝特典 1、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 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日 優秀者発表 コンテストのテーマ 💡 Fast Healthcare Interoperability Resources – FHIR 💡 第5回目のテーマは「InterSystems IRIS for Health を使用して FHIR ソリューションを開発する」です。 InterSystems IRIS for Health を使用し、FHIR に関連するライブラリ、パッケージ、ツール、FHIRソリューションを開発いただき、ご応募ください。 ご応募いただいた中から、最も優秀な作品に賞が贈られます。 アプリケーションは IRIS for Health Community Edition で動作するように作成してください。 アプリケーションはオープンソースであり、GitHub で公開されている必要があります。 特別な技術を活用して開発されたアプリケーションは、テクノロジボーナスの対象となります。ボーナスの詳細については、このページで後日お知らせします。 コンテスト用テンプレートについて(8/8更新) IRIS-FHIR-Template (8/10更新:テンプレートの日本語 Readme) ご参考情報 コンテスト応募方法(このページ末尾のビデオをご参照ください) ドキュメント FHIR Support in InterSystems Products(英語) オンラインコース(英語) Learn FHIR for Software Developers Building SMART on FHIR Apps with InterSystems FHIR Sandbox Exploring FHIR Resource APIs Using InterSystems IRIS for Health to Reduce Readmissions Connecting Devices to InterSystems IRIS for Health Monitoring Oxygen Saturation in Infants FHIR Integration QuickStart ビデオ(英語) 6 Rapid FHIR Questions SMART on FHIR: The Basics Developing with FHIR - REST APIs FHIR in InterSystems IRIS for Health FHIR API Management Searching for FHIR Resources in IRIS for Health その他:開発者コミュニティ(US版)のYouTubeもご参照ください ビデオ(日本語) InterSystems IRIS for Health による FHIR API の構築(1) InterSystems IRIS for Health による FHIR API の構築(2) FHIRについてのQA 開発者コミュニティのFHIRタグ(US版/日本版) community.fhir.org 審査及び投票ルール(英語) インターシステムズ社のプロダクトマネージャ、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」ボタンが表示されるので、クリックすると応募が完了します。 開発テンプレートの使い方ビデオを公開しました! FHIR コンテストのテンプレートの使用方法をご紹介しています。 テンプレートをご利用いただくためには、以下 (3) にある3つのソフトウェアのインストールが必要です。 ビデオ内で記述しているコマンドなどは、(4)以降 をご参照ください。 (1) IRISオンラインプログラミングコンテスト FHIRコンテストの詳細 この記事 (2) テンプレートの説明 iris-fhir-template テンプレート iris-fhir-template の Git (3) 事前準備 Dockerのインストール(コンテナを管理するアプリ) Gitのインストール(ソースを管理するアプリ) VSCodeのインストール(IDE) (4) コマンド実行例 開発テンプレートのダウンロード cd 任意のディレクトリgit clone https://github.com/intersystems-community/iris-fhir-template.git コンテナ作成のためのビルド docker-compose build コンテナの開始 docker-compose up -d コンテナの停止 docker-compose stop コンテナ一覧を表示 docker ps コンテナ一覧に表示されるコンテナ名を使用してコンテナにログインします。 docker exec -it <コンテナ名> bash (5) 目次(YouTubeでご覧いただくと指定秒数にジャンプできます) 最初から~ コンテスト告知ページから開発テンプレート公開ページへの移動方法 00:49~ iris-fhir-template テンプレートのダウンロード(git clone) 01:11~ テンプレートに含まれるコードの紹介(VSCode利用) 01:51~ コンテナの中身について 03:05~ コンテナ開始     FHIRリポジトリにインポートしているサンプルデータについて 03:35~ RESTクライアントからの確認方法(Postman利用例について) 04:25~ サンプルアプリ(HTML)で実行しているGET要求の説明 06:20~ PostmanからサンプルURLを実行 (Patientに対するGET要求、AppointmentのPOST要求など) 10:10~ サンプルアプリ(HTML)の実行 12:25~ Patientデータを増やす方法 参考URL: https://github.com/intersystems-community/iris-fhir-template/blob/master/README-JP.md ぜひ、IRISプログラミングコンテストへご応募ください!
記事
Makiko Kokubun · 2021年5月25日

動画:クラウド環境でのInterSystems製品バックアップ戦略

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。 この動画では、クラウド環境下で利用可能な InterSystems 製品の様々なバックアップオプションと戦略、そしてサードパーティのバックアップ代替オプションについて紹介します。 今現在、クラウド環境をご利用でない方にも役立てて頂ける情報も紹介します。ぜひご覧ください。 関連動画として、こちらも公開しています。宜しければご覧下さい。「クラウドストレージ戦略」(字幕付き動画)
記事
Megumi Kakechi · 2021年11月10日

InterSystems製品のプロセスが使用するメモリ量について

これは InterSystems FAQ サイトの記事です。 InterSystems製品のプロセスが消費するメモリ領域は以下の6つの領域になります。 プロセスのプライベートな領域  1. プロセスパーティション(ローカル変数テーブル等、プロセスごとに使用するメモリ) 2. 長い文字列(LongString)使用メモリ 3. 文字列スタック...等 プロセス間共有領域  4. データベースキャッシュ 5. ルーチンキャッシュ 6. 一般ヒープメモリ(プロセステーブル、ロックテーブル等) プロセスが使用するメモリ領域は、「プライベート領域」と「共有領域」の大きく2種類に分かれます。プライベートな領域はそのプロセスのみが使用し、個々のプロセス毎にメモリを割り当てます。共有領域は、プロセス間で一つのメモリ領域を共有してアクセスしていますので実体はメモリ上に 1つです。以下それぞれの領域の値は、管理ポータルで指定します(設定可能な場合)。(1) プロセスパーティションのサイズ  [システム管理] > [構成] > [システム構成] > [メモリと開始設定] > [プロセスあたりの最大メモリ(KB)]  このプロセスパーティションサイズの初期値は 128 KBytes になっており、プロセスがこの領域を使用すると自動的に拡張します。 管理ポータルでの設定は、このパーティションが拡張できる最大値を設定しています。 (2) 長い文字列(LongString)使用メモリ  ※Caché2007.1~  プロセスで実際に長い文字列が使用されると、文字列用のメモリをそのプロセス用のパーティションメモリ領域から割り当てるのではなく、オペレーティングシステムで malloc() により割り当てられます。 上限はありません(仮想メモリ [=物理メモリ+ページファイル] から確保可能な上限まで)。 文字列が破棄されると、長い文字列用に取得したメモリを解放します。  ※以下ドキュメントをご参照ください 長い文字列について (3) 文字列スタック  プロセスで文字列を処理するための作業領域です。Unicode環境では、最大14MBです。 LongStringを無効にした場合(IRISでは無効にはできません)は、Unicode環境で 264 KBです。 (4) データベースキャッシュ  [システム管理] > [構成] > [システム構成] > [メモリと開始設定]:8KBデータベースキャッシュ用メモリ (MB) (5) ルーチンキャッシュ  [システム管理] > [構成] > [システム構成] > [メモリと開始設定]:ルーチンキャッシュ用メモリ (MB) (6) 一般ヒープメモリ  [システム管理] > [構成] > [追加の設定] > [メモリ詳細] > [gmheap] 以上の要素でプロセスが使用するメモリサイズが決まり、1つのプロセスでの最大使用メモリはおおよそ上記6つの値の合計値になります。 全プロセスで使用するメモリサイズは以下のとおりです。 [ { (1)プロセスパーティション + (3)文字列スタック } × プロセス数 ] + (2) 長い文字列使用メモリ(全プロセス合計※) + (4) データベースキャッシュ + (5) ルーチンキャッシュ + (6) 一般ヒープメモリ ※長い文字列使用メモリとして実際にどの位のメモリ総サイズが必要になるかは、アプリケーション単位で算出する必要があります。 また、各プロセスはアクセスするメモリ領域を管理するページテーブルを持ちます(OSにより管理される領域)。プロセス間共有領域を Small page として確保している場合は、このページテーブルのサイズが大きくなります(1GB当たり32MB)。これを Large page で確保するとページテーブルサイズが小さくなります(1GB当たり64KB)。Large page で確保した場合は、起動時に messages.log/cconsole.log に以下のメッセージが出力されます。 MM/DD/YY-hh:mm:ss:sss ( 0) 0 Allocated ***MB shared memory (large pages): ***MB global buffers, ***MB routine buffers 詳細については、下記の技術資料を公開しております。Windows上でのCaché共有メモリの割り当てについて メモリ要件の見積もりについては、以下のドキュメントをご覧ください。メモリ要件の見積もり あわせて、以下の関連記事も是非ご覧ください。 <STORE>エラーが発生する場合の対処法について 管理ポータルのメモリ関連設定項目について System routine buffer (# KB) shortage is detected.... のメッセージの意味と対処方法 データベースキャッシュおよびルーチンキャッシュの最適値の設定方法 Windows上での共有メモリの割り当てについて IRISが使用するワーキングセット(メモリ)について
記事
Mihoko Iijima · 2022年4月13日

Store Mindmaps using Globals(InterSystems Global コンテスト優勝作品紹介)

開発者の皆さん、こんにちは! この記事では、InterSystems Global コンテストで見事優勝🏆された @Yuri.Gomes さんの作品をご紹介します!(ご本人が投稿された記事を使ってご紹介します) InterSystems IRIS の「Global」はデータベースに格納される変数で、キーバリュー形式でアクセスできます。キーが複数ある場合は、配列の添え字を利用して階層のようなイメージで格納することもできます。 ここでご紹介する優勝作品は、配列をうまく利用した作品で、MindMapで書いた情報そのまま(見たまま)をグローバルに登録しています。 MindMapの表示部分については、オープンソースの Mind-elixir を使用されているようです。 ソースコードは OpenExchange で公開中で、git clone 後、 docker-compose up -d --build したらすぐ動きます!(docker 🐳ほんとに便利ですね!) また、ご本人の解説ビデオも YouTube で絶賛公開中です!お手元で動かさなくてもどんな感じで Global が使われているか、どんな感じで Web アプリを作成されているのかを確認できますので、ぜひご覧ください! Global の登録内容は 2:26秒辺りから、フロントエンドの解説は 3:11 辺りから 以下、Yuri さんが投稿された記事の内容です。 Global は、データを永続化する InterSystems IRIS のコアとなるものです。柔軟性があり、JSON ドキュメント、リレーショナル・データ、オブジェクト指向データ、OLAP キューブ、および Mindmaps のようなカスタム・データ・モデルを保存できます。 グローバルを使用してMindMp データを保存、削除、取得する方法については、以下の手順をご参照ください。 docker/docker-compose/git がインストールされている環境でお試しください。 1. サンプルコードをローカルに clone/pull する手順は以下の通りです。 $ git clone https://github.com/yurimarx/global-mindmap.git 2. clone後、作成されたディレクトリに移動し、ターミナルで以下実行し、イメージをビルドします。 $ docker-compose build 3. 以下のコマンドを実行し、コンテナを開始します。 $ docker-compose up -d 4. Mindmap フロントエンドを開き、👆に貼っているGIFアニメのように動かす場合は http://localhost:3000 にアクセスします(または、http://localhost:52773/mindmap/index.html を開きます)。 ソースコードについての解説 保存するデータの構造は以下の通りです (詳細はこちらをご覧ください: https://www.npmjs.com/package/mind-elixir): { topic: 'node topic', id: 'bd1c24420cd2c2f5', style: { fontSize: '32', color: '#3298db', background: '#ecf0f1' }, parent: null, tags: ['Tag'], icons: ['😀'], hyperLink: 'https://github.com/ssshooter/mind-elixir-core', } parent プロパティは、MindMap のノード間に親子関係を構築するために使用されます。 ^mindmap グローバルに登録する部分のソースコード ClassMethod StoreMindmapNode /// Store mindmap node ClassMethod StoreMindmapNode() As %Status { Try { Set data = {}.%FromJSON(%request.Content) Set ^mindmap(data.id) = data.id /// set mindmap key Set ^mindmap(data.id, "topic") = data.topic /// set topic subscript Set ^mindmap(data.id, "style", "fontSize") = data.style.fontSize /// set style properties subscripts Set ^mindmap(data.id, "style", "color") = data.style.color Set ^mindmap(data.id, "style", "background") = data.style.background Set ^mindmap(data.id, "parent") = data.parent /// store parent id subscript Set ^mindmap(data.id, "tags") = data.tags.%ToJSON() /// store tags subscript Set ^mindmap(data.id, "icons") = data.icons.%ToJSON() /// store icons subscript Set ^mindmap(data.id, "hyperLink") = data.hyperLink /// store hyperLink subscript Set %response.Status = 200 Set %response.Headers("Access-Control-Allow-Origin")="*" Write "Saved" Return $$$OK } Catch err { write !, "Error name: ", ?20, err.Name, !, "Error code: ", ?20, err.Code, !, "Error location: ", ?20, err.Location, !, "Additional data: ", ?20, err.Data, ! Return $$$NOTOK } } ^mindmap グローバルを作成しています。mindmap のプロパティについては、Global の添え字に設定しています。添え字のキーは mindmap の id プロパティの値を設定しています。 ^mindmap ノードを削除するサンプルコード: Global の kill (削除) ClassMethod DeleteMindmapNode /// Delete mindmap node ClassMethod DeleteMindmapNode(id As %String) As %Status { Try { Kill ^mindmap(id) /// delete selected mindmap node using the id (global key) Set %response.Status = 200 Set %response.Headers("Access-Control-Allow-Origin")="*" Write "Deleted" Return $$$OK } Catch err { write !, "Error name: ", ?20, err.Name, !, "Error code: ", ?20, err.Code, !, "Error location: ", ?20, err.Location, !, "Additional data: ", ?20, err.Data, ! Return $$$NOTOK } } このサンプルでは、minamap.id を ^mindmap グローバルのキーとして利用しているので削除は簡単です。以下実行するだけです。 kill ^mindmap(<mindmap id>) 全格納情報を取得するコード例 - $ORDER()関数を使用してGlobal をループする ClassMethod GetMindmap - return all mindmap global nodes /// Get mindmap content ClassMethod GetMindmap() As %Status { Try { Set Nodes = [] Set Key = $Order(^mindmap("")) /// get the first mindmap node stored - the root Set Row = 0 While (Key '= "") { /// while get child mindmap nodes Do Nodes.%Push({}) /// create a item into result Set Nodes.%Get(Row).style = {} Set Nodes.%Get(Row).id = Key /// return the id property Set Nodes.%Get(Row).hyperLink = ^mindmap(Key,"hyperLink") /// return the hyperlink property Set Nodes.%Get(Row).icons = ^mindmap(Key,"icons") /// return icons property Set Nodes.%Get(Row).parent = ^mindmap(Key,"parent") /// return parent id property Set Nodes.%Get(Row).style.background = ^mindmap(Key,"style", "background") /// return the style properties Set Nodes.%Get(Row).style.color = ^mindmap(Key,"style", "color") Set Nodes.%Get(Row).style.fontSize = ^mindmap(Key,"style", "fontSize") Set Nodes.%Get(Row).tags = ^mindmap(Key,"tags") /// return tags property Set Nodes.%Get(Row).topic = ^mindmap(Key,"topic") /// return topic property (title mindmap node) Set Row = Row + 1 Set Key = $Order(^mindmap(Key)) /// get the key to the next mindmap global node } Set %response.Status = 200 Set %response.Headers("Access-Control-Allow-Origin")="*" Write Nodes.%ToJSON() Return $$$OK } Catch err { write !, "Error name: ", ?20, err.Name, !, "Error code: ", ?20, err.Code, !, "Error location: ", ?20, err.Location, !, "Additional data: ", ?20, err.Data, ! Return $$$NOTOK } } ^mindmap グローバルの第1番目の添え字にある最初の情報(ルートノード)を取得するために、$Order(^mindmap("")) を実行しています(取得した内容は変数 Key に設定しています)。 ^mindmap(Key, <property name>) を使用して、各プロパティ値を取得しています。次に登録されている Key を取得するため、While文の最後に $Order(^mindmap(Key) を実行しています。 フロントエンド MindMap のレンダリングと編集には Mind-elixir と React が使われ、IRIS で構築された API バックエンドを呼び出しています。詳細は、MindMap の react コンポーネントを参照してください。 Mindmap React component - consuming IRIS REST API import React from "react"; import MindElixir, { E } from "mind-elixir"; import axios from 'axios'; class Mindmap extends React.Component { componentDidMount() { this.dynamicWidth = window.innerWidth; this.dynamicHeight = window.innerHeight; axios.get(`http://localhost:52773/global-mindmap/hasContent`) .then(res => { if (res.data == "1") { axios.get(`http://localhost:52773/global-mindmap/get`) .then(res2 => { this.ME = new MindElixir({ el: "#map", direction: MindElixir.LEFT, data: this.renderExistentMindmap(res2.data), draggable: true, // default true contextMenu: true, // default true toolBar: true, // default true nodeMenu: true, // default true keypress: true // default true }); this.ME.bus.addListener('operation', operation => { console.log(operation) if (operation.name == 'finishEdit' || operation.name == 'editStyle') { this.saveMindmapNode(operation.obj) } else if (operation.name == 'removeNode') { this.deleteMindmapNode(operation.obj.id) } }) this.ME.init(); }) } else { this.ME = new MindElixir({ el: "#map", direction: MindElixir.LEFT, data: MindElixir.new("New Mindmap"), draggable: true, // default true contextMenu: true, // default true toolBar: true, // default true nodeMenu: true, // default true keypress: true // default true }); this.ME.bus.addListener('operation', operation => { console.log(operation) if (operation.name == 'finishEdit' || operation.name == 'editStyle') { this.saveMindmapNode(operation.obj) } else if (operation.name == 'removeNode') { this.deleteMindmapNode(operation.obj.id) } }) this.saveMindmapNode(this.ME.nodeData) this.ME.init(); } }) } render() { return ( <div id="map" style={{ height: window.innerHeight + 'px', width: '100%' }} /> ); } deleteMindmapNode(mindmapNodeId) { axios.delete(`http://localhost:52773/global-mindmap/delete/${mindmapNodeId}`) .then(res => { console.log(res); console.log(res.data); }) } saveMindmapNode(node) { axios.post(`http://localhost:52773/global-mindmap/save`, { topic: (node.topic == undefined ? "" : node.topic), id: node.id, style: (node.style == undefined ? "" : node.style), parent: (node.parent == undefined ? "" : node.parent.id), tags: (node.tags == undefined ? [] : node.tags), icons: (node.icons == undefined ? [] : node.icons), hyperLink: (node.hyperLink == undefined ? "" : node.hyperLink) }) .then(res => { console.log(res); console.log(res.data); }) } renderExistentMindmap(data) { let root = data[0] let nodeData = { id: root.id, topic: root.topic, root: true, style: { background: root.style.background, color: root.style.color, fontSize: root.style.fontSize, }, hyperLink: root.hyperLink, children: [] } this.createTree(nodeData, data) return { nodeData } } createTree(nodeData, data) { for(let i = 1; i < data.length; i++) { if(data[i].parent == nodeData.id) { let newNode = { id: data[i].id, topic: data[i].topic, root: false, style: { background: data[i].style.background, color: data[i].style.color, fontSize: data[i].style.fontSize, }, hyperLink: data[i].hyperLink, children: [] } nodeData.children.push(newNode) this.createTree(newNode, data) } } } } export default Mindmap; もし、このサンプルコードが気に入りましたら、InterSystems Global コンテストで私の作品に投票してください! ありがとうございました。
お知らせ
Mihoko Iijima · 2022年11月16日

テクノロジーボーナス詳細:InterSystems IRIS for Health コンテスト: FHIR for Women's Health

開発者の皆さん、こんにちは! InterSystems IRIS for Health コンテスト: FHIR for Women's Health 2022 のテクノロジーボーナスが発表されました! Women’s Health に関するトピック Women’s Health データセット IRIS For Health FHIR または FHIR Cloud Server の利用 Healthcare Interoperability Embedded Python の利用 Docker コンテナの利用 ZPM パッケージを使ったデプロイ オンラインデモの公開 Code Quality をパスする コミュニティの記事を書く コミュニティに2つ目の記事を書く YouTubeにビデオを公開する はじめてチャレンジされた方 獲得ポイントについて詳細は、以下ご参照ください。 Women’s Health に関するトピック - 5 points アプリケーションが Women's Health の問題解決を助けるようなアプリケーションを開発した場合、5ポイント獲得できます。 例えば、妊娠中の患者が妊娠中の症状を追跡でき、変化の傾向を発見できるようなアプリケーションだったり、症状や妊娠中の日誌をパートナーアプリケーションと共有できる統合システムを開発するなど。 Women’s Health データセット - 3 points Open Exchange にあなたが作成した Women's Health データセットを投稿し、アプリケーションで使用している場合、3ポイント獲得できます。 OpenExchangeにあるデータセットの例: titanic, community posts, health datasets OpenExchangeに登録する際、データセットとアプリケーションは分けて登録してください。 IRIS For Health または InterSystems FHIR Server Cloud の使用 - 2 points あなたのソリューションが IRIS for Health または、InterSystems FHIR Server on AWS を使用した FHIR サーバである場合、2ポイント獲得できます。 FHIR サーバを実行するIRIS for Health のテンプレートはこちらから入手できます。FHIRサーバのインスタンスは、こちらから ご参考:FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介 Healthcare Interoperability - 4 points あなたのアプリケーションが、 InterSystems Interoperaiblityを使用してメッセージによる医療データの変換や転送を行う Helathcare Interoperability ソリューションである場合、または、ヘルスケアフォーマットのデータ変換を使用する場合、4ポイント獲得できます。healthcare interoperability solution の例 Embedded Python の利用 - 3 points あなたのアプリケーションで Embedded Python を使用している場合、3ポイント獲得できます。Embedded Pythonを使用するためには、IRIS 2021.2以降のバージョンをご利用ください。 Docker コンテナの利用 - 2 points InterSysetms IRISが稼働している docker コンテナを使用している場合、Docker コンテナボーナスを獲得できます。 テンプレートはこちらにあります。 ご参考:開発環境テンプレート(IRIS プログラミングコンテストで使用していたテンプレート)の一覧 ZPM パッケージによるデプロイ- 2 points 以下のようにデプロイできる ZPM(InterSystems Package Manager)であなたのFull Stackアプリケーションを公開するとボーナスポイントを獲得できます。 zpm "install your-multi-model-solution" 上記コマンドをZPMクライアントがインストールされたIRISで実行します。 ZPM について/ZPM Documentati オンラインデモの公開 - 2 points オンラインデモとしてアプリケーションをクラウドにプロビジョニングすると、3ポイント獲得できます。開発環境テンプレートやその他のデプロイメントオプションを使用することができます。例サンプルアプリケーションの使用方法についてはビデオをご参照ください。 Code quality をパスしてBug 0件 を表示させる - 1 point コードの静的制御のためのcode quality Github actionを組み込み、ObjectScriptの Bug 0件 と表示させるとボーナスポイントを獲得できます。 コミュニティに記事を投稿する - 2 points コミュニティに応募したアプリケーションの概要を説明する記事を投稿すると2ポイントを獲得できます。 コミュニティに2つ目の記事を投稿する - 1 point 2つ目の記事を投稿する、または投稿したアプリケーション概要の翻訳記事を投稿することで、さらボーナスポイントを獲得できます。(3記事以降はポイントが加算されません。) YouTube にビデオを公開する - 3 points 開発した作品の動画を作成し、YouTube に掲載した場合、3ポイント獲得できます 初めてチャレンジされた方 - 3 points InterSystems Open Exhangeコンテストに初めて参加された場合、3ポイント獲得できます! ※ ボーナスポイントについては、変更される可能性もあります。予めご了承ください。
記事
Toshihiko Minamoto · 2023年7月5日

開発者コミュニティの記事によるInterSystems IRISの学習

この記事では、InterSystems IRIS の学習に関連したトピックについて、開発者コミュニティでの厳選された記事にアクセスすることができます。機械学習や Embedded Python、JSON、API と REST アプリ、InterSystems環境の構築と管理、DockerとCloud、VSCode、SQL、Analytics/BI、グローバル、セキュリティ、DevOps、インターオペラビリティNative API、それぞれでランク付けされたトップの記事を見ることができます。ぜひ、楽しみながら学んでください!   ## 機械学習 機械学習は、高度なデータ分析を構築し、優れた効率で手動活動を自動化するための必須技術です。既存のデータから学習する認知モデルを作成し、自己調整されたアルゴリズムに基づいて予測、確率計算、分類、識別、「非創造的」な人間の活動の自動化を実行します。 すべてのシナリオにおいて、InterSystems IRISは、これらのマシンラーニングモデルを作成、実行、利用可能にし、使用するためのデータプラットフォームおよび環境として機能します。IRISは、SQLコマンドからのML利用(IntegratedML)、Embedded PythonやPMML(Predictive Model Markup Language)による機械学習が可能です。以下の記事でその機能を確認することができます。 | 名称 | 概要 | URL | | ---------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------- | | IntegratedMLハンズオンラボ | IntegratedMLの実践的な概要 | https://community.intersystems.com/post/integratedml-hands-lab | | InterSystems IRISデータプラットフォームによるAIロボット化 | IRISプロダクションのAI | https://community.intersystems.com/post/ai-robotization-intersystems-iris-data-platform | | IRIS IntegratedMLを使った糖尿病予測Webアプリ | IntegratedMLサンプル | https://jp.community.intersystems.com/node/535221 | | 妊産婦の健康リスクの予測 | IntegratedMLサンプル | https://community.intersystems.com/post/predict-maternal-health-risks | | 機械学習によるコミュニティー記事の整理 - 1 | Python MLライブラリの利用 | https://community.intersystems.com/post/using-machine-learning-organize-community-1 | ##   ## ObjectScript言語 ObjectScript は InterSystems のオフィシャルプログラミング言語です。簡単で柔軟性があり、バックエンド、統合、および分析アプリケーションの作成に非常に強力です。詳細については、以下の記事を参照してください。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | InterSystems ObjectScript 101++ (EN) | ObjectScriptを学ぶビデオシリーズ | https://community.intersystems.com/post/intersystems-objectscript-101-en | | $Sequence関数について | 数列の作成する | https://community.intersystems.com/post/sequence-function | | Caché ObjectScript でのパフォーマンスの高いループの作成 | ループの作成 | https://jp.community.intersystems.com/node/481811 | | データの匿名化、iris-Disguiseの導入 | ObjectScript の永続的なクラスとプロパティをカスタマイズする方法について説明する | https://jp.community.intersystems.com/node/510731 | | ObjectScriptのエラー処理に関するスニペット | 例外処理 | https://jp.community.intersystems.com/node/491451 | | ObjectScriptにおける従来のデバッグ | デバッグ手法 | https://community.intersystems.com/post/traditional-debugging-objectscript | | Caché での正規表現の使用 | 正規表現を使った作業 | https://jp.community.intersystems.com/node/481816 | | ObjectScript における堅牢なエラー処理とクリーンアップ | 品質の高いコードを書く | https://jp.community.intersystems.com/node/486226 | | InterSystems Ensembleを愛し、心配することをやめた理由 | プロダクションでのJSON処理 | https://community.intersystems.com/post/how-we-learned-stop-worrying-and-love-intersystems-ensemble | | より使いやすくなったオブジェクト・ダンプ | ダンプするオブジェクト | https://community.intersystems.com/post/more-usefull-object-dump | | InterSystems IRISのマクロを使ったロギング | マクロを使ったロギング | https://jp.community.intersystems.com/node/503796 | | SYSLOG - その実態と意味すること | シスログのデバッグ情報 | https://jp.community.intersystems.com/node/492146 | | %Statusを使ったデバッグのヒント | %Statusを使ったデバッグ | https://jp.community.intersystems.com/node/503801 | | $Queryの有効活用 | $Query を使ってデータを探す | https://community.intersystems.com/post/making-most-query | | 多次元プロパティの永続性 - Part 1 (クラシック) | 多次元永続プロパティ | https://community.intersystems.com/post/multidimensional-property-persistence-part-1-classic | | 採用されたBitmap | Bitmap インデックス | https://community.intersystems.com/post/adopted-bitmap | | タイムロードになる方法 - 誕生 | 日付と時刻のAPI | https://jp.community.intersystems.com/node/527796 | | 正確なバージョン情報($zv / $zversion)の重要性と収集について | IRISバージョン取得 | https://community.intersystems.com/post/importance-and-collection-exact-version-information-zv-zversion | | 1840年12月以前の日付 ? $H( orolog )がネガティブ? | ネガティブな日付 | https://community.intersystems.com/post/date-dec1840-negative-horolog | | Caché でのカスタム・インデックス・タイプの作成 | カスタムインデックスの作成 | https://jp.community.intersystems.com/node/479316 | | $LIST 文字列フォーマットと %DynamicArray および %DynamicObject クラス | $LIST、%DynamicObject、%DynamicArrayの使用法 | https://jp.community.intersystems.com/node/483711 | | ^ERRORグローバルに対するSQL | SQLを使ってエラーの内容の確認 | https://community.intersystems.com/post/sql-error-global | | コードによるデフォルト設定値の追加 | デフォルト値の設定 | https://community.intersystems.com/post/add-default-setting-value-code | | ダイナミックオブジェクトの反復処理 | イテレート(反復処理)の使用 | https://community.intersystems.com/post/iterate-over-dynamic-object | | クラスのすべてのプロパティをリストアップする (ObjectScriptがお気に入りな理由) | ObjectScriptプロパティの反復使用 | https://jp.community.intersystems.com/node/515786 | | いつも使っているtry catchブロック | Try Catchのハンドリング | https://community.intersystems.com/post/try-catch-block-i-usually-use-intersystems-objectscript | | ObjectScriptでシェルコマンドの実行 | ObjectScriptでシェルコマンドの実行 | https://community.intersystems.com/post/running-shell-commands-objectscript | ## Embedded Python Python は、世界で最も人気があり、よく使われているプログラミング言語の 1 つです (https://www.tiobe.com/tiobe-index/)。InterSystems IRIS は、すべての主要なプログラミング言語に対して開かれたデータ・プラットフォームです。しかし、Python は、この素晴らしい言語とそのライブラリは、クラス、SQL、および統合/プロダクショ ンなど、IRIS のあらゆる場所で使用することができます。ObjectScript ( InterSystems のプログラミング言語 ) を知らない、または知りたくない人にとって、Python は素晴らしい選択肢となります。そのやり方については、以下の記事を参照してください。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | 機械と戦おう | Embedded Pythonを使ったチックタックトー・ゲームの構築 | https://community.intersystems.com/post/lets-fight-against-machines | | InterSystems IRIS 2021.2+ Python サンプル ( Embedded, Native API およびノートPC) | 複数のPythonノートPCでPythonとIRISを見る | https://community.intersystems.com/post/intersystems-iris-20212-python-examples-embedded-native-apis-and-notebooks | | Embedded PythonによるWebSocketクライアント | Custom Socket サンプル | https://community.intersystems.com/post/websocket-client-embedded-python | | AWS LambdaにおけるIRIS Python Native API | AWSでのPython | https://community.intersystems.com/node/485361 | | JupyterノートPCにObjectScriptを追加する方法 | ノートPCでのIRIS | https://jp.community.intersystems.com/node/521496 | | ようこそDjango | IRISをデータベースとしたPython Djangoアプリの作成 | https://jp.community.intersystems.com/node/527801 | | IRISとGoogle Maps APIによるジオコーディング | Geocoding python ライブラリの使用 | https://community.intersystems.com/post/geocoding-iris-and-google-maps-api | | IRISとPython gTTSを用いたテキストから音声への変換のためのRESTサービス | gTTSを使用したPythonサンプル | https://community.intersystems.com/post/rest-service-convert-text-audio-using-iris-and-python-gtts | | Python Flask WebフレームワークによるIRISレスポンシブダッシュボードの作成 | IRISによるFlask Webアプリ | https://community.intersystems.com/post/building-iris-responsive-dashboard-python-flask-web-framework | ## JSON JSON は、マーケットで最も広く使用されている、データの送受信のための相互運用性フォーマットの 1 つです。InterSystems IRIS は、いくつかの方法でこの形式をサポートしています。JSON (DocDB) でネイティブ・データベースを持ち、オブジェクトを直列化および非直列化し、特に REST サービスからの要求と応答を JSON で処理することが可能です。以下の記事を確認してください。 | 名称 | 概要 | URL | | ------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------------------------ | | Caché 2016.1における新しいJSON機能の紹介 | ObjectScript JSON API の紹介 | https://community.intersystems.com/post/introducing-new-json-capabilities-cach%C3%A9-20161 | | JSONの機能強化 | JSON Adaptor API | https://jp.community.intersystems.com/node/481776 | ## APIとRESTアプリ バックグラウンドアプリケーションは現在、REST(Representational State Transfer)パラダイムで開発され、Web APIとして公開されています。以下の記事で、その仕組みを確認してください。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | InterSystemsのデータプラットフォームのためのGraphQL | GraphQLスタイルでREST APIの作成 | https://jp.community.intersystems.com/node/481796 | | InterSystems API Managerの紹介 | API Managementの概要 | https://community.intersystems.com/post/introducing-intersystems-api-manager | | RESTの高度なURLマッピング | APIへの経路のマッピング | https://jp.community.intersystems.com/node/497976 | | AppS.REST: InterSystems IRISのための新しいRESTフレームワーク | RESTアプリを簡単に作成 | https://jp.community.intersystems.com/node/497991 | | RESTForms : クラスのためのREST API | CRUDアプリケーションのためのREST APIの開発 | https://jp.community.intersystems.com/node/479226 | | スペックファーストのアプローチによるREST APIの作成 | Contract First ApproachによるAPI開発 | https://jp.community.intersystems.com/node/476556 | | ObjectScript REST API クックブック | REST API 開発のヒント | https://community.intersystems.com/post/objectscript-rest-api-cookbook | | 永続クラスとシリアルクラスからSwaggerスペックを生成する | Contract First ApproachによるAPI開発 | https://jp.community.intersystems.com/node/490976 | | InterSystems IRIS REST アプリケーションのパターン | IRISによるAPI RESTの作成 | https://community.intersystems.com/post/intersystems-iris-rest-application-patterns | | SUSHIでFHIRプロファイルを作成しよう 第1回 | カスタムFHIRプロファイルの作成 | https://jp.community.intersystems.com/node/493351 | | ゼロから使いこなすIAM | IAMでAPIの管理 | https://jp.community.intersystems.com/node/493416 | | InterSystems API Management を使用してAPIの負荷を分散する | APIMによるAPIのロードバランス | https://jp.community.intersystems.com/node/482711 | | InterSystems API Management で OAuth 2.0 による API のセキュリティの確保 - 第1回 | APIMによるAPI のセキュリティの確保 | hhttps://jp.community.intersystems.com/node/497946 | | InterSystems IRISアプリケーションのAngular UIを5分で取得 | IRISとAngularによるFull Stackアプリ | https://community.intersystems.com/post/getting-angular-ui-your-intersystems-iris-application-5-minutes | | InterSystems IRIS REST APIへのアップロード | REST APIによるファイル保存 | https://community.intersystems.com/post/upload-intersystems-iris-rest-api | ## InterSystems 環境の管理と設定 IRIS環境を適切に管理・設定することは、ユーザーが使用するアプリケーションのパフォーマンス、セキュリティ、可用性、信頼性にとって不可欠です。これらの記事は、これを行うための優れたヒントを与えてくれるでしょう。 | 名称 | 概要 | URL | | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | InterSystemsデータプラットフォームにおける容量計画およびパフォーマンスのシリーズのインデックス | 性能とパフォーマンスの向上 |https://jp.community.intersystems.com/node/477596 | | InterSystems Cache での %Installer によるアプリケーションのデプロイメント | %Installer によるネームスペース、データベース、およびアプリケーションの構成の作成 | https://jp.community.intersystems.com/node/478966 | | InterSystems IRISによる水平方向のスケーラビリティ | IRISインスタンスを設定し、水平方向のスケーラビリティの実現 | https://jp.community.intersystems.com/node/477591 | | Raspberry Pi Raspberry で動作する InterSystems Iris Fhirserver が FHIRserver として動作 | Raspberry PI内部でIRISの動作 | https://jp.community.intersystems.com/node/516361 | | バーチャルIPアドレスを使用しないデータベースミラーリング | VIPによるミラーの設定 | https://jp.community.intersystems.com/node/493401 | | DockerによるApache Web Gateway | WebアプリケーションのSSLとWeb Gatewayの設定 | https://jp.community.intersystems.com/node/542181 | | IRISにおけるSAMLとの連携 | Webサービス向けSAML | https://community.intersystems.com/post/work-saml-iris | | SYSTEM.Encryption クラスの習得 | IRISによる暗号化・復号化 | https://jp.community.intersystems.com/node/523406 | ## Docker と Cloud 新しいアプリケーション・アーキテクチャは、コンテナ Docker と Cloud において動作し、弾力的なスケーラビリティ、インストール、設定、プロビジョニング時間の短縮、インフラの複雑性とコストの削減を実現することを目的としています。これらの記事を読んで、IRISをクラウド化する方法を学んでください。 | 名称 | 概要 | URL | | -------------------------------------------------------------------------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | Kubernetesにおけるミラーリングを使用しない高可用性IRISデプロイ | KubernetesによるIRISをクラウドクラスターで利用する | https://jp.community.intersystems.com/node/490971 | | Amazon Web Services (AWS)のためのInterSystems IRISリファレンス・アーキテクチャ | AWSでのIRIS | https://jp.community.intersystems.com/node/481326 | | Microsoft Azure Resource Manager (ARM)のInterSystems製リファレンス・アーキテクチャ | 安価なマシン(ARM machine)を使ったAzureでのIRIS | https://jp.community.intersystems.com/node/478971 | | Dockerfileと仲間たち、またはInterSystems IRISでのObjectScriptプロジェクトの実行と共同作業の方法 | Dockerプロジェクトにおける重要なファイルについて知ること | https://community.intersystems.com/post/dockerfile-and-friends-or-how-run-and-collaborate-objectscript-projects-intersystems-iris | | CloudFormationテンプレートを使用したAWS向けInterSystems IRISデプロイメントガイド | CloudFormationを使ったAWSで使うIRIS | https://jp.community.intersystems.com/node/486206 | | Google Cloud Platform(GCP) におけるInterSystems IRIS のリファレンス・アーキテクチャ | Google Cloudで使うIRIS | https://jp.community.intersystems.com/node/479806 | | InterSystems IRISでAWS Glueの使用 | IRISとAWS Glue(AWSのETLツール)の利用 | https://jp.community.intersystems.com/node/485971 | | AmazonのEKSとIRIS。高可用性とバックアップ | AWSによるHAで使うIRIS | https://jp.community.intersystems.com/node/501186 AWSによるHAでのIRIS | | コンテナでの InterSystems レポートの動かしてみる | Dockerに関するIRISのレポート | https://jp.community.intersystems.com/node/501656 | | InterSystems IRIS を Kubeless を使って FaaS モードで実行 | Kubernetesで使うIRIS | https://jp.community.intersystems.com/node/523446 | | InterSystems Kubernetes Operator Deep Dive ‐ Kubernetes Operatorの紹介 | Kubernetesで使うIRIS | https://community.intersystems.com/post/intersystems-kubernetes-operator-deep-dive-introduction-kubernetes-operators | | クラウドホストのスケーリングとInterSystems IRISの再構築 | AWS、Azure、またはGCPでのIRISのスケーリング | https://community.intersystems.com/post/scaling-cloud-hosts-and-reconfiguring-intersystems-iris | | Amazon EKSを用いたシンプルなIRISベースのWebアプリケーションのデプロイメント | AWSで使うIRIS | https://jp.community.intersystems.com/node/478961 | ## VSCode VSCodeは世界で最も使われているIDEの1つです。IRISはこのIDEをフルサポートしています。以下の記事をご覧ください。 | 名称 | 概要 | URL | | ----------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------ | | VSCode-ObjectScriptのGitHubでの使用 | Web Github VSCodeでIRISアプリの開発 | https://jp.community.intersystems.com/node/510736 | | IRISによるGitHubのコードスペース | GithubでIRISアプリの開発 | https://jp.community.intersystems.com/node/510736 | | VSCodeのヒントとコツ - SOAPウィザード | VSCodeにショートカットのオプションの作成 | https://community.intersystems.com/post/vscode-tips-tricks-soap-wizard | | VS Codeへの独自のスニペットの追加| スニペットの作成 | https://community.intersystems.com/post/adding-your-own-snippets-vs-code | ## SQL SQLは、リレーショナルデータベースを扱うのに最もよく使われる言語の1つです。これらの記事は、クエリの実行方法とデータの永続性を示しています。 | 名称 | 概要 | URL | | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | フリーテキスト検索:SQL開発者が隠しているテキストフィールドの検索方法*| インデックスの活用で高度な検索を促進 | https://jp.community.intersystems.com/node/479321 | | 日付範囲クエリのSQLパフォーマンスの向上 | 日付を使ったSQLクエリの実行 | https://jp.community.intersystems.com/node/479286 | | スタティックWHERE条件 | 永続的なクラ使うWhere | https://community.intersystems.com/post/static-where-conditions | | 2021.2 SQL機能スポットライト - ランタイムプランの選択 | ランタイムSQL実行プランの選択 | https://jp.community.intersystems.com/node/510746 | | 2020.1 の新機能:ユニバーサルクエリキャッシュ | SQL Cache | https://jp.community.intersystems.com/node/535211 | | マテリアライズド・ビュー | 永続的なクラスの中にビューの作成 | https://community.intersystems.com/post/materialized-views | | SQLを使ったデバッグのコツ | SQLコマンドのデバッグ | https://community.intersystems.com/post/debugging-trick-sql | | ClassQueries()をテーブルとして使用 | ビューの作成 | https://community.intersystems.com/post/using-classqueries-tables | | M:Nの関係 | N対Nの関係性のマッピング | https://community.intersystems.com/post/mn-relationship | | IRISでCOVIDにたいしてのAWS S3データをSQLテーブルとして読み込む | AWS S3からCSVデータをIRISのテーブルに取得 | https://community.intersystems.com/post/reading-aws-s3-data-covid-sql-table-iris | | 知っておくと便利なクエリパフォーマンスのコツ - Tune Table | SQLチューニング | https://jp.community.intersystems.com/node/535211 | | データストレージ:開発がうまくいくために知っておくべき情報 | より高いパフォーマンスを得るために、データストレージ部を永続的なクラスで構成する | https://community.intersystems.com/post/data-storage-information-you-must-know-make-good-decisions-when-developing | | 日付範囲クエリのSQLパフォーマンスを改善する vol2 | SQLクエリの日付に関するチューニング | https://jp.community.intersystems.com/node/479291 | | スクロール可能なResultSetのページネーションのサンプル | SQLの結果をページ分割する(コメントも参照) | https://community.intersystems.com/post/scrollable-resultset-pagination-sample | | 1日目 InterSystems ObjectsとSQLを用いた開発 | InterSystems IRISへのSQLに関するコンセプト | https://community.intersystems.com/post/day-1-developing-intersystems-objects-and-sql | | SQLgatewayを利用したDBマイグレーション | PostgreSQL、MySQL、その他のデータベースからIRISへのマイグレーション | https://jp.community.intersystems.com/node/518861 | | InterSystems IRIS の既存のテーブルに CSV のインポート | CSVからSQLテーブルへのインポート | https://community.intersystems.com/post/importing-csv-existing-table-intersystems-iris | | データベースの4つのAPI | SQLの API | https://community.intersystems.com/post/four-database-apis | | アトミックでない属性のインデックス作成 | 高度なインデックスのオプションの作成 | https://jp.community.intersystems.com/node/486236 | | インデックスについて | インデックス作成の基礎知識 | https://jp.community.intersystems.com/node/492126 | | Dynamic SQLからDynamic Objectへ | DynamicSQLの使用 | https://community.intersystems.com/post/dynamic-sql-dynamic-object | | データ移行ツール - その1:PostgresからIRISへ | 一般的なデータベースからIRISデータベースへの移行方法を紹介する連載記事 | https://jp.community.intersystems.com/node/518871 | ## アナリティクスとビジネスインテリジェンス(BI) アナリティクスとBIは、グラフ、ダッシュボード、サマリー、詳細表などのデータ分析、およびアナリスト・ユーザーによるナビゲーションとデータ探索に基づいて意思決定を行うことを可能にします。ここでは、IRISを使った分析アプリケーションの構築方法を紹介します。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------ | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | InterSystems IRISのCOVID-19アナリティクス | InterSystems IRISにおけるCOVID-19アナリティクス | https://community.intersystems.com/post/covid-19-analytics-intersystems-iris | | DeepSeeトラブルシューティングガイド | 不具合修正 | https://jp.community.intersystems.com/node/542206 | | AnalyzeThis - InterSystems BIへのクイックスタート | InterSystems BIへのクイックスタート | https://community.intersystems.com/post/analyzethis-%E2%80%93-quick-start-intersystems-bi | | InterSystems IRIS用のPower BIコネクタ パート1 | Power BIでIRISのデータの利用 | https://jp.community.intersystems.com/node/482606 | | DeepSee でのポートレットの作成 | IRIS BIによるアナリティクスポートレット | https://community.intersystems.com/post/creating-portlets-deepsee | | Game Of Throne Analytics、またはアリア スタークリストの長さ | アナリティクスのサンプル | https://community.intersystems.com/post/game-throne-analytics-or-how-long-aryas-stark-list | | DeepSee Web。AngularJSによるInterSystems Analyticsのビジュアライゼーション。第 1 部| Angularを使用するWebダッシュボード | https://community.intersystems.com/post/deepsee-web-intersystems-analytics-visualization-angularjs-part-1 | | IRIS でアナリティクスソリューションを構築する | IRISでアナリティクスを行うための主なオプションの紹介 | https://jp.community.intersystems.com/node/501571 |   ## グローバル IRIS では、SQL、クラス、JSON ドキュメント、BI キューブ、その他のカスタム形式など、データを柔軟に保存および取得するための重要なメカニズムとして、グローバルが使用されています。以下の記事で、その方法を垣間見てください: | 名称 | 概要 | URL | | -------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------- | | グローバルをクラスにマッピングする技術 :1 / 3 | グローバルの SQL テーブルおよびオブジェクトへのマッピング | https://jp.community.intersystems.com/node/486176 | | グローバルは、データ管理の魔法の剣。第1回 | グローバルに関する基礎知識 | https://jp.community.intersystems.com/node/476486 | | GlobalToJSON-embeddedPython-pure | グローバルをJSONへの書き出し | https://community.intersystems.com/post/globaltojson-embeddedpython-pure | | InterSystems IRIS のグローバルを使ったトランザクション | グローバルパーシスタンスのトランザクション管理 | https://jp.community.intersystems.com/node/486476 | | グローバルによる マインドマップの保存 | グローバルを使ってマインドマップデータの永続化 | https://jp.community.intersystems.com/node/516226 | ## セキュリティ どのようなアプリケーションでも、セキュリティを確保することは非常に重要です。セキュリティは、アクセスや承認の管理、トランザクションの追跡と監査、保存および転送されるコンテンツの暗号化、感性的なリソースの保護を保証するための正しい設定パラメータに関連しています。これらの記事を読んで、セキュリティを確立する方法について理解を深めてください。 | 名称 | 概要 | URL | | ---------------------------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | InterSystems IRIS Open Authorization Framework (OAuth 2.0) の実装 - 第1回 | OAuthの使用 | https://jp.community.intersystems.com/node/478821 | | Webのデバッグ | CSPおよびRESTアプリのデバッグ | https://jp.community.intersystems.com/node/501166 | | InterSystems IRIS のクラスクエリ | 永続クラス内部でのSQL Queryの定義 | https://jp.community.intersystems.com/node/483716 | | TLS/SSLでOSの証明書ストアの使用 | SSLを行うためにOSの証明書の使用 | https://community.intersystems.com/post/using-os-certificate-store-tlsssl | | インテグリティチェック :スピードアップまたはスピードダウン | インテグリティの確保 | https://community.intersystems.com/post/integrity-check-speeding-it-or-slowing-it-down | | データ変更の追跡 - 監査ログ - 1 / 2 | 監査データの保存 | https://jp.community.intersystems.com/node/483691 | | TLS/SSL/HTTPS による管理ポータル(プライベート Web サーバー)の運用 | IRIS Web サーバーへの SSL の設定 | https://community.intersystems.com/post/running-management-portal-private-web-server-over-tlssslhttps | | OAuth認証とInterSystems IRIS:信頼プロトコルのテイム化 | OAuthの使用 | https://community.intersystems.com/post/oauth-https://jp.community.intersystems.com/node/493421 | | SOAP(Web)サービスでのOauth2の利用について | SOAPサービスにおけるOauthの設定 | https://jp.community.intersystems.com/node/483696 | | DeepSee: セキュリティの設定 - 1/5 | IRIS BIにおけるセキュリティ | https://community.intersystems.com/post/deepsee-setting-security-part-1-5 | | システムのセキュリティレベルの変更について | デフォルトでセキュリティ | https://community.intersystems.com/post/changes-security-level-system | ## DevOps DevOpsとは、ソースコードの開発(Dev)から本番運用(Ops)への高速かつ高品質な移行を自動化することを可能にするプラクティスやツールを採用する方法です。IRISでその方法をご覧ください。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | GitLabを使ったInterSystemsソリューションの継続的デリバリー - 第1回:Git | GitLabによる継続的デリバリー | https://jp.community.intersystems.com/node/476396 | | InterSystems ObjectScripts パッケージ・マネージャの紹介 | ZPMを使用して、アプリケーション内のサードパーティパッケージを設定およびインストール | https://jp.community.intersystems.com/node/486186 | | ZPMshow - 疲れた指のためのヘルパー | ZPM - IRISパッケージマネージャの使用方法 | https://community.intersystems.com/post/zpmshow-helper-tired-fingers | | プログラムによるミラーのセットアップ方法 | 新しいミラーの作成を自動化する | https://jp.community.intersystems.com/node/516091 | | ObjectScript パッケージマネージャにおけるユニットテストとテストカバレッジ | ObjectScriptのコード品質のためのUnit Testsの作成 | https://jp.community.intersystems.com/node/516111 | | DockerとMergeCPFを使ったシャードクラスターの展開 | cpfファイルによる設定の自動化 | https://community.intersystems.com/post/deploying-sharded-cluster-docker-and-mergecpf | | Caché ObjectScript クイックリファレンス | ObjectScriptリファレンスpdfドキュメント | https://community.intersystems.com/post/cach%C3%A9-objectscript-quick-reference | | ZPMモジュールの解剖学:InterSystems Solution のパッケージング | ZPMを使用してデプロイメントの自動化 | https://jp.community.intersystems.com/node/487071 | | IRISコンテナへのVSCodeの追加 | VSCodeをdockerインスタンスに埋め込む | https://community.intersystems.com/post/adding-vscode-your-iris-container | | InterSystems IRIS用の新しいデータベース、ネームスペース、およびWebアプリケーションをプログラムによって作成する方法 | データベースとネームスペースの作成の自動化 | https://community.intersystems.com/post/how-create-new-database-namespace-and-web-application-intersystems-iris-programmatically | | ユニットテスト: ObjectScript コードの品質 | ユニットテストによる品質保証 | https://community.intersystems.com/post/unit-tests-quality-your-objectscript-code | | インターシステムズ開発者コミュニティのDockerイメージ | Dockerコミュニティイメージ | https://community.intersystems.com/post/some-intersystems-developer-community-docker-images | ## インターオペラビリティ IRISは、強力なデータおよびアプリケーションのインタラクティブなバスを備えています。以下の記事でその使い方をご覧ください。 | 名称 | 概要 | URL | | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | EnsembleからTelegramでアラートの送信 | テレグラムにデータを送信するためのプロダクション | https://community.intersystems.com/post/sending-alerts-ensemble-telegram | | [初めてのInterSystems IRIS] インターオペラビリティを使ってみよう | ビジネスサービス、オペレーション、プロセス、プロダクションの作成 | https://jp.community.intersystems.com/node/483021 | | Embedded PythonによるInterSystems IRISのインターオペラビリティー | Pythonによるビジネスサービス、オペレーション、プロセス、プロダクションの作成 | https://jp.community.intersystems.com/node/518846 | | Ensemble / Interoperabilityトレーニングコース | プロダクションの作り方を学ぶのに最適なサンプル | https://community.intersystems.com/post/ensemble-interoperability-training-course | | プログラムによるインターオペラビリティーのサンプル | PythonまたはObjectScriptを使用したプログラムによるプロダクション | https://jp.community.intersystems.com/node/521511 | | フォルダ内のファイルのリスティング | フォルダー内のファイルをリスト化する | https://community.intersystems.com/post/listing-files-folder | | .Net/Java Gatewayのコンテナ化(またはKafka統合のデモ) | Javaまたは.Net Native APIを使用したKafkaサポート | https://jp.community.intersystems.com/node/542191 | | PEXを使用した.NETまたはJavaでのIRIS統合の実装 | PEXによるJavaまたは.Netを使ったプロダクションの作成 | https://community.intersystems.com/post/implementing-iris-integrations-net-or-java-using-pex | | Java Business HostからPEXへの移行 | PEXの使用 | https://jp.community.intersystems.com/node/486231 | | Tesseract OCRとJava Gatewayの使用について | Java PEXの使用 | https://community.intersystems.com/post/using-tesseract-ocr-and-java-gateway | | PEXのビジネスオペレーションを作成について | Create Java PEX Business Operation | https://community.intersystems.com/post/creating-pex-business-operation | | OCRとNLPを統合したInterSystems IRIS | Java PEX のサンプル | https://community.intersystems.com/post/ocr-and-nlp-together-intersystems-iris | | HTTP Adapterを使用したカスタムインターオペラビリティビジネスサービスの作成 | ビジネスサービスの作成 | https://community.intersystems.com/post/creating-custom-interoperability-business-service-using-http-adapter | ## Native API IRISは、市場で最も使用されているプログラミング言語(Java、Javascript/NodeJS、.Net、C++、Python)を使用することに前向きです。これを実現するために、これらの言語ごとにNative APIを使用しています。以下の記事をご覧ください。 | 名称 | 概要 | URL | | --------------------------------------------------------------------- | --------------------------------------- | ----------------------------------------------------------------------------------------------- | | Docker Micro ServerとしてIRIS Native APIを使用したWebSocket Client JS | IRISとNodeJSを使ってWebSocketを行う | https://jp.community.intersystems.com/node/507846 | | ObjectScript用IRIS Native API | Native APIの使用 | https://community.intersystems.com/post/iris-native-api-objectscript | | Node.jsでのZPMの使用 | Node.jsプロジェクトでのZPMの使用 | https://jp.community.intersystems.com/node/507866 | | テキストファイルからPDFファイルの作成 | PDFファイルの生成用Java Native API | https://community.intersystems.com/post/creating-pdf-text-file | | InterSystems IRISを使った開発を1分以内に始める方法 | IRISを使った開発の開始 | https://community.intersystems.com/post/how-start-development-intersystems-iris-less-minute | | Python + IRIS Globals を使ったブログの作成 | Python Native API用ブログ | https://jp.community.intersystems.com/node/501856 |        
お知らせ
Mihoko Iijima · 2023年4月4日

テクノロジーボーナス詳細:InterSystems IRIS Cloud SQL and IntegratedML コンテスト 2023

開発者の皆さん、こんにちは。 技術文書ライティングコンテストの受賞者が発表されたばかりですが、次のコンテスト:InterSystems IRIS Cloud SQL and IntegratedML コンテスト 2023 のテクノロジーボーナス詳細が決定しましたのでお知らせします📣 IntegratedML の利用 オンラインデモ コミュニティに記事を投稿する コミュニティに2つ目の記事を投稿する YouTubeにビデオを公開する はじめてチャレンジされた方 InterSystems Idea 内 Community Opportunityの実装 獲得ポイントについて詳細は、以下ご参照ください。 IntegratedML の利用 - 5 points IRIS Cloud SQL の IntegratedML SQL エクステンションを使用した場合、5ポイント獲得できます。 オンラインデモの公開 - 2 points オンラインデモとしてアプリケーションをクラウドにプロビジョニングすると、2ポイント獲得できます。開発環境テンプレートやその他のデプロイメントオプションを使用することができます。例サンプルアプリケーションの使用方法についてはビデオをご参照ください。 コミュニティに記事を投稿する - 2 points コミュニティに応募したアプリケーションの概要を説明する記事を投稿すると2ポイントを獲得できます。異なる言語への翻訳も含まれます。 コミュニティに2つ目の記事を投稿する - 1 point 2つ目の記事を投稿する、または投稿したアプリケーション概要の翻訳記事を投稿することで、さらボーナスポイントを獲得できます。(3記事以降はポイントが加算されません。) YouTubeにビデオを公開する - 3 points 開発した作品の動画を作成し、YouTube に掲載した場合、3ポイント獲得できます。 例)過去投稿されたビデオ 初めてチャレンジされた方 - 3 points InterSystems Open Exhangeコンテストに初めて参加された場合、3ポイント獲得できます! InterSystems Idea の Community Oppotunity の実装 - 3 points InterSystems Ideaポータルに投稿されているCommunity Opportunityのアイデアを開発ツールとして実装された場合、3ポイント獲得できます! ※ ボーナスポイントについては、変更される可能性もあります。予めご了承ください。 ぜひ、コンテストにチャレンジしてみてください!
記事
Tomohiro Iwamoto · 2020年6月5日

InterSystemsデータプラットフォームとパフォーマンス –パート3: CPUに注目

今週は、ハードウェアの主な”食品群” (^_^) の1つであるCPUに注目します。お客様から、次のようなシナリオについてのアドバイスを求められました。お客様の本番サーバーはサポート終了に近づいており、ハードウェアを交換する時期が来ています。 また、仮想化によってサーバーを一元的に管理できるようにし、ベアメタルか仮想化によりキャパシティを適正化したいとも考えています。 今日はCPUに焦点を当てますが、後日の記事では、メモリやIOといったほかの主要食品群を適正化するアプローチについて説明したいと思います。 では、質問を整理しましょう。 5年前のプロセッサをもとに作られたアプリケーション要件を今日のプロセッサに変換するには? 現在ではどのプロセッサが適しているのか? 仮想化はCPUキャパシティプランニングにどのような影響を及ぼすのか? 2017年6月追記: VMware CPUに関する考慮事項と計画の詳細、および一般的な質問と問題の詳細については、「大規模データベースの仮想化 - VMware CPUのキャパシティ計画」の記事も参照してください。 このシリーズの他の記事のリストはこちら spec.orgのベンチマークを使ったCPUパフォーマンスの比較 InterSystemsデータプラットフォーム(Caché、Ensemble、HealthShare)を使って構築されたアプリケーションにおいて、異なる種類のプロセッサのCPU使用率を解釈する際に、信頼できる大雑把な計算としてSPECintベンチマークを使用してプロセッサを比較できます。 http://www.spec.org のWebサイトには、ハードウェアベンダーが標準的に実施した信頼性の高いベンチマークの結果が掲載されています。 具体的に言うと、SPECintは、プロセッサを同じベンダーのほかのプロセッサモデルや異なるベンダー(Dell、HP、Lenovo、およびIntel、AMD、IBM POWER、SPARC)のプロセッサと比較する方法です。 ハードウェアをアップグレードする場合に、またはアプリケーションをさまざまな顧客ハードウェアに展開して、Intel Xeon E5-2680など選択したプロセッサのCPUコア当たりのピークトランザクションといったサイジングメトリックのベースラインを設定する必要がある場合に、SPECintを使って、アプリケーションに期待されるCPU要件を理解することができます。 SPECintのWebサイトではいくつかのベンチマークが使用されていますが、Cachéでは SPECint_rate_base2006 の結果が最適であり、長年にわたって顧客データと独自のベンチマークでそのことが確認されています。 この記事の例として、Intel Xeon 5570プロセッサを実行する顧客のDell PowerEdgeサーバーとIntel Xeon E5-2680 V3プロセッサを実行する最新のDellサーバーを比較してみましょう。 Intel Xeon V4サーバープロセッサが一般に利用できるようになったときにも(本記事を執筆した2016年初期時点で近日発売予定)、同じ方法を適用できます 例: プロセッサの比較 spec.orgデータベースでプロセッサの SPECint2006_Rates を検索します。E5-2680 V3 などのプロセッサ名を検索し、対象サーバーの製造会社とモデル(Dell R730など)がわかっていればその名前で、そうでない場合は一般的なベンダーを使って検索結果を絞り込みます。私は、一般的なサーバーとしてDellやHPのモデルが優れたベースラインだと思っていますが、異なるベンダーのハードウェアに使われるプロセッサには大した差はありません。 この記事の最後に、spec.orgのWebサイトを使って結果を検索する例を段階的に説明します… spec.orgを検索して、次のような既存のサーバーと可能性のある新しいサーバーを見つけたとします。 Existing: Dell PowerEdge R710 with Xeon 5570 2.93 GHz: 8 cores, 2 chips, 4 cores/chip, 2 threads/core: SPECint_rate_base2006 = 251 New: PowerEdge R730 with Intel Xeon E5-2680 v3, 2.50 GHz: 24 cores, 2 chips, 12 cores/chip, 2 threads/core: SPECint_rate_base2006 = 1030 当然のことながら、新しい方の24コアサーバーでは、クロック速度が遅いにも関わらず、古い8コアサーバーのSPECint_rate_base2006ベンチマークスループットが4倍以上増加しています。 この例は、共に複数のプロセッサソケットが搭載された2プロセッササーバーであることに注意してください。 CachéにSPECint_rate_base2006を使用する理由 spec.orgのWebサイトにはさまざまなベンチマークが説明されていますが、要約すると、SPECint_rate2006 ベンチマークは完全なシステムレベルのベンチマークで、すべてのCPUでハイパースレッディングがサポートされています。 特定のSPECint_rate2006ベンチ―マークでは、baseとpeakの2つのメトリックが報告されています。 ベース(base)は保守的なベンチマークで、ピーク(peak)は積極的なベンチマークです。 キャパシティ計画では、SPECint_rate_base2006の結果を使用してください。 SPECint_rate_base2006の4倍とは、ユーザーまたはトランザクションの容量が4倍ということですか? 24個のコアをすべてを使用した場合、アプリケーションのスループットは古いサーバーの能力の4倍に拡張される可能性はありますが、 この幅はいくつかの要因によって異なってきます。 SPECintを使用すれば、可能性のあるサイジングとスループットについておおよその見当をつけることはできますが、注意点がいくつかあります。 SPECintでは、上記の例にある2つのサーバーの適切な比較を提供しますが、E5-2680 V3サーバーのピーク時の同時ユーザーまたはピーク時のトランザクションスループットにおけるキャパシティが古いXeon 5570ベースサーバーと比べて75%増になるという保証はありません。 “食品群”のほかのハードウェアコンポーネントがアップグレードされるかどうかなど、ほかの要因もかかわってきます。たとえば、スループットの増加に対応できる新しいストレージや既存のストレージは存在するのかといったことです(ストレージについては後程詳細に説明します)。 Cachéをベンチマークし、顧客のパフォーマンスデータを調査した私の経験では、コンピューターのリソース(CPUコア)を追加するにつれ、Cachéは単一サーバーで非常に高いスループットにリニアスケーリングすることができます。さらに年ごとのCaché自体の改善による恩恵もあります。 言い換えると、最大アプリケーションスループットのリニアスケーリングは、CPUコアが追加されるにつれ、アプリケーショントランザクションやCaché に反映されるのがわかります。 ただし、アプリケーションのボトルネックが存在する場合、トランザクションレートが高くなるとそれが表面化し始め、リニアスケーリングに影響を与えてしまいます。 アプリケーションのボトルネックの症状を見分ける方法については、別の記事で説明します。 アプリケーションのパフォーマンス機能を改善する最善の方法に、Cachéを最新バージョンにアップグレードすることが挙げられます。 注意: Cachéでは、64個を超える論理コアを搭載したWindows 2008サーバーはサポートされていません。 たとえば、40コアサーバーのハイパースレッディングは無効にしておく必要があります。 Windows 2012では、最大640個の論理プロセッサがサポートされています。 Linuxには制限はありません。 アプリケーションに必要なコア数は? アプリケーションは多様であり、あなたのアプリケーションプロファイルはあなた自身にしかわからないことではありますが、サーバー(または仮想マシン)のCPUキャパシティプランニングを行う場合に私が共通して使用するアプローチは、入念なシステム監視活動です。ある「標準」プロセッサの特定の数のCPUコアが、1分当たり n 個のトランザクションというピーク時トランザクションレートを維持できることを確認する方法です。 これは、エピソードであっても、受診時対応やラボテストなど、あなたの環境で意味を成すものであっても構いません。 ポイントは、標準プロセッサのスループットは、現在のシステムまたは顧客のシステムで収集したメトリックに基づくものであるとうことです。 n 個のコアを備えた既知のプロセッサにおけるピーク時のCPUリソース使用率を知っているのであれば、SPECintを使用して、同じトランザクションレートでより新しいプロセッサまたは別のプロセッサに必要なコア数に変換することができます。 期待されるリニアスケーリングにおいて(2 ✕ 毎秒 n 個のトランザクション)はざっと2倍のコア数が必要ということになります。 プロセッサの選択 spec.org Webサイトで、もしくは選択したベンダー製品を見てわかるように、プロセッサの選択肢はたくさんあります。 この例のお客様はIntelで満足しているため、私が現在のIntelサーバーを推奨するとした場合、「値段に見合う価値」または「コアあたりの1ドルあたりのSPECint_rate_base2006」を探るのが1つの選択方法として挙げられます。 たとえば、次のグラフではDellコモディティサーバーについて表示しています。価格の有用性は人によって異なりますが、これは仮想化を使ったサーバーの統合には、価格と高いコア数にスイートスポットがあることを示しています。 このグラフは、Dell R730などの本番グレードのサーバーの価格を設定してから、別のプロセッサオプションを検討して作成したものです。 グラフのデータと顧客サイトにおける経験に基づくと、E5-2680 V3プロセッサは、コアあたりSPECintあたりの良好のパフォーマンスと価格ポイントを示しています。 また、ほかの要因も関係してきます。たとえば、仮想化デプロイメント向けのサーバープロセッサを検討している場合、プロセッサあたりのコア数を増やせばコストは高くなりますが、すべてのVMをサポートするために必要なサーバーホストの合計数が減るため、プロセッサソケット単位でライセンス提供されるソフトウェア(VMwareやオペレーティングシステムなど)を節約できるため、より安価に収めることができます。 また、高可用性(HA)要件に対するホスト数のバランスも考慮する必要があります。 VMwareとHAについては、後の記事でもう一度取り上げることにします。 たとえば、3つの24コアホストサーバーで構成されるVMware HAクラスタは、優れた可用性と大幅な処理能力(コア数)を提供するため、本番と非本番のVMの構成を柔軟に行うことができます。 VMware HAのサイズはN+1サーバーで決めることができるため、3つの24コアサーバーの場合、VMで使用できる合計コアは48コアに相当します。 コアとGHz―Cachéに最適なのは? CPUコアの速度と数のどちらかを選択する場合、次の点を考慮する必要があります。 - アプリケーションに多くのcache.exeスレッド/プロセスが必要な場合は、コア数を増やすことで、より多くのスレッド/プロセスをまったく同時に実行することができる。 - アプリケーションのプロセスが少ない場合は、それぞれができる限り高速に動作する方が望ましい。 別の見方をすると、たとえば同時ユーザーあたり1つ(以上)のプロセスといったように、多数のプロセスがあるクライアント/サーバーアプリケーションがある場合、利用できるコア数がさらに必要ということになります。 CSPを使ったブラウザベースのアプリケーションの場合、ユーザーが少数の非常にビジーなCSPサーバーにバンドルされるため、アプリケーションに必要なコア数は少ない代わりにより高速である方がメリットを得られる可能性があります。 理想的には、複数のcache.exeプロセスがそれらすべてのコアで同時に実行している場合にリソースの競合がないと仮定すれば、いずれのアプリケーションタイプにおいても、高速コアを多く使用する方がメリットが高いと言えます。 上で述べたように、CachéはリリースされるたびにCPUリソースの使用が改善されているため、最新バージョンのCachéにアプリケーションをアップグレードすることで、より多くのコアを利用できるようになります。 もう1つの重要な考慮事項は、仮想化を使用する際にホストあたりのコア数を最大化することです。 個別のVMのコア数が多くない場合でも、コア数を増やすことで可用性に必要なホスト数と、管理とコストを考慮してホスト数を最小限にすることのバランスを取る必要があります。 VMware仮想化とCPU VMware仮想化は、最新のサーバーとストレージコンポーネントと合わせて使用した場合に、Cachéでうまく機能します。 物理キャパシティプランニングと同じルールに従えば、適切に構成されたストレージ、ネットワーク、およびサーバーでVMware仮想化を実施しても、パフォーマンスに大きな影響はありません。 仮想化サポートは、より新しいモデルのIntel Xeonプロセッサではるかに優れています。具体的には、Intel Xeon 5500(Nehalem)以降、つまりIntel Xeon 5500、5600、7500、E7シリーズ、およびE5シリーズのみでの仮想化を検討する必要があります。 例: ハードウェアの更新 - 最低CPU要件の計算 上で述べたヒントと手順をまとめ、例として、8コア(2つの4コアXeon 5570プロセッサ)のDell PowerEdge R710で実行するワークロードのサーバーアップグレードを検討します。 顧客のプライマリ本番サーバーにおける現在のCPU使用率を図に表すと、1日の最も忙しい時間帯におけるサーバーのピークは、80%未満であることがわかります。 実行キューは圧迫されていません。 IOとアプリケーションにも問題がないので、人為的にCPUを抑制しているボトルネックはありません。 経験則: 予測される成長(ユーザー、トランザクションの増加など)を考慮し、ハードウェアの使用期間の終わりに最大80%のCPU使用率となるようにシステムをサイジングします。 こうすることで、予想外の成長、異常なイベント、または予定外のアクティビティの急増に対応することができます。 計算をわかりやすくするために、新しいハードウェアの使用期間中にスループットの増加がないと仮定します。 コアあたりのスケーリングは、(251/8):(1030/24)またはコアあたりのスループット26%増として計算できます。 8コアを使用する古いサーバーのCPU使用率80%は、ざっと、6コアを使用する新しいE5-2680 V3プロセッサのCPU 80%に相当します。 したがって、6つのコアで同じ数のトランザクションをサポートできます。 お客様にはいくつかの選択肢があり、最低CPU要件である6個のE5-2680 V3または同等のCPUコアを満たす新しいベアメタルサーバーを購入するか、本番ワークロードをVMwareで仮想化する計画を進めることができます。 サーバーの統合、柔軟性、および高可用性を活用するには、仮想化を選択するのが当然です。 CPU要件の算出が終われば、お客様は自信をもってVMware上の本番VMの適正化に進むことができます。 補足として、コア数の少ない最新のサーバーを購入するのは調達が困難であるかコストがかかるため、仮想化のオプションはさらに魅力的と言えます。 大幅な成長が見込まれる場合にも、仮想化が有利と言えます。 CPU要件は、最初の数年間の成長に基づいて計算できます。 継続的な監視により、必要に応じて必要となる前に必要なリソースのみを追加する、というのも有効な戦略といえるでしょう。 CPUと仮想化に関する考慮事項 これまで見てきたように、本番Cachéシステムのサイジングは実稼働の顧客サイトのベンチマークと測定に基づきます。 また、ベアメタルの監視からVMwareの仮想CPU(vCPU)要件をサイジングすることも有効です。 共有ストレージを使用した仮想化は、ベアメタルに比べてCPUオーバーヘッドがほとんど付加されません**。 本番システムには、ベアメタルのCPUコアと同じようにシステムのサイズを最初に決定する戦略を使用してください。 **注意: VMware VSANデプロイメントについては、VSAN処理用に10%のホストレベルCPUバッファを追加する必要があります。 仮想CPU割り当てについては、次の重要なルールを考慮する必要があります。 推奨: 余裕を持ったパフォーマンスに必要な数以上のvCPUを割り当てないようにしてください。 仮想マシンには大量のvCPUを割り当てることができますが、必要以上のvCPUを割り当てないことがベストプラクティスです。使用されていないvCPUを管理するために、(通常は小さい)パフォーマンスのオーバーヘッドが生じる可能性があります。 ここで重要なのは、システムを定期的に監視し、VMの適正化を確認することです。 推奨: 本番システム、特にデータベースサーバーは、初めに1つの物理CPU = 1つの仮想CPUでサイジングしてください。 本番サーバー、特にデータベースサーバーの使用率は非常に高くなることが予想されます。 6つの物理コアが必要な場合は、仮想コアも6つにサイジングしてください。 下のハイパースレッディングに関する注意も参照してください。 オーバーサブスクリプション オーバーサブスクリプションとは、物理ホストで利用可能なリソースよりも多くのリソースをそのホストがサポートする仮想サーバーに割り当てるさまざまな方法を指します。 一般に、仮想マシンの処理、メモリ、およびストレージリソースをオーバーサブスクライブすることで、サーバーを統合することができます。 ホストのオーバーサブスクリプションは、本番Cachéデータベース環境においても可能ですが、本番システムの初期サイジングでは、各vCPUが完全に専用のコアを持つと想定します。 たとえば、24コア(2✕12コア)E5-2680 V3サーバーを使用している場合は、統合に利用できるヘッドルームがあることを考慮しつつ、最大でも合計24vCPUキャパシティになるようにサイジングします。 この構成では、ホストレベルでハイパースレッディングが有効化されていることが前提です。 ピーク処理期間のアプリケーション、オペレーティングシステム、およびVMwareのパフォーマンスをしばらく監視したら、より高い統合が可能であるかどうかを判断することができます。 非本番VMを混在させている場合、合計CPUコアを計算するためのシステムサイジングにおいて私がよく使用する経験則は、非本番の物理対仮想CPUのサイズを最初は 2:1で設定することです。 ただし、これは確実に有効性が異なる領域であり、キャパシティプランニングには監視が必要となります。 疑問がある場合や経験がない場合は、ホストレベルか、ワークロードを理解するまでvSphere構成を使用して、本番VMと非本番VMを分けることができます。 VMware vRealize Operationsとほかのサードパーティツールには、経時的にシステムを監視し、統合を提案したり、VMにリソースを追加する必要があることを警告したりするファシリティがあります。 監視に利用できるツールについては、今後の記事で取り上げることにします。 結論として、お客様の例では、6 vCPUの本番VMでうまく機能することを確信できます。もちろん、IOやストレージなどのほかの主要”食品群”コンポーネントに十分な容量があると想定した上でです。 ハイパースレッディングとキャパシティプランニング 物理サーバーに関する既知のルールに基づいてVMのサイジングに着手するには、まず、ハイパースレッディングが有効化された状態でプロセッサあたりのターゲットに対する物理サーバーのCPU要件を計算し、それを単に変換します。 1つの物理CPU(ハイパースレッディングを含む)= 1つのvCPU(ハイパースレッディングを含む) ハイパースレッディングによってvCPUキャパシティが2倍になるという誤解が一般的にありますが、 これは、物理サーバーまたは論理vCPUには当てはまりません。 経験則として、ベアメタルサーバーでのハイパースレッディングは、ハイパースレッディングを使用しない同じサーバーよりもパフォーマンスキャパシティが増加する率は30%です。 同じ30%のルールは、仮想サーバーに適用されます。 ライセンスとvCPU vSphereでは、特定の数のソケットまたはコアを持つようにVMを構成できます。 たとえば、デュアルプロセッサVMを使用している場合、2つのCPUソケット、または2つのCPUコアを持つ単一のソケットに構成することができます。 VMが1つの物理ソケットで実行するのか2つの物理ソケットで実行するのかは、最終的にハイパーバイザーが決定するため、実行の観点からは、大きな違いはありません。 しかし、デュアルCPU VMに実際には2つのソケットではなく2つのコアがあると指定すると、Caché以外のソフトウェアライセンスに違いが生じる可能性があります。 最後に この記事では、SPECintベンチマークの結果を使用して、プロセッサをベンダー、サーバー、またはモデル間で比較する方法を説明しました。 また、仮想化の使用状況に関係なく、パフォーマンスとアーキテクチャに基づいて、キャパシティを計画する方法とプロセッサを選択する方法についても説明しました。 このトピックは非常に深く、洞窟のさらに奥へと進みがちですが、別の方向性を探りたい方は、ほかの記事と同様にコメントやご質問をお寄せください。 — SPECint_rate2006の結果の検索例 下の図は、SPECint_rate2006の結果の選択方法を示します。 検索画面で結果を絞り込みます。 Excelなどを使ってローカルで処理できるように、最大20 MBの .csvファイルにすべてのレコードをダンプすることもできます。 検索結果には、Dell R730が表示されます。 HTMLを選択すると、ベンチマークの全結果が表示されます。 この記事の例で使ったプロセッサを搭載するサーバーについて、次の結果を確認できます。 Dell PowerEdge R710 with 2.93 GHz: 8 cores, 2 chips, 4 cores/chip, 2 threads/core Xeon 5570: SPECint_rate_base2006 = 251 PowerEdge R730 (Intel Xeon E5-2680 v3, 2.50 GHz) 24 cores, 2 chips, 12 cores/chip, 2 threads/core Xeon E5-2680 v3: SPECint_rate_base2006 = 1030
記事
Tomohiro Iwamoto · 2020年6月5日

InterSystemsデータプラットフォームとパフォーマンス-パート4: メモリの確認 

この記事では、InterSystemsデータプラットフォームで実行するデータベースアプリケーションにおけるグローバルバッファ、ルーチンバッファ、gmheap、locksizeなどの共有メモリ要件のサイジングアプローチを説明し、サーバー構成時およびCachéアプリケーションの仮想化時に検討すべきパフォーマンスのヒントをいくつか紹介します。 これまでと同じように、Cachéについて話すときは、すべてのデータプラットフォーム(Ensemble、HealthShare、iKnow、Caché)を指しています。 このシリーズの他の記事のリストはこちら 最初にCachéを使い始めたころ、ほとんどの顧客オペレーティングシステムは32ビットで、Cachéアプリケーションのメモリは少なく、高価なものでした。 一般的に展開されていたIntelサーバーにはコアが数個しかなく、スケールアップするには、大型のサーバーを使用するか、ECPを使って水平方向にスケールアウトするしかありませんでした。 今では、基本製品グレードのサーバーでさえも、マルチプロセッサ、数10個のコア、TBにまで増設できる可能性も備わった128GBまたは256GBの最低メモリが搭載されています。 ほとんどのデータベースインストールでは、ECPは忘れられ、単一サーバー上でアプリケーショントランザクションレートを大幅に拡張できるようになりました。 Cachéの主要機能は、共有メモリでデータを使用する方法で、通常データベースキャッシュまたはグローバルバッファと呼ばれています。 手短に言えば、適切なサイズにして「より多くの」メモリをグローバルバッファに割り当てることができれば、通常はシステムパフォーマンスを向上させることができます。メモリ内のデータには、ディスク上のデータよりもはるかに高速にアクセスできるからです。 32ビットシステムが主流であったころ、「グローバルバッファにはどれくらいのメモリを割り当てればよいのか」という問いへの回答は簡単でした。「できるだけ多く!」という答えです。割り当てられる量も特に多かったわけではないため、OS要件、OSとCachéプロセスの数とサイズ、およびそれぞれが使用する実メモリを計算して残りを割り出し、できるだけ多くのグローバルバッファを割り当てるために、総計の計算が入念に行われていました。 潮流の変化 最新世代のサーバーでアプリケーションを実行しているのであれば、Cachéインスタンスに大量のメモリを割り当てることができ、「安価」なメモリが豊富にあるため自由放任な姿勢で臨むことができます。 ところが、潮の流れは再び変わり、現在では非常に大きなシステムを除き、デプロイされているほぼすべてのシステムが仮想化されています。 そのため、「モンスター」VMのメモリフットプリントは必要に応じて大きくできるにしろ、システムの適正化が再びスポットライトを浴びているのです。 サーバーの一元化を最大限に活用するには、利用可能なホストメモリを最大限に活用するキャパシティプランニングが必要となります。 メモリを使用するもの Cachéデータベースサーバーの主なメモリ消費者は、大まかに4つあります。 オペレーティングシステム(ファイルシステムキャッシュを含む)。 Caché以外のアプリケーション(インストールされている場合)。 Cachéプロセス。 Caché共有メモリ(グローバルバッファ、ルーチンバッファ、GMHEAPを含む)。 必要な物理メモリ量は、おおまかにリストの各項目の要件を単純に合計することで得られます。 上記はすべて実メモリを使用しますが、仮想メモリを使用することもできます。キャパシティプランニングでは、ページングが発生しない、もしくは最小化されるように、またはメモリをディスクから戻す必要のあるハードページフォールトの発生を緩和または失くすために、十分な物理メモリを得られるようにシステムのサイズを決定することが重要となります。 この記事では、Caché共有メモリのサイジングと、メモリパフォーマンスを最適化するためのいくつかの一般的な規則について説明します。 オペレーティングシステムとカーネルの要件はオペレーティングシステムごとに異なりますが、ほとんどの場合数GBです。 ファイルシステムキャッシュは多様で、リスト内の他の項目に割り当てられた後に使用可能な量となります。 Cachéは主にプロセスです。アプリケーションの実行中のオペレーティングシステムの統計には、Cacheプロセス(cacheまたはcache.exe)が表示されます。 そのため、アプリケーションのメモリ要件を確認するには、オペレーティングシステムのメトリックを調べるのが単純な方法と言えます。 たとえば、Linuxの vmstat または ps コマンド、またはWindows Process Exploreで、使用中の実メモリ量を合計し、増加とピーク時の要件を推定することができます。 一部のメトリックは共有メモリを含めた仮想メモリを表示するため、それに注意して実メモリ要件を収集してください。 グローバルバッファのサイジング - 単純な方法 高トランザクションデータベースの場合、キャパシティ計画の目標の1つは、アプリケーションのできる限り多くのワーキングセットがメモリ内に存在できるようにグローバルバッファを適正化することです。 こうすることで、読み取りIOPSが最小化されるため、全体的にアプリケーションのパフォーマンスが向上することになります。 また、オペレーティングシステムやCachéシステムといったほかのメモリ利用者がページアウトされることなく、ファイルシステムキャッシュのメモリが十分であるように、バランスを取ることも必要です。 このシリーズのパート2では、ディスクからの読み取りが過剰になると何が起きるかという例を紹介しました。あの場合は、大量の読み取りは、不良なレポートまたはクエリが原因で発生しましたが、グローバルバッファが小さすぎでアプリケーションがディスクからデータブロックを読み取り続けなければならない場合にも同じような効果が見られます。 補足として、ストレージの状況が常に変化していることにも注目する価値があります。ストレージはSSDの進歩により加速化が進んでいますが、メモリ内のデータが実行中のプロセスに近いことが依然として最適です。 もちろん、すべてのアプリケーションは異なるため、「有用性は異なる場合がある」と言っておくことが重要ですが、アプリケーションに合った共有メモリのキャパシティプランニングに着手するには、一般的な規則があります。 それに従った後で、特定の要件に合わせて調整することができます。 どこから始める? 残念ながら、その問いを魔法のように解決する答えはありません。しかし、前の記事で話したように、必要なピーク時トランザクションレートについて、ピーク処理時間のCPUの使用率が約80%になるようにシステムのCPUキャパシティを調整することが適当な実践と言えます。 アクティビティにおける短期的な増加または予期しない急増に備えて、20%のヘッドルームを残しておくということです。 たとえば、私がTrakCareシステムのサイジングを行っている場合は、顧客サイトのメトリックのベンチマークと確認から、トランザクションレートのCPU要件がわかっているため、Intelプロセッサベースのサーバーに対して幅広い経験則を使用できます。 経験則: 物理メモリのサイズは、CPUコア当たり n ギガバイトで決定する。 TrakCareデータベースサーバーの場合、n は8 GBです。 より規模の小さなWebサーバーの場合は、4 GBです。 経験則: Cachéグローバルバッファには、n%のメモリを割り当てる。 小規模から中規模のTrakCareシステムの場合、n%は60%で、オペレーティングシステム、ファイルシステムキャッシュ、およびCachéプロセスに40%を残します。 ファイルシステムキャッシュがたくさん必要な場合やプロセス数が多い場合には、50%などに変更できます。 または、大規模なシステムで非常に大量のメモリ構成を使用する場合は、%を高く指定します。 この経験則では、サーバー上のCachéインスタンスが1つしかないことを想定しています。 そのため、たとえばアプリケーションに10個のCPUコアが必要な場合、VMのメモリは80 GBで、グローバルバッファに48 GB、その他すべてに32 GBが割り当てられることになります。 メモリサイジングの規則は、物理システムまたは仮想システムに適用されるため、TrakCare VMにも同じ1 vCPU : 8 GBのメモリ比率が適用されます。 グローバルバッファの調整 サイジングがどれほど効果的かを確認するために注目すべきことがいくつかあります。 オペレーティングシステムツールを使用して、Caché以外の空きメモリを観察できます。 最良の計算に従ってセットアップし、経時的なメモリ使用量を確認します。常に空きメモリがある場合、グローバルバッファを増やすかVMを適正化してシステムを再構成することができます。 グローバルバッファの適切なサイジングのもう1つの重要な指標は、読み取りIOPSをできる限り低くすることです。Cachéキャッシュの効率性が高くなります。 mgstatを使用して、PhyRdsとRdRatioに対するさまざまなグローバルバッファサイズの影響を観察できます。これらのメトリックの見方の例はこのシリーズのパート2で説明しています。メモリにデータベースが丸ごと格納されていない限り、ディスクからの読み取りは必ず発生するため、この目的は、読み取りをできるだけ低く抑えるところにあります。 ハードウェアの”食品群”とそのバランスを正しく取ることに注意してください。グローバルバッファのメモリが多くなるほど読み取りIOPSは低くなりますが、システムが短時間でより多くの処理を実行できるようになるため、CPU使用率は増加する可能性があります。ただし、IOPSを低くすることはほぼ必ず良い結果を生み出し、顧客により速い応答時間を提供することができます。 物理メモリ構成への要件の適用については、以下のセクションを参照してください。 仮想サーバーの場合は、本番VMメモリ、特にCaché共有メモリをオーバーサブスクライブしないように計画してください。これについては以下でも説明します。 あなたのアプリケーションのスイートスポットは、CPUコア当たり8 GBの物理メモリですか? 私にはわかりませんが、あなたのアプリケーションでも同様の方法が使用できるかを確認してください。 コア当たり4 GBであろうが10 GBであろうが関係ありません。 グローバルバッファのサイズを適正化するにあたりほかの方法を見つけた方は、ぜひ下にコメントを残してください。 グローバルバッファの使用状況の監視 Cachéユーティリティ「^GLOBUFF」は、グローバルバッファがある時点で何をしているのかに関する統計を表示します。 たとえば、上位25をパーセントで表示するには、次のように記述します。 do display^GLOBUFF(25) これは、次のように出力されます。 Total buffers: 2560000 Buffers in use: 2559981 PPG buffers: 1121 (0.044%) Item Global Database Percentage (Count) 1 MyGlobal BUILD-MYDB1 29.283 (749651) 2 MyGlobal2 BUILD-MYDB2 23.925 (612478) 3 CacheTemp.xxData CACHETEMP 19.974 (511335) 4 RTx BUILD-MYDB2 10.364 (265309) 5 TMP.CachedObjectD CACHETEMP 2.268 (58073) 6 TMP CACHETEMP 2.152 (55102) 7 RFRED BUILD-RB 2.087 (53428) 8 PANOTFRED BUILD-MYDB2 1.993 (51024) 9 PAPi BUILD-MYDB2 1.770 (45310) 10 HIT BUILD-MYDB2 1.396 (35727) 11 AHOMER BUILD-MYDB1 1.287 (32946) 12 IN BUILD-DATA 0.803 (20550) 13 HIS BUILD-DATA 0.732 (18729) 14 FIRST BUILD-MYDB1 0.561 (14362) 15 GAMEi BUILD-DATA 0.264 (6748) 16 OF BUILD-DATA 0.161 (4111) 17 HISLast BUILD-FROGS 0.102 (2616) 18 %Season CACHE 0.101 (2588) 19 WooHoo BUILD-DATA 0.101 (2573) 20 BLAHi BUILD-GECKOS 0.091 (2329) 21 CTPCP BUILD-DATA 0.059 (1505) 22 BLAHi BUILD-DATA 0.049 (1259) 23 Unknown CACHETEMP 0.048 (1222) 24 COD BUILD-DATA 0.047 (1192) 25 TMP.CachedObjectI CACHETEMP 0.032 (808) これは、たとえばワーキングセットのどれくらいがメモリに保持されているのかを確認する場合など、さまざまな点で役立ちます。 このユーティリティが便利だと思った方は、役に立った理由を下のコメント欄でほかのコミュニティユーザーに共有してください。 ルーチンバッファのサイジング アプリケーションが実行しているコンパイルされたクラスなどのルーチンは、ルーチンバッファに格納されます。 ルーチンバッファの共有メモリをサイジングする目的は、すべてのルーチンコードをロードし、ルーチンバッファに常駐させることにあります。 グローバルバッファと同じように、ディスクからルーチンを読み取るのは高くつき、非効率です。 ルーチンバッファの最大サイズは1023 MBです。 ルーチンをキャッシュすることでパフォーマンスは確実に大幅に向上するため、原則として、必要以上のバッファを設定するとよいでしょう。 ルーチンバッファはさまざまなサイズで構成されています。 デフォルトでは、Cachéが各サイズのバッファ数を決定します。2016.1のインストール時のデフォルトは、4、16、および64 KBです。 さまざまなサイズに対するメモリの割り当てを変更することはできますが、キャパシティプランニングに着手するには、特別な変更理由がない限り、Cachéのデフォルトを使用することをお勧めします。 詳細については、Cachéドキュメンテーションを参照してください。『Caché Parameter File Reference(Cachéパラメータファイルリファレンス)』の場合は、付録「config」の「routines(ルーチン)」、『Caché System Administration Guide(Cachéシステム管理ガイド)』の場合は、「Configuring Caché(Cachéの構成)」の章にある「Memory and Startup Settings(メモリと起動の設定)」で説明されています。 アプリケーションが実行されると、ルーチンはディスクからロードされ、そのルーチンが入る最も小さなバッファに格納されます。 たとえば、ルーチンが3 KBの場合、理想的には4 KBのバッファに格納され、4 KBのバッファがない場合は、それより大きなバッファが使用されます。 32 KBより大きなルーチンの場合は、64 KBルーチンバッファが必要な数だけ使用されます。 ルーチンバッファの使用状況の確認 mgstatメトリック RouLas ルーチンバッファの大きさが十分であるかを理解するには、mgstatメトリックのRouLas(ルーチンのロードと保存)を使用する方法があります。 RouLasはディスクからのフェッチまたはディスクへの保存です。 ルーチンのロード/保存の数が多いと、パフォーマンスの問題が現れる場合があります。その場合は、ルーチンバッファを増やすことでパフォーマンスを改善でできます。 cstat ルーチンバッファを最大の1023 MBに増やしてもRouLasが高くなってしまう場合は、より詳細な調査を行うために、cstatコマンドを使ってどのルーチンがバッファ内にあり、どのくらいが使用されているのかを確認することができます。 ccontrol stat cache -R1 これを実行すると、ルーチンバッファとキャッシュ内のすべてのルーチンのリストを含む、ルーチンメトリックのリストが生成されます。 たとえば、デフォルトのCachéインストールの部分リストは、次のように生成されます。 Number of rtn buf: 4 KB-> 9600, 16 KB-> 7200, 64 KB-> 2400, gmaxrouvec (cache rtns/proc): 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, gmaxinitalrouvec: 4 KB-> 276, 16 KB-> 276, 64 KB-> 276, Dumping Routine Buffer Pool Currently Inuse hash buf size sys sfn inuse old type rcrc rtime rver rctentry rouname 22: 8937 4096 0 1 1 0 D 6adcb49e 56e34d34 53 dcc5d477 %CSP.UI.Portal.ECP.0 36: 9374 4096 0 1 1 0 M 5c384cae 56e34d88 13 908224b5 %SYSTEM.WorkMgr.1 37: 9375 4096 0 1 1 0 D a4d44485 56e34d88 22 91404e82 %SYSTEM.WorkMgr.0 44: 9455 4096 0 0 1 0 D 9976745d 56e34ca0 57 9699a880 SYS.Monitor.Health.x 2691:16802 16384 0 0 7 0 P da8d596f 56e34c80 27 383da785 START etc etc 上記の2行目の「rtns/proc」は、276個のルーチンがデフォルトの各バッファーサイズにキャッシュできることを示しています。 この情報を使用したルーチンバッファのサイジングには、アプリケーションを実行して、実行中のルーチンを cstat -R1で一覧表示する方法があります。 一覧表示した後、使用中のルーチンのサイズを計算します。たとえば、このリストをExcelに入力し、サイズ順に並べ替えて一体どのルーチンが使用中であるのかを確認できます。 各サイズのすべてのバッファを使用していない場合は、ルーチンバッファが十分に用意されていることになりますが、すべてを使用している場合は、ルーチンバッファを増やす必要があるか、各バケットサイズの数の構成をより積極的に行うことができます。 ロックテーブルのサイズ locksiz構成パラメータは、異なるプロセスがデータの特定の要素を同時に変更するのを防止する並行処理制御のロックを管理するために割り当てられるメモリのサイズ(バイト単位)です。 内部的には、メモリ内のロックテーブルには現在のロックと、それらのロックを保持するプロセスに関する情報が含まれています。 ロックの割り当てに使用されるメモリはGMHEAPから取得されるため、GMHEAPに存在する以上のメモリをロックに使用することはできません。 locksizのサイズを増やす場合は、下のGMHEAPセクションに記載された式に従って、GMHEAPを対応するサイズに増加してください。 アプリケーションによるロックテーブルの使用に関する情報は、システム管理ポータル(SMP)を使用して監視できます。また、APIを使うとより積極的に監視できます。 set x=##class(SYS.Lock).GetLockSpaceInfo() このAPIは、「空き領域、使用可能領域、使用中領域」の3つの値を返します。 適切な値を大まかに計算するには、「使用可能領域」と「使用中領域」を確認します(一部のロック領域はロック構造に予約されています)。 詳細については、Cachéドキュメンテーションを参照してください。 注意: locksizの設定を編集すると、変更内容はすくに反映されます。 GMHEAP GMHEAP(汎用メモリヒープ)構成パラメータは、Cachéの汎用メモリヒープのサイズ(キロバイト単位)として定義されています。 これが、ロックテーブル、NLSテーブル、およびPIDテーブルにも割り当てられる割当量です。 注意: GMHEAPを変更するには、Cachéを再起動する必要があります。 アプリケーションに合ったサイジングを行うには、APIを使ってGMHEAPの使用状況に関する情報を確認することができます。 %SYSTEM.Config.SharedMemoryHeap このAPIには、使用可能な汎用メモリヒープを取得する機能があり、構成用のGMHEAPパラメータを推奨することができます。 たとえば、DisplayUsageメソッドは、各システムコンポーネントが使用するすべてのメモリと使用可能なヒープメモリの量を表示します。 詳細については、Cachéドキュメンテーションを参照してください。 write $system.Config.SharedMemoryHeap.DisplayUsage() 任意の時点のGMHEAPの使用状況と推奨を取得するには、RecommendedSizeメソッドを使用できます。 ただし、システムのベースラインと推奨を得るには、これを何度も実行する必要があります。 write $system.Config.SharedMemoryHeap.RecommendedSize() 経験則: 繰り返しになりますが、アプリケーションの改善率はそれぞれに異なりますが、サイジングを始めるとすれば、次のいずれかから始めることができます。 (最小128MB) または (64 MB * コア数) または (2x locksiz) またはこれらの最大値。 GMHEAPは、ロックテーブルを含めたサイズにする必要があることに注意してください。 LargePages / HugePages LinuxでHugePagesを有効にするとパフォーマンスを大幅に改善できる理由について、Mark Bolinskyが素晴らしい記事を書いています。 危険! WindowsのLargePagesと共有メモリ Cachéは、すべてのプラットフォームとバージョンで共有メモリを使用しており、パフォーマンスを大幅に改善することができます。それが常に使用されるWindowsも例外ではありませんが、注意すべきWindows固有の問題がいくつかあります。 Cachéが起動すると、データベースキャッシュ(グローバルバッファ)、ルーチンキャッシュ(ルーチンバッファ)、共有メモリヒープ、ジャーナルバッファ、およびその他の制御構造に使用される単一の大きなチャンクの共有メモリが割り当てられます。 共有メモリの割り当てには、Cachéの起動時に、SmallPagesまたはLargePagesを使用することができます。 Windows 2008 R2以降では、CachéはデフォルトでLargePagesを使用するようになっていますが、それまでにシステムが長時間稼働していた場合はメモリが断片化しているため、Cachéの起動時にメモリを割り当てられず、代わりにSmallPaegsを使用して起動することがあります。 Cachéを予期せずにSmallPagesで起動してしまうと、構成で定義された量より少ない共有メモリでCachéが起動してしまう可能性があります。または起動に時間が掛かかったり、起動できなかったりすることもあります。個人的には、バックアップサーバーが長い間データベースサーバーとして使用されていないフェイルオーバークラスタを備えたサイトでこれが発生したのを見たことがあります。 ヒント: 緩和策として、オフラインのWindowsクラスタサーバーを定期的に再起動することができます。 また、Linuxを使用することもできます。 物理メモリ 物理メモリは、プロセッサの最適な構成によって決まります。 不適切なメモリ構成は、パフォーマンスに大きな影響を与えかねません。 Intelメモリ構成のベストプラクティス これはIntelプロセッサに限定される情報です。 ほかのプロセッサに適用されるルールについては、ベンダーにご確認ください。 最適なDIMMのパフォーマンスは以下のような要因にによって決定します。 DIMMの種類 DIMMのランク クロック速度 プロセッサとの位置関係(近い/遠い) メモリチャネル数 必要な冗長機能 たとえば、NehalemとWebmereのサーバー(Xeon 5500と5600)には、プロセッサあたり3つのメモリチャネルがあるため、メモリはプロセッサあたり3個を1セットとしてインストールする必要があります。 たとえばE5-2600といった現行のプロセッサの場合、プロセッサあたり4つのメモリチャネルがあるため、メモリはプロセッサあたり4個を1セットとしてインストールする必要があります。 メモリが3つまたは4つを1セットとしてインストールされていなかったり、メモリDIMMのサイズが異なっていたりなど、メモリ構成が不均衡である場合は、それにより23%のメモリパフォーマンス低下となる可能性があります。 Cachéの機能の1つはメモリデータ処理にあるため、メモリから最高のパフォーマンスを得ることが重要であることを忘れてはいけません。 また、最大帯域幅のサーバーは、メモリ速度が最速になるように構成する必要があることにも注意してください。 Xeonプロセッサの場合、最大メモリパフォーマンスは、チャネルあたり最大2個のDIMMのみでサポートされるため、CPUを2個備えた一般的なサーバーの最大メモリ構成は、CPU周波数とDIMMサイズ(8 GB、16 GBなど)といった要因によって決まります。 経験則: バランスの取れたプラットフォーム構成を使用します。各チャネルと各ソケットに、同じ数のDIMMを使用してください。 プラットフォーム全体でサイズ、速度、ランク数が同じDIMMを使用してください。 物理サーバーの場合、ホストサーバーの物理メモリの合計を、Intelプロセッサのベストプラクティスに従って、64 GB、128 GBなどの自然な区切りに切り上げます。 VMware仮想化に関する考慮事項 Cachéを仮想化する場合のガイドラインについては、今後別の記事で説明するつもりですが、 メモリ割り当てについては、以下の重要なルールを考慮する必要があります。 ルール: 本番システムにVMwareの予約メモリを設定すること。 前に説明したように、Cachéが起動すると、グローバルバッファ、ルーチンバッファ、GMHEAP、ジャーナルバッファ、そしてその他の制御構造で使用される単一の大きなチャンクの共有メモリが割り当てられます。 共有メモリのスワッピングは避けたいため、本番データベースVMの予約メモリを、少なくともCaché共有メモリにCachéプロセス、オペレーティングシステム、およびカーネルサービス用のメモリを加えたサイズに設定する必要があります。 適切かどうかわからない場合は、本番データベースVMの全メモリを予約してください。 原則として、本番サーバーと非本番サーバーを同じシステムに混在させる場合、非本番サーバーには予約メモリを設定しないでください。 非本番サーバーには、残っているメモリで対処してもらいましょう (^_−)☆ VMwareは、8個を超えるCPUを搭載したVMを「モンスターVM」と呼ぶことがよくあります。 高トランザクションのCachéデータベースサーバーは多くの場合、モンスターVMです。 モンスターVMに予約メモリを設定する場合には、ほかの考慮事項があります。たとえば、モンスターVMがメンテナンスにより移行される場合や高可用性によって再起動がトリガされた場合には、ターゲットホストサーバーに十分な空きメモリが必要となります。 これに対して計画するにも戦略がありますが、NUMAを最大限に活用する計画といった他のメモリ関連の考慮事項と合わせて、今後の記事で説明したいと思います。 最後に これは、メモリのキャパシティプランニングの開始部分であり、厄介な領域です。CPUのサイジングほど明確ではありません。 ご質問やご意見がございましたら、ぜひコメントを残してください。 この記事が投稿されるころ、私はグローバルサミット2016に向かっています。 今年このイベントに参加される方は、パフォーマンス関連のトピックで2つのプレゼンテーションを行いますので、ぜひご覧ください。また、開発者エリアで直接お会いしましょう。
記事
Tomohiro Iwamoto · 2020年6月5日

InterSystemsデータプラットフォームとパフォーマンス-パート5: SNMPによる監視 

前回の記事では、pButtonsを使って履歴パフォーマンスメトリックを収集する方法を説明しました。 すべてのデータプラットフォームインスタンス(Ensemble、Cachéなど)にはpButtonsがインストールされていることがわかっているため、私はpButtonsを使用する傾向にありますが、 Cachéパフォーマンスメトリックをリアルタイムで収集、処理、表示する方法はほかにもあり、単純な監視や、それよりもさらに重要な、より高度な運用分析とキャパシティプランニングに使用することができます。 データ収集の最も一般的な方法の1つは、SNMP(簡易ネットワーク管理プロトコル)を使用することです。 SNMPは、Cachéが管理・監視情報をさまざまな管理ツールに提供するための標準的な方法です。 Cachéのオンラインドキュメンテーションには、CachéとSNMP間のインターフェースに関する詳細が説明されています。 SNMPはCachéと「単純に連携」するはずですが、構成にはいくつかの技と罠があります。 私自身、はじめに何度も過ちを繰り返し、InterSystemsの同僚から助けを得ながらCachéをオペレーティングシステムのSNMPマスターエージェントにやっと接続できた経験から、皆さんが同じような困難を避けられるようにこの記事を書くことにしました。 この記事では、Red Hat Linuxで実行するCachéにおけるSNMPのセットアップと構成について説明します。ほかの *nixフレーバーでも同じ手順を使用できるはずです。 Linuxの場合はセットアップにもう少しコツが必要なので、Red Hatを使ってこの記事を書いています。WindowsのCachéは、自動的にDLLをインストールして標準のWindows SNMPサービスに接続するため、より簡単に構成できます。 サーバー側でSNMPのセットアップが完了したら、複数のツールを使用して監視を開始できます。 私は一般的なPRTGツールを使って監視を説明しようと思いますが、ほかにもたくさんのツールがあります。ここに示すのはリストの一部です。 CachéとEnsembleのMIBファイルは Cachéインストールディレクトリ/SNMP フォルダにあります。ファイルは ISC-CACHE.mib と ISC-ENSEMBLE.mib です。 このシリーズのこれまでの記事: パート1 - はじめの一歩。メトリックの収集。 パート2 - 収集したメトリックの確認。 パート3 - CPUに注目 パート4 - メモリの確認。 まずはここから始めましょう... まず、Cachéオンラインドキュメンテーションの「Monitoring Caché Using SNMP(SNMPによるCachéの監視)」を確認してください。 1. Cachéを構成する Caché オンラインドキュメンテーションの「Managing SNMP in Caché(CachéでのSNMPの管理)」セクションにある手順に従って、Caché監視サービスを有効化し、Caché SNMPサブエージェントがCachéの起動時に自動的に開始するように構成します。 OSのプロセスリストを確認するなどして、Cachéプロセスが実行していることを確認します。 ps -ef | grep SNMP root 1171 1097 0 02:26 pts/1 00:00:00 grep SNMP root 27833 1 0 00:34 pts/0 00:00:05 cache -s/db/trak/hs2015/mgr -cj -p33 JOB^SNMP これで、Cachéの構成は完了です! 2. オペレーティングシステムを構成する ここでは、もう少しやることがあります。 まず、snmpdデーモンがインストール済みで実行中であることを確認してください。 そうでない場合はsnmpdをインストールして開始します。 次ようにして、snmpdのステータスを確認します。 service snmpd status 次のようにして、snmpdを開始または停止します。 service snmpd start|stop snmpがインストールされていない場合は、OSの指示に従ってインストールする必要があります。次に例を示します。 yum -y install net-snmp net-snmp-utils 3. snmpdを構成する Cachéドキュメンテーションで説明されるとおり、Linuxシステムで最も重要なタスクは、システム上のSNMPマスターエージェントがAgent Extensibility(AgentX)プロトコルと互換性があり(Cachéはサブエージェントとして実行)、マスターがアクティブで標準のAgentX TCPポート705で待ち受け状態であることを確認することです。 私が壁にぶつかったのは、この部分でした。 snmp.confファイルで基本的なミスをしてしまったせいで、Caché SNMPサブエージェントがOSマスターエージェントと通信していませんでした。 次の /etc/snmp/snmp.conf サンプルファイルはagentXを開始してCachéとEnsembleのSNMP MIBにアクセスを提供するように構成されています。 次の構成があなたの組織のセキュリティポリシーを順守しているかどうかを確認する必要があります。 システムの設定が反映されるように、少なくとも次の行を編集する必要があります。 例えば、 syslocation "System_Location" の行を次のように変更します。 syslocation "Primary Server Room" また、少なくとも次の2行を編集します。 syscontact "Your Name" trapsink Caché_database_server_name_or_ip_address public 次と一致するように、既存の/etc/snmp/snmp.conf ファイルを編集するか置換します。 ############################################################################### # # snmpd.conf: # An example configuration file for configuring the NET-SNMP agent with Cache. # # This has been used successfully on Red Hat Enterprise Linux and running # the snmpd daemon in the foreground with the following command: # # /usr/sbin/snmpd -f -L -x TCP:localhost:705 -c./snmpd.conf # # You may want/need to change some of the information, especially the # IP address of the trap receiver of you expect to get traps. I've also seen # one case (on AIX) where we had to use the "-C" option on the snmpd command # line, to make sure we were getting the correct snmpd.conf file. # ############################################################################### ########################################################################### # SECTION: System Information Setup # # This section defines some of the information reported in # the "system" mib group in the mibII tree. # syslocation: The [typically physical] location of the system. # Note that setting this value here means that when trying to # perform an snmp SET operation to the sysLocation.0 variable will make # the agent return the "notWritable" error code. IE, including # this token in the snmpd.conf file will disable write access to # the variable. # arguments: location_string syslocation "System Location" # syscontact: The contact information for the administrator # Note that setting this value here means that when trying to # perform an snmp SET operation to the sysContact.0 variable will make # the agent return the "notWritable" error code. IE, including # this token in the snmpd.conf file will disable write access to # the variable. # arguments: contact_string syscontact "Your Name" # sysservices: The proper value for the sysServices object. # arguments: sysservices_number sysservices 76 ########################################################################### # SECTION: Agent Operating Mode # # This section defines how the agent will operate when it # is running. # master: Should the agent operate as a master agent or not. # Currently, the only supported master agent type for this token # is "agentx". # # arguments: (on|yes|agentx|all|off|no) master agentx agentXSocket tcp:localhost:705 ########################################################################### # SECTION: Trap Destinations # # Here we define who the agent will send traps to. # trapsink: A SNMPv1 trap receiver # arguments: host [community] [portnum] trapsink Caché_database_server_name_or_ip_address public ############################################################################### # Access Control ############################################################################### # As shipped, the snmpd demon will only respond to queries on the # system mib group until this file is replaced or modified for # security purposes. Examples are shown below about how to increase the # level of access. # # By far, the most common question I get about the agent is "why won't # it work?", when really it should be "how do I configure the agent to # allow me to access it?" # # By default, the agent responds to the "public" community for read # only access, if run out of the box without any configuration file in # place. The following examples show you other ways of configuring # the agent so that you can change the community names, and give # yourself write access to the mib tree as well. # # For more information, read the FAQ as well as the snmpd.conf(5) # manual page. # #### # First, map the community name "public" into a "security name" # sec.name source community com2sec notConfigUser default public #### # Second, map the security name into a group name: # groupName securityModel securityName group notConfigGroup v1 notConfigUser group notConfigGroup v2c notConfigUser #### # Third, create a view for us to let the group have rights to: # Make at least snmpwalk -v 1 localhost -c public system fast again. # name incl/excl subtree mask(optional) # access to 'internet' subtree view systemview included .1.3.6.1 # access to Cache MIBs Caché and Ensemble view systemview included .1.3.6.1.4.1.16563.1 view systemview included .1.3.6.1.4.1.16563.2 #### # Finally, grant the group read-only access to the systemview view. # group context sec.model sec.level prefix read write notif access notConfigGroup "" any noauth exact systemview none none /etc/snmp/snmp.confファイルの編集が完了したら、snmpdデーモンを再起動します。 service snmpd restart snmpdのステータスを確認します。AgentXが開始されていることに注意してください。ステータス行に「Turning on AgentX master support」が表示されます。 h-4.2# service snmpd restart Redirecting to /bin/systemctl restart snmpd.service sh-4.2# service snmpd status Redirecting to /bin/systemctl status snmpd.service ● snmpd.service - Simple Network Management Protocol (SNMP) Daemon. Loaded: loaded (/usr/lib/systemd/system/snmpd.service; disabled; vendor preset: disabled) Active: active (running) since Wed 2016-04-27 00:31:36 EDT; 7s ago Main PID: 27820 (snmpd) CGroup: /system.slice/snmpd.service └─27820 /usr/sbin/snmpd -LS0-6d -f Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Starting Simple Network Management Protocol (SNMP) Daemon.... Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: Turning on AgentX master support. Apr 27 00:31:36 vsan-tc-db2.iscinternal.com snmpd[27820]: NET-SNMP version 5.7.2 Apr 27 00:31:36 vsan-tc-db2.iscinternal.com systemd[1]: Started Simple Network Management Protocol (SNMP) Daemon.. sh-4.2# snmpdを再起動したら、^SNMPルーチンを使用してCaché SNMPサブエージェントを再起動する必要があります。 %SYS>do stop^SNMP() %SYS>do start^SNMP(705,20) オペレーティングシステムのsnmpdデーモンとCachéサブエージェントが実行しており、アクセスできるようになっているはずです。 4. MIBアクセスを検証する MIBアクセスは、コマンドラインで以下のコマンドを使って確認できます。snmpgetは、単一の値を返します。 snmpget -mAll -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1.5.5.72.50.48.49.53 SNMPv2-SMI::enterprises.16563.1.1.1.1.5.5.72.50.48.49.53 = STRING: "Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT" そして、snmpwalkは、MIBツリーまたはブランチを「ウォーク」します。 snmpwalk -m ALL -v 2c -c public vsan-tc-db2 .1.3.6.1.4.1.16563.1.1.1.1 SNMPv2-SMI::enterprises.16563.1.1.1.1.2.5.72.50.48.49.53 = STRING: "H2015" SNMPv2-SMI::enterprises.16563.1.1.1.1.3.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/cache.cpf" SNMPv2-SMI::enterprises.16563.1.1.1.1.4.5.72.50.48.49.53 = STRING: "/db/trak/hs2015/mgr/" etc etc また、システムデータの表示には、さまざまなウィンドウと *nixクライアントを使用できます。 私は無料のiReasoning MIB Browserを使用しています。 MIBの構造を認識させるために、ISC-CACHE.MIBファイルをクライアントにロードする必要があります。 次の画像は、OS X上のiReasoning MIB Browserをキャプチャしたものです。 監視ツールに含める これが、実装に大きな違いを生じる可能性のあるところです。 監視ツールや分析ツールの選択は、あなたにお任せすることにします。 システムの監視と管理に使用するツールとそれから得られる価値について、コメント欄で詳しくお聞かせください。 他のコミュニティメンバーにとっても非常に役立つと思います。 次は、一般的に使用されているPRTG Network Monitorのスクリーンショットで、Cachéメトリックが表示されています。 CachéメトリックをPRTGに含める手順はほかのツールと同じです。 ワークフローの例 - 監視ツールをCaché MIBに追加する。 ステップ 1. オペレーティングシステムのMIBに接続できることを確認します。 ヒントは、Cachéではなく、オペレーティングシステムに対してトラブルシューティングを行うということです。 監視ツールは一般的なオペレーティングシステムのMIBをすでに認識しており、あらかじめ構成されている可能性が高いため、ベンダーやほかのユーザーから支援を得る方が簡単かもしれません。 選択した監視ツールによっては、SNMP「モジュール」または「アプリケーション」を追加する必要がある場合があります。これらは通常無料で、オープンソースです。 この手順では、ベンダーが作成した指示が非常にわかりやすいと思いました。 オペレーティングシステムのメトリックを監視できるようになったら、Cachéを追加します。 ステップ 2. ISC-CACHE.mib と ISC-ENSEMBLE.mib をツールにインポートして、MIB構造を認識できるようにします。 ここでの手順はツールによって異なります。PRTGの場合は「MIB Importer」ユーティリティが提供されています。 基本的には、ツールで ISC-CACHE.mib テキストファイルを開いて、ツールの内部形式にインポートする、という手順です。 たとえば、SplunkではPython形式が使用されています。 注意: すべてのCaché MIBブランチでセンサーを追加しようとすると、PRTGツールはタイムアウトしてしまいました。 ツリー全体をウォークし、プロセスリストなどのいくつかのメトリックでタイムアウトしたのだと思います。このトラブルシューティングに時間をかける代わりに、 ISC-CACHE.mibからパフォーマンスブランチ(cachePerfTab)のみをインポートすることで問題を回避しました。 インポートと変換が完了したら、ネットワークのほかのサービスからデータを収集するためにMIBを再利用することができます。 上の図では、PRTGがSensor Factoryセンサを使用して複数のセンサを1つのチャートに結合しています。 最後に 監視ツール、警告ツール、そして非常に高度なスマート分析ツールにはさまざまなものがあり、無料で提供されているものもあれば、サポートライセンス付きのものもあり、機能も多岐に渡ります。 システムを監視し、どのアクティビティが正常であり正常外であるのかを理解し、調査する必要があります。 SNMPは、CachéとEnsembleのメトリックを確認できるようにするための簡単な方法と言えます。
記事
Shintaro Kaminaka · 2020年7月3日

組み込みREST APIを使用したInterSystems IRISの監視

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はパフォーマンスとシステムの使用状況に関するメトリックの履歴データベースとして長い間利用されてきました。 しかし、これらのメトリックと計測システムをリアルタイムで表示する明確な方法はありませんでした。 IRISプラットフォームソリューションは(その他のあらゆるソリューションと同様に)少数のオンプレミスインスタンスで実行されている単一のモノリシックアプリケーションから「あらゆる場所」に配置される分散ソリューションに移行しています。 既存のIRIS監視オプションは、多くの使用事例でこれらの新しいパラダイムに適合していません。 InterSystemsは既存の技術を作り直すのではなく、好評で実績のある現在の監視・警告用オープンソースソリューションに目を向けました。 Prometheusとは? Prometheusは実績のある技術に基づいた、広く普及している有名なオープンソースの監視システムです。 同システムにはさまざまなプラグインがあります。 また、クラウド環境内で適切に機能するように設計されていますが、オンプレミスでも同様に役立ちます。 プラグインには、オペレーティングシステム、ApacheなどのWebサーバー、およびその他の多くのアプリケーション向けのものがあります。 PrometheusはGrafanaなどのフロントエンドクライアントでよく使用されており、高度なカスタマイズ性と優れたUI/UXエクスペリエンスを提供します。 Grafanaとは? Grafanaもオープンソースです。 この連載を進める中で、一般的なシナリオの監視ダッシュボードのサンプルテンプレートをご紹介します。 サンプルをベースに監視対象項目のダッシュボードを設計できます。 本当の力は、状況に応じたIRISメトリックを使用中のソリューションスタック全体のメトリックと組み合わせるときに発揮されます。 例えば、プラットフォームのコンポーネント、オペレーティングシステム、IRISのメトリックがありますが、特にアプリケーションからインストルメンテーションを追加する場合もそうです。 これらは実績のあるソリューションです。 PrometheusおよびGrafanaによるIRISとCachéの監視は目新しいことではありません。 私はこれらのアプリケーションを数年間使用し、自分の開発環境やテスト環境を監視しています。 開発者コミュニティで「Prometheus」を検索していただければ、CachéのメトリックをPrometheusで使用するために公開する方法を説明した他の投稿(Mikhail Khomenkoによるいくつかの優れた投稿など)が見つかります。 現在との違いは、/api/monitor APIが含まれ、デフォルトで有効になっていることです。 メトリックを公開するために独自のクラスをコーディングする必要はありません。 Prometheus 入門 ここでは、Prometheusといくつかの用語について簡単に説明します。 私はIRISまたは他のソースが提供するメトリックの可視化方法や利用方法について、概要を理解し、基礎を固め、実践する機会を作っていただきたいと考えています。 Prometheusは、アプリケーションがHTTPエンドポイント(IRIS /api/monitor などの各種API)として公開する時系列データをスクレイピングまたは取得することで機能します。エクスポーターとクライアントライブラリは多くの言語、フレームワーク、オープンソースアプリケーションに対応しています。例えば、ApacheなどのWebサーバー、オペレーティングシステム、Docker、Kubernetes、データベース、現在のIRISなどが挙げられます。 エクスポーターはアプリケーションやサービスを計測し、スクレイピング用にエンドポイントで関連メトリックを公開するために使用されます。 Webサーバー、データベースなどの標準コンポーネントは基本的なエクスポーターでサポートされています。 他の多くのエクスポーターは、Prometheusコミュニティからオープンソースで公開されています。 Prometheus用語集 知っておくと便利な用語がいくつかご紹介します。 ターゲットは、ホストやアプリケーション、ApacheやIRISなどのサービス、独自のアプリケーションなど、監視対象となるサービスの場所です。 PrometheusはHTTPを利用してターゲットをスクレイピングし、メトリックを時系列データとして収集します。 時系列データは、IRISなどのアプリケーションやエクスポーターを介して公開されます。 エクスポーターは、Linuxカーネルのメトリックなどの制御できないものに使用できます。 結果の時系列データは、Prometheusサーバーのデータベース内にローカルに保存されます**。 時系列データベースは、最適化されたクエリ言語(PromQL)を使用して照会できます。 例えば、アラートを作成したり、Grafanaなどのクライアントアプリケーションを使用してダッシュボードにメトリックを表示したりできます。 **ネタバレ注意:セキュリティ、スケーリング、高可用性およびその他の運用効率の理由から、新しいSAMソリューションではPrometheusの時系列データに使用されるデータベースはIRISになっています! ただし、IRISでのPrometheusデータベースへのアクセスは透過的であるため、Grafanaなどのアプリケーションがその事を認識したり、問題にすることはありません。 Prometheusのデータモデル APIが返すメトリックはPrometheus形式です。 Prometheusは1行ごとに1つのメトリックを持つ単純なテキストベースのメトリック形式を使用します。次のような形式になっています。 <identifier> [ (time n, value n), ....] メトリックには、(キー、値)のペアとしてラベルを付けることができます。 ラベルは、メトリックをディメンションとしてフィルタリングする強力な方法です。 例として、IRIS /api/monitorに対して返された単一のメトリックを調べます。 この場合、ジャーナルの空き容量は次のようになります。 iris_jrn_free_space{id="WIJ",dir=”/fast/wij/"} 401562.83 識別子はそのメトリックが何であるかを表し、その出処を伝えるものです。 iris_jrn_free_space 複数のラベルを使用してメトリックを装飾し、後からフィルタリングとクエリに使用できます。 この例では、WIJと、WIJが格納されているディレクトリを確認できます。 id="WIJ",dir="/fast/wij/" また、値は401562.83 (MB) です。 どんなIRISメトリックを利用できますか? プレビューのドキュメントのメトリックのリストを掲載しています。 ただし、リストの内容は変更される可能性がありますのでご注意ください。 または、単に /api/monitor/metrics エンドポイントを照会し、リストを確認することもできます。 コミュニティの次の投稿では、Postmanの使い方についてご説明します。 何を監視対象にすべきですか? システムとアプリケーションの監視方法を検討する場合は以下の点に留意してください。 可能な場合は、ユーザーに影響を与える重要なメトリックを計測してください。 ユーザーはあなたが所有するマシンのCPU能力不足を気にしません。 ユーザーはサービスの遅延やエラーを気にします。 プライマリダッシュボードでは、ユーザーに直接影響する概要メトリックに注目してください。 ダッシュボードをグラフで埋め尽くさないでください。 人間は一度に多くのデータを処理することはできません。 例えば、サービスごとにダッシュボードを用意してください。 マシンではなくサービスについて考えてください。 問題を1つのサービスに特定したら、それを掘り下げ、1台のマシンに問題があるかどうかを確認できるようになります。 参考情報 PrometheusとGrafanaのドキュメントとダウンロード SAM(PrometheusとGrafanaを含む)のプレリリース概要をInterSystems Global Summit 2019で発表しました。リンクはInterSystemsの学習サービスでご確認いただけます。 直接リンクが機能しない場合は、InterSystems学習サービスのWebサイトにアクセスして「System Alerting and Monitoring Made Easy」を検索してください。 コミュニティで「Prometheus」と「Grafana」を検索してください。 次のパート「例:デフォルトのREST APIを使用したInterSystems IRISの監視メトリックの確認」を読み進めてください。
記事
Toshihiko Minamoto · 2020年7月6日

Microsoft Azure Resource Manager(ARM)向けInterSystemsサンプルリファレンスアーキテクチャ

この記事では、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(サービスとしてのインフラストラクチャ)向けの機能の豊富な環境を提供しています。 あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などの環境に関わるすべての側面が正しく機能するように注意を払う必要があります。 この記事では、こういった各分野の詳細について説明しています。 パフォーマンス Azure ARMには、計算仮想マシン(VM)と関連するストレージオプションに使用できるさまざまなオプションがありますが、InterSystems製品に最も直接関連するのは、AzureページBLOBストレージにVHDファイルとして保管されたネットワーク接続IaaSディスクです。 ほかにも Blob(ブロック)やFileなどのオプションがいくつかありますが、それらはCachéの操作をサポートするのではなく、個別のアプリケーションの要件に特化したオプションです。 ディスクが保管されるストレージには、PremiumとStandardの2種類があります。 Premiumストレージは、確実に予測可能な低レイテンシの入出力操作毎秒(IOPS)とスループットが必要な本番ワークロードに適しています。 Standardストレージはより経済的なオプションで、本番以外またはアーカイブタイプのワークロードに適しています。 すべてのVMタイプがPremiumストレージにアクセスできるわけではないため、特定のVMタイプを選択する際には注意が必要です。 仮想IPアドレスと自動フェイルオーバー ほとんどのIaaSクラウドプロバイダーには、データベースフェイルオーバー設計で一般的に使用される仮想IP(VIP)アドレスに対応できる能力が欠けていました。 これを解決するために、最も一般的に使用されるいくつかの接続方法(特にECPクライアントやCSPゲートウェイ)は、ミラー対応にするVIP機能に依存しないようにCaché 内で強化されています。  xDBC、ダイレクトTCP/IPソケット、またはその他のダイレクトコネクトプロトコルなどの接続方法にはVIPを使用する必要があります。 これらに対処するために、InterSystemsのデータベースミラーテクノロジーは、Azure内部ロードバランサー(ILB)とやり取りしてVIPのような機能を実現するAPIを使うことで、Azure内でこれらの接続方法に対して自動フェイルオーバーを提供できるようにしており、したがって、Azure内に完全で堅牢な高可用性設計を提供しています。 これに関する詳細は、コミュニティ記事「Database Mirroring without a Virtual IP address(仮想IPアドレスを使用しないデータベースミラーリング)」で説明されています。 バックアップ操作 クラウド型デプロイメントでは、従来のファイルレベルのバックアップまたはスナップショットによるバックアップのいずれかによるバックアップは困難な場合があります。 これは、Azure BackupおよびAutomation Run Booksを、InterSystems External Freeze and Thaw API機能とともに使って達成できるようになりました。これにより、実質的な24時間365日の運用と、クリーンな定期バックアップの保証が実現できます。 または、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VMそのものにバックアップエージェントを展開し、論理ボリュームマネージャ(LVM)のスナップショットと組み合わせてファイルレベルのバックアップを活用することができます。 サンプルアーキテクチャ この記事では、アプリケーション固有のデプロイメントの開始点として、サンプルのAzureアーキテクチャを提供しています。可能性のあるさまざまなデプロイメントのガイドラインとしてご利用ください。 このリファレンスアーキテクチャでは、高可用性を実現するデータベースミラーメンバー、InterSystems Enterprise Cache Protocol(ECP)を使ったアプリケーションサーバー、InterSystems CSP Gatewayを使ったWebサーバー、内部および外部のAzureロードバランサーを含んだ、非常に堅牢なCaché データベースデプロイメントを紹介しています。 Azureアーキテクチャ Microsoft AzureにCachéベースのアプリケーションを展開する場合、ある分野に特有の考慮事項があります。 このセクションでは、アプリケーションに必要な通常の技術要件のほかに考慮する必要のある分野について説明します。   この記事には、InterSystems TrakCare統合医療情報システムとInterSystems HealthShare医療情報プラットフォームのデプロイメントに基づく2つの例が提供されています。後者には、Information Exchange、Patient Index、Health Insight、Personal Community、Health Connectが含まれています。 仮想マシン Azure仮想マシン(VM)には、BasicとStandardの2つのレベルがあります。 どちらのタイプでもサイズを選択できますが、 Basicレベルには、負荷分散や自動スケーリングといったStandardレベルに提供される機能がいくつか含まれていません。 このため、TrakCareのデプロイにはStandardレベルを使用しています。 StandardレベルのVMには、シリーズごとにさまざまなサイズが用意されています。 A、D、DS、F、FS、G、GSというシリーズです。 DS、GS、および新しいFSのサイズでは、Azure Premium Storageの使用がサポートされています。 通常、本番サーバーには、信頼性、低レイテンシ、高パフォーマンスを得られるPremium Storageを使用する必要があります。 このため、このドキュメントで説明するTrakCareとHealthShareのサンプルデプロイメントアーキテクチャでは、FS、DS、またはGSシリーズのVMを使用します。 提供される仮想マシンのサイズは、地域よって異なることにご注意ください。 仮想マシンのサイズの詳細は、以下を参照してください。 Windows仮想マシンのサイズ Linux仮想マシンのサイズ ストレージ TrakCareおよびHealthShareサーバーには、Azure Premium Storageが必要です。 Premium Storageは、データをソリッドステートドライブ(SSD)に格納して低レイテンシで高いスループットを提供しますが、Standard Storageはハードディスクドライブ(HDD)に格納するため、パフォーマンスレベルが低下します。 Azure Storageは冗長で可用性の高いシステムですが、現在、可用性セットはストレージ障害ドメイン全体に冗長性を提供しておらず、これによってまれに問題が起こることがあることに注意しておくことが重要です。 マイクロソフトは緩和策を備えており、このプロセスを広く利用できるようにするほか、エンドユーザーが簡単に使用できるように取り組んでいます。 お近くのマイクロソフトチームと直接協力し、緩和策が必要かどうかを判断することをお勧めします。 Premium Storageアカウントに対してディスクがプロビジョニングされる場合、IOPSとスループット(帯域幅)はディスクのサイズによって変化します。 現在、Premium Storageディスクには、P10、P20 、P30 の3タイプがあります。 各タイプのIOPSとスループットには、次の表に示すように特定の制限があります。 Premiumディスクタイプ P4 P6 P10 P15 P20 P30 P40 P50 ディスクサイズ 32 GB 64 GB 128 GB 256 GB 512 GB 1024 GB 2048 GB 4096 GB ディスクあたりのIOPS 120 240 500 1100 2300 5000 7500 7500 ディスクあたりのスループット 25 MB/秒 50 MB/秒 100 MB/秒 125 MB/秒 150 MB/秒 200 MB/秒 250 MB/秒 250 MB/秒 注意: 特定のVMにディスクトラフィックを駆動するのに十分な帯域幅があることを確認してください。 たとえば、STANDARD_DS13 VMには、すべてのPremium Storageディスクトラフィックに使用できる毎秒256 MBの専用帯域幅があります。 つまり、このVMに4つのP30 Premium Storageディスクが接続されている場合、スループットの制限は毎秒256 MBであり、4つのP30ディスクが理論的に提供される毎秒800 MBではありません。 Premium Storageディスクの詳細と、プロビジョニング済みの容量、パフォーマンス、サイズ、IOサイズ、キャッシュヒット数、スループットターゲット、帯域幅調整などの制限については、以下を参照してください。 Premium Storage 高可用性 InterSystemsは、定義された可用性セットに2台以上の仮想マシンを含めることをお勧めします。 定期または非定期のメンテナンス中に、99.95%のAzure SLAを満たすためには少なくとも1台の仮想マシンが利用可能となるため、この構成が必要となります。 データセンターが更新中である場合、VMは並行してダウン状態となり、アップグレードされた後、適当な順でオンラインとなるため、これは重要なことです。このメンテナンス期間中はアプリケーションが使用できません。 したがって、可用性の高いアーキテクチャには、負荷分散されたWebサーバー、データベースミラー、複数のアプリケーションサーバーなど、各種サーバが2台ずつ必要となります。 Azureの高可用性に関するベストプラクティスの詳細は、以下を参照してください。 可用性の管理 Webサーバーの負荷分散 Cachéベースのアプリケーションには、外部および内部の負荷分散されたWebサーバーが必要となる場合があります。 外部のロードバランサーはインターネットまたはWAN(VPNまたはExpress Route)経由でのアクセスに使用され、内部のロードバランサーは内部トラフィックに使用される可能性があります。 Azure Load Balancerは、レイヤー4(TCP、UDP)タイプのロードバランサーで、ロードバランサー内に定義されたクラウドサービスまたは仮想マシン内の正常なサービスインスタンスに着信トラフィックを分散します。 Webサーバーのロードバランサーは、クライアントIPアドレスセッション永続化(2タプル)と可能な限り短いプローブタイムアウト(現在は5秒)で構成されている必要があります。 TrakCareでは、ユーザーがログインしている期間、セッション永続化が必要です。   マイクロソフトが提供している次の図は、ARMデプロイメントモデル内のAzure Load Balancerの簡単な例を示しています。 分散アルゴリズム、ポート転送、サービス監視、送信元ネットワークアドレス変換といったAzure Load Balancerの機能や、各種ロードバランサーの詳細については、以下を参照してください。 Load Balancerの概要 Azureは、外部ロードバランサーのほか、Azure Application Gatewayを提供しています。 Application Gatewayは、CookieベースのセッションアフィニティとSSL終端(SSLオフロード)をサポートするL7ロードバランサー(HTTP/HTTPS)です。 SSLオフロード機能は、SSL接続がロードバランサーで終了するため、暗号化/復号化のオーバーヘッドをWebサーバーから取り除きます。 このアプローチでは、SSL証明書がWebファーム内のすべてのノードでではなく、ゲートウェイで展開および管理されるため、管理が簡素化されます。 詳細については、以下を参照してください。 Application Gatewayの概要 Azure Resource Managerを使ってApplication GatewayにおけるSSLオフロードを構成する データベースミラーリング CachéベースのアプリケーションをAzureにデプロイする場合、Cachéデータベースサーバーに高可用性を提供するには、同期データベースミラーリングを使用して、特定のプライマリAzureリージョンで高可用性を提供し、アップタイムサービスレベル契約の要件によっては、潜在的に非同期データベースミラーリングを使用して、災害復旧用としてセカンダリAzureリージョンのホットスタンバイにデータを複製する必要があります。 データベースミラーは、フェイルオーバーメンバーと呼ばれる2つのデータベースシステムの論理グループです。これらのメンバーはネットワークでのみ接続された物理的に独立したシステムです。 ミラーは、2つのシステムを解決した後、自動的に片方をプライマリシステムとするため、もう片方は自動的にバックアップシステムになります。 外部クライアントワークステーションまたはほかのコンピュータは、ミラーリング構成中に指定されたミラーの仮想IP(VIP)を介してミラーに接続します。 ミラーVIPは、ミラーのプライマリシステムのインターフェイスに自動的にバインドされます。 注意: Azureでは、ミラーVIPを構成することはできないため、代替ソリューションが考案されています。 Azureにデータベースミラーをデプロイするために現在推奨されているのは、同じAzure可用性セットに3つのVM(プライマリ、バックアップ、アービター)を構成することです。 こうすることで、Azureは常に、99.95%のSLAでこれらのVMのうち少なくとも2つと外部接続し、それぞれが別々の更新ドメインと障害ドメインに割り当てられるように保証しており、 その結果、データベースのデータ自体の適切な分離と冗長性を提供しています。 これに関するその他の詳細は、以下を参照してください。 Azure可用性セット Azureサーバーレベルアグリーメント(SLA) Azureを含むあらゆるIaaSクラウドプロバイダーには、クライアント接続を仮想IP機能がないアプリケーションに自動的にフェイルオーバーする処理に関する課題が伴います。 そこで、クライアント接続の自動フェイルオーバーには、それを維持するための指示がいくつかあります。   まず、InterSystemsは、CSPゲートウェイをミラー対応に拡張し、CSP Gatewayを備えたWebサーバーからデータベースサーバーへの接続にVIPを使用する必要をなくしました。 CSPゲートウェイは、両方のミラーメンバーと自動ネゴシエーションし、プライマリメンバーとなった適切なメンバーにリダイレクトします。 ECPクライアントを使用している場合は、すでにミラー対応である機能に対応します。 次に、CSP GatewayとECPクライアントの外部の接続には、依然としてVIPのような機能が必要です。 InterSystemsは、mirror_status.cxw ヘルスチェックステータスページを使ったポーリング方法を使用することをお勧めします。これは、コミュニティ記事「Database Mirroring without a Virtual IP address(仮想IPアドレスを使用しないデータベースミラーリング)」に説明されています。 Azure内部ロードバランサー(ILB)は、すべてのネットワークトラフィックをプライマリミラーメンバーに転送するために、VIPのような機能として単一のIPアドレスを提供します。 ILBはプライマリミラーメンバーにのみトラフィックを分散します。 この方法はポーリングに依存していないため、ミラー構成内のミラーメンバーがプライマリメンバーになった時点で転送することができます。 Azure Traffic Managerを使用したDRシナリオでは、ポーリングをこの方法と組み合わせて使用することができます。 バックアップと復元 バックアップ操作には、いくつかのオプションがあります。 InterSystems製品を使用したAzureデプロイメントでは、次の3つのオプションを実行できます。 最初の2つのオプションは、スナップショットを作成する前にデータベースによるディスクへの書き込みを一時停止し、スナップショットに成功したら更新を再開するというスナップショットタイプの手順を使用しています。 いずれかのスナップショット方式を使用してクリーンなバックアップを作成するには、次のおおまかな手順を実行します。 データベースのFreeze API呼び出しにより、データベースへの書き込みを一時停止する。 OSとデータディスクのスナップショットを作成する。 データベースのThaw API呼び出しにより、Cachéの書き込みを再開する。 バックアップファシリティはバックアップ場所にアーカイブする。 クリーンで一貫したバックアップを確保するために、整合性チェックなどの追加手順を定期的に追加することができます。 どのオプションを使用するかという決定ポイントは、組織の運用要件とポリシーによって異なります。 さまざまなオプションをさらに詳しく検討するには、InterSystemsにご相談ください。 Azure Backup Azure BackupとAzure Automation Runbooks、そしてInterSystemsのExternal Freeze and Thaw API機能を使って、Azure ARMプラットフォーム内でバックアップ操作を実施できるようになりました。実質的な24時間365日の運用リジリエンシーとクリーンな定期バックアップを実現できます。 Azure Backupの管理と自動化に関する詳細は、こちらを参照してください。 論理ボリュームマネージャのスナップショット 別の方法として、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VMそのものにバックアップエージェントを展開し、論理ボリュームマネージャ(LVM)のスナップショットと組み合わせてファイルレベルのバックアップを活用することができます。 このモデルには、WindowsまたはLinuxベースのVMをファイルレベルで復元できるというメリットがあります。 このソリューションで注意すべき点は、AzureやほとんどのIaaSクラウドプロバイダはテープメディアを提供しないため、すべてのバックアップリポジトリは、短期アーカイブ用のディスクベースであり、長期保管(LTR)にはBLOBまたはバケットタイプの低コストストレージを活用できるということです。 このモデルを使用する場合は、ディスクベースのバックアップリポジトリを最も効率的に使用できるように、重複除去テクノロジーをサポートするバックアップ製品を使用することを強くお勧めします。 こういったクラウド対応のバックアップ製品には、Commvault、EMC Networker、HPE Data Protector、Veritas Netbackupなどさまざまな製品があります。 InterSystemsでは、これらの製品の比較検証や推奨は行っておりません。 Caché Online Backup 小さなデプロイメントでは、組み込みのCaché Online Backupファシリティもオプションとして考えられます。 InterSystemsのデータベースオンラインバックアップユーティリティは、データベース内のすべてのブロックをキャプチャしてデータベースファイルにデータをバックアップし、出力をシーケンシャルファイルに書き込みます。 この、InterSystems独自のバックアップメカニズムは、本番システムのユーザーにダウンタイムを引き起こさないように設計されています。   Azureでは、オンラインバックアップが完了した後、バックアップ出力ファイルとシステムが使用中のその他すべてのファイルをAzureファイル共有にコピーする必要があります。 このプロセスは、仮想マシン内でスクリプト化して実行しなければなりません。 Azureファイル共有で最大限の可用性を得るには、Azure RA-GRSストレージアカウントを使用する必要があります。 Azureファイル共有の最大共有サイズは5 TB、最大ファイルサイズは1 TB、共有あたりの最大スループットは60 MB/秒(すべてのクライアントで共有)です。 オンラインバックアップは、バックアップに低コストのソリューションを実装したい小規模サイト向けのエントリーレベルのアプローチですが、 データベースのサイズが大きくなるにつれ、スナップショットテクノロジーを使った外部バックアップがベストプラクティスとして推奨されます。外部ファイルのバックアップ、より高速な復元時間、エンタープライズ全体のデータビューと管理ツールなどのメリットがあります。 災害復旧 AzureにCachéベースのアプリケーションをデプロイする場合は、ネットワーク、サーバー、ストレージなどの災害復旧(DR)リソースを異なるAzureリージョンに配置することをお勧めします。 指定されたDR Azureリージョンに必要な容量は、組織のニーズによって異なります。 ほとんどの場合、DRモードでの運用時には本番容量の100%が必要となりますが、弾性モデルとして必要になるまでは、より少ない容量をプロビジョニングできます。 DR Azureリージョンの仮想マシンに継続して複製するには、非同期データベースミラーリングが使用されます。 ミラーリングは、データベースのトランザクションジャーナルを使用して、プライマリシステムのパフォーマンスへの影響を最小限に抑えながら、TCP/IPネットワーク経由で更新を複製します。 これらのDR非同期ミラーメンバーには、圧縮と暗号化を構成することを強くお勧めします。 アプリケーションにアクセスする一般インターネット上のすべての外部クライアントは、DNSサービスとしてのAzure Traffic Manager経由でルーティングされます。 Microsoft Azure Traffic Manager(ATM)は、トラフィックを現在アクティブなデータセンターに転送するスイッチとして使用されます。 Azure Traffic Managerは、エンドユーザーがさまざまなサービスエンドポイントにルーティングされる方法を決定する、多数のアルゴリズムをサポートしています。 各種アルゴリズムの詳細は、こちらを参照してください。 このドキュメントでは、Traffic Managerのエンドポイント監視とフェイルオーバーと組み合わせて「優先度」付きのトラフィックルーティング方法を使用します。 エンドポイント監視とフェイルオーバーの詳細は、こちらを参照してください。 Traffic Managerは、各エンドポイントに通常のリクエストを送信してそのレスポンスを検証することで機能します。 エンドポイントが有効なレスポンスを提供できない場合、Traffic Managerはそのステータスを「デグレード」として表示します。 DNSレスポンスには含まれなくなり、代わりに利用可能な代替エンドポイントを返します。 このようにして、ユーザートラフィックは障害のあるエンドポイントから離れ、利用可能なエンドポイントに向けられます。 上記の方法を使用すると、特定のリージョンと特定のミラーメンバーのみがトラフィックを許可することになります。 これは、InterSystems CSP Gatewayから提示されるmirror-statusページの「エンドポイント定義」によって制御されており、 プライマリミラーメンバーのみが、モニタープローブからのHTTP 200として「成功」を返すことになっています。 マイクロソフトが提供する次の図は、優先度付きトラフィックルーチンアルゴリズムの概要を示しています。 Azure Traffic Managerは、すべてのクライアントが接続できる「https://my-app.trafficmanager.net」といった単一のエンドポイントを生成します。 さらに、「https://www.my-app-domain.com」のようなバニティURLを提供するようにAレコードを構成することができます。Azure Traffic Managerは、両リージョンのエンドポイントのアドレスを含む1つのプロファイルで構成されます。   常に、エンドポイント監視に基づいて、1つのリージョンのみがオンライン状態を報告します。 これにより、トラフィックは常に1つのリージョンにのみ流れるようになります。 エンドポイント監視は、プライマリAzureリージョンのアプリケーションがダウン状態であり、セカンダリAzureリージョンのアプリケーションがライブになっていることを検出するため、リージョン間のフェイルオーバーにさらに手順を追加する必要はありません。 これは、DR非同期ミラーメンバーがプライマリに昇格されると、CSP GatewayがTraffic Managerのエンドポイント監視にHTTP 200を送信するようになっているためです。 上記のソリューションの代替案は多くあり、組織の運用要件やサービスレベル契約に基づいてカスタマイズすることができます。 ネットワーク接続 アプリケーションの接続要件に応じて、インターネット、IPSEC VPN、またはAzure Express Routeを使った専用リンクのいずれかを使った複数の接続モデルがあります。 選択方法は、アプリケーションとユーザーのニーズによって異なります。 これら3つのモデルの帯域幅使用率はそれぞれ異なるため、Azure担当者に相談するかAzure Portalで特定のリージョンで使用可能な接続オプションを確認することをお勧めします。 Express Routeを使用している場合、災害復旧シナリオで有効にできる複数の回線やリージョンアクセスなどのオプションがあります。 Express Routeプロバイダーに相談し、プロバイダーがサポートする高可用性と災害復旧シナリオを理解することが重要です。 セキュリティ パブリッククラウドプロバイダーにアプリケーションをデプロイするかどうかを決定するには注意が必要です。 組織のセキュリティコンプライアンスを維持するには、組織の標準セキュリティポリシーまたはクラウド専用に作成された新しいポリシーに従う必要があります。 クラウドデプロイメントには、クライアントデータセンターと物理的なセキュリティ管理の外にデータが置かれるため、付加リスクが伴います。 使用中でないデータ(データベースとジャーナル)と使用中のデータ(ネットワーク通信)には、InterSystemsのデータベースとジャーナル暗号化と合わせて、前者にはAESを、後者にはSSL/TLS暗号化を使用することを強くお勧めします。 すべての暗号化キー管理と同様に、データの安全を確保し、不要なデータアクセスやセキュリティ違反を防止するには、組織のポリシーに基づいて、適切な手順を文書化し、それに従う必要があります。 インターネット経由でのアクセスが許可されている場合、侵入検知、サービス拒否保護などの追加機能を導入するために、サードパーティのファイアウォール装置が必要となる場合があります。 アーキテクチャ図の例 下の図は、データベースミラーリング(同期フェイルオーバーとDR非同期)、ECPを使用したアプリケーションサーバー、負荷分散された複数のWebサーバーの構成で高可用性を提供する典型的なCachéインストールを示しています。 TrakCareの例 次の図は、負荷分散される複数のWebサーバー、ECPクライアントとしての2台のEPSプリントサーバー、データベースミラーで構成される典型的なTrakCareデプロイメントを示しています。 仮想IPアドレスは、ECPまたはCSP Gatewayに関連付けられていない接続のみ使用されます。 ECPクライアントとCSP Gatewayはミラー対応であり、VIPを必要としません。 下のサンプルリファレンスアーキテクチャ図には、アクティブまたはプライマリリージョンにおける高可用性と、プライマリAzureリージョンが利用不可である場合の別のAzureリージョンへの災害復旧が含まれます。 また、この例では、データベースミラーには、1つのミラーセット内にTrakCare DB、TrakCare Analytics、およびIntegrationネームスペースが含まれています。 TrakCare Azureリファレンスアーキテクチャ図 - 物理アーキテクチャ さらに、次の図は、インストール済みの関連する高度なソフトウェア製品を含めたより論理的なアーキテクチャ全容と機能目的を示しています。 TrakCare Azureリファレンスアーキテクチャ図 - 論理アーキテクチャ HealthShareの例 次の図は、負荷分散される複数のWebサーバーと、Information Exchange、Patient Index、Personal Community、Health Insight、Health Connectといった複数のHealthShare製品による典型的なHealthSharaeデプロイメントを示しています。 それぞれの製品は、Azure可用性セット内に1組のデータベースミラーを含めて高可用性を実現しています。 仮想IPアドレスは、ECPまたはCSP Gatewayに関連付けられていない接続にのみ使用されます。 HealthShare製品間のWebサービス通信に使用されるCSP Gatewayはミラー対応であり、VIPを必要としません。 下のサンプルリファレンスアーキテクチャ図には、アクティブまたはプライマリリージョンにおける高可用性と、プライマリAzureリージョンが利用不可である場合の別のAzureリージョンへの災害復旧が含まれます。 HealthShare Azureリファレンスアーキテクチャ図 - 物理アーキテクチャ さらに、次の図は、インストール済みの関連する高度なソフトウェア製品を含めたより論理的なアーキテクチャ全容、接続要件と方法、およびそれぞれの機能目的を示しています。 HealthShare Azureリファレンスアーキテクチャ図 - 論理アーキテクチャ
記事
Toshihiko Minamoto · 2020年7月8日

LinuxのTransparent HugePageとInterSystems IRISへのインパクト

** 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] に設定されている可能性があります。   Transparent Huge Pages(THP)はより大きなメモリページを使用することにより、大量のメモリを搭載したマシンでのTranslation Lookaside Buffer(TLB)ルックアップのオーバーヘッドを削減するLinuxのメモリ管理システムです。 ただし、現在のLinuxリリースでTHPがマップできるのは、個々のプロセスヒープとスタック領域のみです。 課題 Cache'システムでは、共有メモリセグメント(グローバルプールとルーチンバッファプール)に大部分のメモリ割り当てが行われます。これは、THPがこれらの共有メモリセグメントを処理しないためです。 その結果、THPは共有メモリには使用されず、個々のプロセスごとにのみ使用されます。 この状況は、単純なシェルコマンドを使用して確認できます。   以下はInterSystemsのテストシステムの例ですが、2MBのTHPがCache'のプロセスに割り当てられていることが分かります。 # grep -e AnonHugePages /proc/*/smaps | awk '{ if($2>4) print $0} ' | awk -F "/" '{print $0; system("ps -fp " $3)}' /proc/2945/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 2945 1 0 2015 ? 01:35:41 /usr/sbin/rsyslogd -n /proc/70937/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70937 70897 0 Jan27 pts/0 00:01:58 /bench/EJR/ycsb161b641/bin/cache WD /proc/70938/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70938 70897 0 Jan27 pts/0 00:00:00 /bench/EJR/ycsb161b641/bin/cache GC /proc/70939/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70939 70897 0 Jan27 pts/0 00:00:39 /bench/EJR/ycsb161b641/bin/cache JD /proc/70939/smaps:AnonHugePages: 4096 kB UID PID PPID C STIME TTY TIME CMD root 70939 70897 0 Jan27 pts/0 00:00:39 /bench/EJR/ycsb161b641/bin/cache JD /proc/70940/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70940 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 1 /proc/70941/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70941 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 2 /proc/70942/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70942 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 3 /proc/70943/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70943 70897 0 Jan27 pts/0 00:00:33 /bench/EJR/ycsb161b641/bin/cache SWD 7 /proc/70944/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70944 70897 0 Jan27 pts/0 00:00:29 /bench/EJR/ycsb161b641/bin/cache SWD 4 /proc/70945/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70945 70897 0 Jan27 pts/0 00:00:30 /bench/EJR/ycsb161b641/bin/cache SWD 5 /proc/70946/smaps:AnonHugePages: 2048 kB UID PID PPID C STIME TTY TIME CMD root 70946 70897 0 Jan27 pts/0 00:00:30 /bench/EJR/ycsb161b641/bin/cache SWD 6 /proc/70947/smaps:AnonHugePages: 4096 kB さらに、特にジョブまたはプロセスが高い頻度で作成される可能性のあるアプリケーションでは、実行時にメモリ割り当てが遅延するという形でパフォーマンスが低下する可能性があります。 推奨事項 目的とするパフォーマンスの向上はIRIS共有メモリセグメントには適用されず、一部のアプリケーションでパフォーマンスに悪影響を及ぼす可能性があるため、InterSystemsはTHPを当分の間は無効にすることをお勧めしています。 次のコマンドを実行し、LinuxシステムでTransparent HugePagesが有効になっているかどうかを確認してください。 Red Hat Enterprise Linuxカーネルの場合: # cat /sys/kernel/mm/redhat_transparent_hugepage/enabled 他のカーネルの場合: # cat /sys/kernel/mm/transparent_hugepage/enabled 上記のコマンドは、[always]、[madvise]、または [never] フラグが有効になっているかどうかを表示します 。 THPがカーネルから削除されている場合、/sys/kernel/mm/redhat_transparent_hugepage or /sys/kernel/mm/redhat/transparent_hugepage ファイルは存在しません。 起動中にTransparent HugePagesを無効にするには、次の手順を実行します。 /etc/grub.conf ファイルのカーネル起動行に次のエントリを追加します。 transparent_hugepage=never OSを再起動します。 THPをその場で無効にする方法もありますが、それは新しいプロセス用のTHPの作成と使用が停止するだけなので、望ましい結果が得られない可能性があります。 作成済みのTHPは、通常のメモリページに分解されません。 ブート時にTHPを無効にするには、システムを完全に再起動することをお勧めします。 *注意:THPを無効にする方法を確認するには、各Linuxディストリビューターに確認することをお勧めします。
質問
Hiroshi Sato · 2020年8月26日

InterSystems製品のIsolation レベルについて教えてください。

SQL92では以下の4つのIsolation レベルを定義しています。 1. Read Uncommitted2. Read Committed3. Repeatable Read4. Serializable InterSystems SQLでは、 1. Read Uncommitted と 2. Read Committed をサポートして おり、デフォルトのIsolation レベルは Read Uncommitted です。