クリアフィルター
お知らせ
Mihoko Iijima · 2022年11月16日
開発者の皆さん、こんにちは！
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 の学習に関連したトピックについて、開発者コミュニティでの厳選された記事にアクセスすることができます。機械学習や 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 のテクノロジーボーナス詳細が決定しましたのでお知らせします📣
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日
今週は、ハードウェアの主な”食品群” (^_^) の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データプラットフォームで実行するデータベースアプリケーションにおけるグローバルバッファ、ルーチンバッファ、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日
前回の記事では、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日
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日
この記事では、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日
** 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日
SQL92では以下の4つのIsolation レベルを定義しています。
1. Read Uncommitted2. Read Committed3. Repeatable Read4. Serializable
InterSystems SQLでは、 1. Read Uncommitted と 2. Read Committed をサポートして おり、デフォルトのIsolation レベルは Read Uncommitted です。
お知らせ
Mihoko Iijima · 2020年9月15日
開発者の皆さん、こんにちは！
Full Stack コンテストについての続報をお伝えします！
投票期間に追加ポイントを獲得できる「テクノロジーボーナス」について紹介します。
対象となる技術は、以下の通りです。
InterSystems IRIS REST API の使用
InterSystems Native API の使用
InterSystems JDBC の使用
ZPMパッケージによる公開
Docker コンテナの使用
詳細は以下の通りです。
InterSystems IRIS REST API の使用 - 1 point
フルスタック・アプリケーションから、REST API 経由で InterSystems IRIS にアクセスるとボーナスポイントを獲得できます。REST API をご自身で開発されるか、組み込みのものを利用したり、ZPM 経由でインストールするなど、選択できます。
RESTサービス作成方法については、ドキュメントや IRIS で作成する REST サーバの仕組み をご参照ください。
InterSystems Native API の使用 - 1 point
InterSystems Native API（.NET、Java、Python、Node.js）のいずれかを使用してフルスタック・アプリケーションのデータにアクセスすると、テクノロジーボーナスを獲得できます。詳細はこちらのドキュメントの「Native API for xxx の使用法」のリンク先をご参照ください。
InterSystems JDBC の使用 - 1 point
InterSystems IRIS では、JDBC ドライバを提供しています。SQL と InterSystems JDBC を使用してフルスタック・アプリケーションのデータ参照を行うことでテクノロジボーナスが獲得できます。
JDBC ドライバの使用法についてはドキュメントをご参照ください。
ZPM パッケージによる公開と使用 - 1 point
フルスタック・アプリケーション用に ZPM（ObjectScript Package Manager）パッケージをビルドして公開し、それを利用してデプロイできるように開発されると、テクノロジーボーナスが獲得できます。
ZPM クライアントがインストールされている IRIS でのコマンド実行例は以下の通りです。
zpm "install your-full-stack-solution-name"
詳細は、ZPM クライアントのドキュメントをご参照ください。
Docker container usage - 1 point
フルスタック・アプリケーションに Docker コンテナで実行する InterSystems IRIS を使用すると「Docker コンテナ」ボーナスを獲得できます。
コンテナ作成用の開発テンプレートを公開しています。以下のいずれかのテンプレートを使用して開発された場合、ボーナスポイントを獲得できます。
Basic InterSystems IRIS Docker template ／使い方解説ビデオ（日本語）
IRIS REST API template ／使い方解説ビデオ（日本語）（13:00～）
Native API template ／使い方解説ビデオ（日本語）
IntegratedML template／ 使い方解説ビデオ（日本語）（00:46～17:55）
IRIS Analytics template
掲載されている技術を使ってみたい方、何かお困りのことがあればぜひ開発者コミュニティへご質問ください！
記事
Megumi Kakechi · 2021年11月10日
これは 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が使用するワーキングセット(メモリ)について
記事
Tomohiro Iwamoto · 2020年6月29日
ここ数年の間、ハイパーコンバージドインフラストラクチャ（HCI）ソリューションが勢いを増しており、導入件数が急速に増加しています。 IT部門の意思決定者は、VMware上ですでに仮想化されているアプリケーションなどに対し、新規導入やハードウェアの更新を検討する際にHCIを考慮に入れています。 HCIを選択する理由は、単一ベンダーと取引できること、すべてのハードウェアおよびソフトウェアコンポーネント間の相互運用性が検証済みであること、IO面を中心とした高いパフォーマンス、単純にホストを追加するだけで拡張できること、導入や管理の手順が単純であることが挙げられます。
この記事はHCIソリューションの一般的な機能を取り上げ、HCIを初めて使用する読者に紹介するために執筆しました。 その後はデータベースアプリケーションの具体的な例を使用し、InterSystems データプラットフォーム上に構築されたアプリケーションを配置する際の、キャパシティプランニングとパフォーマンスに関する構成の選択肢と推奨事項を確認します。 HCIソリューションはパフォーマンスを向上させるためにフラッシュストレージを利用しているため、選択されたフラッシュストレージオプションの特性と使用例に関するセクションも含めています。
この記事のキャパシティ計画とパフォーマンスに関する推奨事項は、VMWare vSANに特化しています。 ただし、HCI市場で成長しているのはvSANだけではなく、同じく導入件数が増加しているNutanixをはじめとする他のHCIベンダーも存在します。 選択したHCIベンダーにかかわらず多くの機能は共通しているため、この記事の推奨事項は広く適用できます。 ただし、どの場合もアプリケーション固有の要件を考慮しながらHCIベンダーとこの記事の推奨事項について話し合うことが得策です。
InterSystems データプラットフォームとパフォーマンスに関する他の連載記事のリストはこちらにあります。
HCIとは？
厳密に言えばコンバージドソリューションは以前から長らく存在しますが、この記事ではWikipediaに「ハイパーコンバージェンスはパッケージ化された複数の個別システムから、市販されている商用x86ラックサーバーですべてが実行されるソフトウェア定義のインテリジェントな環境に進化している…」と記載されているような最新のHCIソリューションを取り上げています。
では、HCIは単独で存在するものなのでしょうか？
違います。 ベンダーに相談する際は、HCIには多くの置き換え可能な要素があることを覚えておく必要があります。コンバージドとハイパーコンバージドは具体的な青写真や標準ではなく、どちらかといえば一種のアーキテクチャなのです。 HCIハードウェアには商品性があるため、市場では複数のベンダーがソフトウェアレイヤーのほか、コンピューティング機能、ネットワーク機能、ストレージ機能、管理機能を組み合わせたその他の革新的な方法を使って差別化を図っています。
ここではあまり深追いしませんが、HCIの名が付いたあるソリューションでは、クラスター内の複数サーバー内にストレージを配置したり、サーバーのクラスターと独立したSANストレージ（複数の異なるベンダー製のものである可能性もあります）を使ったより普通の構成を作ることができます。これらはまた、相互運用性がテストおよび検証されており、単一のコントロールプレーンから管理できます。 キャパシティとパフォーマンスを計画する際は、ストレージがSANファブリック（ファイバーチャネルやイーサネットなど）を介して接続されたアレイにあり、ストレージプールがソフトウェアで定義され、サーバーノードの各クラスター内に配置され、複数のサーバー上でストレージが処理される場合とは異なるパフォーマンスと要件を備えたソリューションを検討する必要があります。
では、改めてHCIとは何でしょうか？
この記事ではHCI、特にストレージが物理的にホストサーバー内にあるVMware vSANに焦点を当てています。 このようなソリューションでは、HCIソフトウェアレイヤーが処理を実行するクラスター内の複数のノードのそれぞれの内部ストレージを1つの共有ストレージシステムのように機能させています。 そのため、HCIソフトウェアにコストがかかったとしても、エンタープライズストレージアレイを使用するソリューションと比較して、HCIを使用すると大幅にコストを節約できる可能性があることがHCIを採用するもう一つの要因となっています。
この記事では、HCIがコンピューティング、メモリ、ストレージ、ネットワーク、および管理ソフトウェアを仮想化したx86サーバーのクラスターに統合するソリューションについてご紹介します。
一般的なHCIの特徴
上記のとおり、HCIソリューションの一例にはVMWare vSANとNutanixがあります。 どちらもHCIに対して類似した高レベルのアプローチを採用しており、良い典型例だと言えます。
VMware vSAN にはVMware vSphereが必要であり、複数のベンダーのハードウェアで利用できます。 利用可能なハードウェアの選択肢は多数ありますが、これらはVMwareのvSANハードウェア互換性リスト(HCL)に厳密に依存しています。 ソリューションは、パッケージ化および事前構成されたEMC VxRailなどで購入できます。または、HCLでコンポーネントを購入して独自に構築することもできます。
Nutanixは、最大で2U、4ノードのアプライアンスを構成済みブロック化したハードウェアを含むオールインワンソリューションとして購入および導入することもできます。 Nutanixソリューションは、他のベンダーのハードウェアで検証された独自のソフトウェアソリューションとしても利用できます。
実装にはいくつかのバリエーションがありますが、一般的にHCIにはパフォーマンスとキャパシティの計画に関して、あなたが知っておくべき一般的な特徴があります。
仮想マシン(VM)はVMware ESXiなどのハイパーバイザーで実行されますが、Hyper-VやNutanix Acropolis Hypervisor(AHV)などのハイパーバイザーでも実行されます。 NutanixはESXiを使用して導入することもできます。
ホストサーバーは多くの場合、コンピューティング、ストレージ、ネットワークのブロックに統合されます。 例えば、4つのノードを持つ2Uアプライアンスがあります。
管理と可用性のために、複数のホストサーバーがクラスターに統合されます。
ストレージは階層化されており、オールフラッシュ、またはフラッシュキャッシュ層とキャパシティ層として利用する回転式ディスクとのハイブリッドになっています。
ストレージは、容量、パフォーマンス、可用性を確保するためのデータ配置とポリシーを含むソフトウェア定義のプールとして表現されます。
容量とIOのパフォーマンスは、クラスターにホストを追加することでスケーリングされます。
データは複数のクラスターノード上のストレージに同期的に書き込まれるため、クラスターはデータを失うことなくホストやコンポーネントの障害に耐えることができます。
VMの可用性とロードバランシングは、vMotion、VMware HA、DRSなどのハイパーバイザーによって提供されます。
上記の通り、外部ストレージアレイ、ストレージ専用ノードのサポートなど、このリストに変更を加えた他のHCIソリューションもあります。このリストはベンダーのリストと同じく長いです。
HCIの採用が加速し、ベンダー間の競争がイノベーションとパフォーマンスの向上を推進しています。 HCIがクラウドを導入するための基本的要素になっていることも注目に値します。
InterSystemsの製品はHCIでサポートされていますか？
オペレーティングシステムが仮想化されている場合を含め、さまざまなプロセッサのタイプとオペレーティングシステムに対してInterSystemsの製品を検証およびリリースするのは、InterSystemsのポリシーであり、決まりでもあります。 詳細については、InterSystemsサポートポリシーおよびリリース情報を参照してください。
例えばx86ホスト上のvSANの場合、Caché 2016.1をRed Hat 7.2オペレーティングシステム上で実行することができます。
注意：独自のアプリケーションを作成しない場合は、アプリケーションベンダーのサポートポリシーも確認する必要があります。
vSANキャパシティプランニング
このセクションでは、Caché、Ensemble、HealthShareなどのInterSystemsデータプラットフォーム上のデータベースアプリケーションにVMware vSANを導入する場合の考慮事項と推奨事項について説明します。 ただし、これらの推奨事項はHCIベンダーと検討するための一般的な構成関連の質問リストとして使用することもできます。
VM vCPUとメモリ
まず、複数の同じプロセッサを持つVMware ESXiにアプリケーションを導入するためにすでに使用中のものと同じキャパシティプランニングのルールをデータベースVMのvCPUとメモリに使用します。
Cachéの一般的なCPUとメモリのサイジングについて復習するには、この連載の他の記事のリスト「キャパシティ計画とパフォーマンスに関する連載の索引」を参照してください。
HCIシステムの特徴の1つに、非常に低いストレージIOレイテンシと高いIOPS機能があります。 この連載の第2回目の投稿にあった、CPU / メモリ / ストレージ / ネットワークを示すハードウェアの食品群の図を覚えていらっしゃるかもしれません。 その記事ではこれらのコンポーネントがすべて相互に関連しているため、1つのコンポーネントに対する変更が別のコンポーネントに影響する可能性があり、予期しない結果が生じることがあることを指摘していました。 例えば、私はストレージアレイの特にひどいIOボトルネックを解消するとCPU使用率が100％に跳ね上がり、ユーザーエクスペリエンスがさらに悪化した事例を見たことがあります。これは、システムが突然自由に作業量を増やせるようになったものの、ユーザー活動とスループットの増加に対応するためのCPUリソースがなかったために発生したものです。 新しいシステムを計画する際、サイジングモデルがパフォーマンスの低いハードウェアのパフォーマンスメトリックに基づいている場合はこのような影響を考慮する必要があります。 新しいプロセッサを搭載した新しいサーバーにアップグレードする場合でも、新しいプラットフォームでのIOレイテンシが低いために適切なサイズにする必要がある場合は、データベースVMの動作を注意深く監視する必要があります。
また、後述するように物理ホストのCPUリソースとメモリリソースをサイジングする際はソフトウェア定義のストレージIO処理も考慮する必要があります。
ストレージキャパシティプランニング
ストレージキャパシティプランニングを理解し、データベースの推奨事項を理解するには、まずvSANと従来のESXiストレージの基本的な違いを理解する必要があります。 最初にこれらの違いを説明し、次にCachéデータベースに関するすべてのベストプラクティスの推奨事項を詳しく説明します。
vSANストレージモデル
vSANおよびHCIでは、一般的にソフトウェア定義ストレージ(SDS)が重要な役割を果たしています。 データの保存方法と管理方法は、ESXiサーバーのクラスターと共有ストレージアレイを使用する場合とは大きく異なります。 HCIの利点の1つはLUNがないことです。その代わり、必要に応じてVMに割り当てられるストレージのプールがあり、VMDKごとに可用性、容量、およびパフォーマンスの機能を表すポリシーが適用されています。
例えば、パフォーマンスと可用性の要件に応じて、ディスクの数やタイプが異なるさまざまなサイズのディスクグループやディスクプールにまとめられた回転式ディスクのシェルフで構成された従来のストレージアレイを想像してください。 その後、ディスクグループは多数の論理ディスク(ストレージアレイボリュームまたはLUN)として表現され、データストアとしてESXiホストに提示され、VMFSボリュームとしてフォーマットされます。 VMはデータストア内のファイルとして表現されます。 可用性とパフォーマンスに関するデータベースのベストプラクティスでは、データベース(ランダムアクセス)、ジャーナル(シーケンシャル)、およびその他(バックアップや非本番システムなど)用に、少なくとも独立したディスクグループとLUNを使用することを推奨しています。
vSANの場合はそうではありません。vSANのストレージは、ストレージポリシーベースの管理(SPBM)を使用して割り当てられます。 ポリシーは、以下を含む機能を組み合わせて作成できます(ただし、これ以外の機能もあります)。
冗長なデータのコピー数を決める許容障害数(FTT)。
容量を節約するイレイジャーコーディング(RAID-5またはRAID-6)。
パフォーマンスを向上させるディスクストライプ。
シックまたはシンディスクプロビジョニング(vSANではデフォルトでシン)。
その他...
VMDK(個々のVMディスク)は適切なポリシーを選択することにより、vSANストレージプールから作成されます。 したがって、属性を設定してアレイ上にディスクグループとLUNを作成するのではなく、SPBMを使用してストレージの機能をvSANのポリシーとして定義します。例えば、「データベース」は「ジャーナル」やその他の必要なものとは異なります。 VM用のディスクを作成する際は容量を設定し、適切なポリシーを選択します。
もう一つ重要な概念があります。VMはVMDKデータストア上のファイルのセットではなく、ストレージオブジェクトのセットとして保存されます。 例えば、データベースVMはVMDK、スワップ、スナップショットなどを含む複数のオブジェクトとコンポーネントで構成されます。vSAN SDSは選択したポリシーの要件を満たすため、すべてのオブジェクト配置メカニズムを管理します。
ストレージ階層とIOパフォーマンスのプランニング
高いパフォーマンスを確保するため、2つの階層のストレージがあります。
キャッシュ層 - 高耐久性フラッシュである必要があります。
キャパシティ層 - フラッシュ、またはハイブリッドの場合は回転式ディスクを使用します。
下の図に示すように、ストレージは複数の階層とディスクグループに分かれています。 vSAN 6.5では、各ディスクグループに単一のキャッシュデバイスと最大7台の回転式ディスクまたはフラッシュデバイスが含まれます。 最大5つのディスクグループを使用できるため、ホストごとに最大35台のデバイスを使用できます。 次の図は、4つのホストを持つオールフラッシュvSANクラスターを示しています。各ホストには2つのディスクグループがあり、それぞれに1台のNVMeキャッシュディスクと3台のSATAキャパシティディスクがあります。
図1. それぞれの層とディスクグループを示すvSANオールフラッシュストレージ
それぞれの層の設定方法やキャッシュ層とキャパシティ層に使うフラッシュのタイプを検討する場合、IOパスを考慮する必要があります。レイテンシを最小にしてパフォーマンスを最大にするため、書き込みはキャッシュ層に移され、ソフトウェアがその書き込みをまとめてキャパシティ層に移します。 キャッシュの使用状況は導入モデルに依存します。例えばvSANハイブリッド構成の場合はキャッシュ層の30%が書き込みキャッシュですが、オールフラッシュの場合はキャッシュ層の100%が書き込みキャッシュで、読み込みは低レイテンシなフラッシュキャパシティ層から行われます。
オールフラッシュを使用すると、パフォーマンスが向上します。 大容量で耐久性のあるフラッシュドライブが利用できるようになった今、回転式ディスクが必要かどうかを検討する必要があります。 近年のビジネス事例では回転式ディスクの代わりにフラッシュが採用されており、はるかに低いIOPS単位のコスト、パフォーマンス(低レイテンシ)、高信頼性(可動部品が故障せず、必要なIOPSで故障するディスクが少ない)、低電力かつ低発熱なプロファイル、小さな設置面積などを特徴としています。 また、その他のHCI機能のメリットも得られます。例えばvSANでは、オールフラッシュ構成でのみ重複排除と圧縮が許可されます。
推奨: 最高のパフォーマンスとTCOの削減のため、オールフラッシュを検討してください。
最高のパフォーマンスを得るには、特にvSANの場合はディスクグループごとにキャッシュデバイスが1つしかないため、キャッシュ層のレイテンシを最低にする必要があります。
推奨: SASでも問題ありませんが、可能であればキャッシュ層にNVMe SSDを選択してください。
推奨: キャッシュ層で高耐久性フラッシュデバイスを選択し、高負荷なI/Oを処理するようにしてください。
キャパシティ層のSSDについては、SAS SSDとSATA SSDの性能の差はごくわずかです。 データベースアプリケーションについては、キャパシティ層でNVMe SSDのコストを負担する必要はありません。 ただし、いかなる場合も、電源障害保護などの機能を備えたエンタープライズクラスのSATA SSDを使用するようにしてください。
推奨: キャパシティ層には大容量のSATA SSDを選択してください。
推奨: 電源障害保護機能を備えたエンタープライズSSDを選択してください。
スケジュールによってはIOPSが高い3D Xpointなどの新しいテクノロジーを使用し、レイテンシを下げ、容量を増やし、耐久性を高めることができます。 この記事の最後に、フラッシュストレージの構成を記しています。
推奨: キャッシュ層とキャパシティ層には、3D Xpointなどの新しいテクノロジーを組み込むことを検討してください。
前述したように、ホストごとに最大5つのディスクグループを作成でき、ディスクグループのキャパシティ層は1台のフラッシュデバイスと最大7台のデバイスで構成されます。 1台のフラッシュデバイスかつ必要な容量の単一のディスクグループ、またはホストごとに複数のディスクグループを作成できます。 ホストごとに複数のディスクグループを持たせると、次のようなメリットがあります。
パフォーマンス：階層内に複数のフラッシュデバイスがあると、ホストごとのIOPSが増加します。
障害ドメイン：キャッシュディスクの障害はディスクグループ全体に影響しますが、vSANが自動的に再構築されるため、可用性は維持されます。
可用性、パフォーマンス、容量のバランスをとる必要がありますが、一般的にはホストごとに複数のディスクグループを用意することをお勧めします。
推奨: ストレージの要件を確認し、ホストごとに複数のディスクグループを用意することを検討してください。
どのようなパフォーマンスを期待できますか？
アプリケーションのユーザーエクスペリエンスを向上させるには、ストレージのレイテンシを下げることが重要です。通常は、データベースの読み取りIOのレイテンシを10ミリ秒未満にすることが推奨されています。詳細については、この連載のパート6の表を参照してください。
既定のvSANストレージポリシーとCaché RANREADユーティリティを使用してCachéデータベースのワークロードをテストした結果、キャパシティ層でIntel S3610 SATA SSDを使用したオールフラッシュvSANのレイテンシは1ミリ秒未満で、3万IOPS超のランダムな読み取りIOが100%持続されることを確認しました。 Cachéデータベースが基本的に可能な限り多くのデータベースIOにメモリを使用するようにインスタンスをサイジングすることを考慮すれば、オールフラッシュのレイテンシとIOPS能力はほとんどのアプリケーションに十分な余裕を与えるものです。 メモリのアクセス時間は、NVMeフラッシュストレージよりも桁違いに短いことを覚えておいてください。
いつものことですが、何が最適なのかは状況によって違います。ストレージポリシー、ディスクグループの数、ディスクの数とタイプなどがパフォーマンスに影響するため、ご自身のシステムで検証してください！
キャパシティとパフォーマンスのプランニング
vSANストレージプールの物理容量(TB)は、キャパシティ層のディスクの合計サイズとして大まかに計算できます。 図1の構成例では、合計24個のINTEL S3610 1.6 TB SSDがあります。
クラスターの物理容量：24 x 1.6TB = 38.4 TB
ただし、利用可能な容量は選択する構成によって大きく異なり、計算が煩雑になります。例えば、使用されるポリシー(データのコピー数を指定するFTTなど)のほか、重複排除や圧縮が有効になっているかどうかによって決まります。
ここでは選択されたポリシーを段階的に追い、その容量とパフォーマンスへの影響とデータベースのワークロードに関する推奨事項について説明します。
私が目にするあらゆるESXiの導入環境は、複数のVMで構成されています。例えば、統合医療情報システムであるTrakCareはInterSystemsの医療情報プラットフォーム上に構築されており、HealthShareの中核には「ティア1ビジネスクリティカルアプリケーション」の説明に完全に適合する少なくとも1台の大規模(モンスター)データベースサーバーVMがあります。 ただし、導入環境には本番ウェブサーバー、プリントサーバーなど、単一の目的を持つ他のVMも混在しています。 テスト用、トレーニング用、および本番用ではないその他のVMもです。 通常、すべてが単一のESXiクラスターに導入されます。 ここではデータベースVMの要件に焦点を当てていますが、SPBMはすべてのVMに対してVMDKごとに調整できることを覚えておいてください。
重複排除と圧縮
vSANの場合、重複排除と圧縮はクラスター全体でオン/オフします。 重複排除と圧縮は、オールフラッシュ構成を使用している場合にのみ有効にできます。 両方の機能を同時に有効にできます。
一見すると、重複排除と圧縮は良い考えのように思えます。キャパシティ層で(より高価な)フラッシュデバイスを使用している場合は特に容量を節約したいものです。 重複排除と圧縮を有効にすると容量を節約できますが、大規模な本番データベースや常にデータが上書きされているクラスターではこの機能を有効にしないことをお勧めします。
重複排除と圧縮によってホストの処理負荷が1桁の%CPU使用率の範囲で増加する可能性がありますが、それはデータベースに推奨されない主な理由ではありません。
要約すると、vSANは4Kブロックを使用する単一ディスクグループ内のキャパシティ層にデータが書き込まれるときにデータの重複排除を試みます。 したがって、図1の例では重複排除するデータオブジェクトは、同じディスクグループのキャパシティ層に存在していなければなりません。 一意のポインタやコンテンツなどを含む8Kのデータベースブロックで埋められた基本的に巨大なファイルであるCachéデータベースファイルの容量が大幅に減るとは思えません。 また、vSANは重複ブロックの圧縮のみを試み、圧縮率が50％以上に達した場合にのみブロックが圧縮されたと見なします。 重複排除されたブロックが2Kに圧縮されない場合は、圧縮されずに書き込まれます。 オペレーティングシステムや他のファイルに重複がある場合がありますが、重複排除と圧縮の本当のメリットはVDI用に導入されたクラスターにあります。
また、重複排除と圧縮が有効になっている場合、ディスクグループ内の1台のデバイスの(まれではありますが)障害がグループ全体に影響を及ぼすことにも注意すべきです。 ディスクグループ全体が「異常」とマークされると、クラスター全体に影響があります。グループが異常とマークされると、ディスクグループ上のすべてのデータがそのグループから他の場所に退避され、その後はデバイスを交換しなければならず、vSANはリバランスするためにオブジェクトを再同期します。
推奨: データベースの導入では、圧縮と重複排除を有効にしないでください。
補足：InterSystemsのデータベースミラーリングについて。
最高の可用性を必要とするミッションクリティカルなティア1のCachéデータベースアプリケーションインスタンスの場合、仮想化されている場合でもInterSystemsの同期データベースミラーリングをお勧めします。仮想化ソリューションにはHAが組み込まれています。例えばVMWare HAの場合、ミラーリングを使用すると次のようなメリットもあります。
最新データの独立したコピーが存在します。
秒単位でフェイルオーバーできます(VMを再起動してからオペレーティングシステムを起動し、Cachéをリカバリするよりも高速です)。
アプリケーション/Cachéに障害が発生した場合(VMwareでは検出されません)にフェイルオーバーできます。
同じクラスターでデータベースをミラーリングしている場合に重複排除を有効にすると、問題があることに気付きましたか？ ミラーデータの重複排除を試すことは 一般的には賢明ではなく、処理のオーバーヘッドも発生します。
HCIでデータベースをミラーリングするかどうかを決定する際は、必要な合計ストレージ容量を考慮する必要があります。 vSANは可用性を確保するためにデータのコピーを複数作成します。このデータストレージもミラーリングによって複製されます。 ストレージの追加コストと、VMware HAによるわずかな稼働時間の増加を天秤に掛ける必要があります。
稼働時間を最大にするため、2つのクラスターを作成し、データベースミラーの各ノードを完全に独立した障害ドメインに配置できます。 ただし、このレベルの稼働時間を提供するには、サーバーとストレージの合計容量に注意してください。
暗号化
また、保管データの暗号化方法も考慮する必要があります。 IOスタックには、次のようないくつかの選択肢があります。
Cachéのデータベース暗号化を使用する(データベースの暗号化のみ)。
ストレージで暗号化する(SSDでのハードウェアディスク暗号化など)。
暗号化がパフォーマンスに与える影響はごくわずかですが、HCIで重複排除または圧縮を有効にすると容量に大きな影響を与える可能性があります。 重複排除や圧縮を選択した場合、暗号化されたデータは設計上ランダムであり、十分に圧縮されないため、Cachéのデータベース暗号化を使用することは望ましくありません。 保護対象の場所や回避したいリスク(ファイルの盗難とデバイスの盗難のどちらを危険視するかなど)を検討してください。
推奨: 最低限の暗号化を行うには、可能な限り最下層のIOスタックで暗号化してください。 ただし、回避したいリスクが多くなるほど、スタックの階層は高くなります。
許容障害数(Failures To Tolerate, FTT)
FTT は、ストレージオブジェクトにクラスター内で少なくともn件のホスト、ネットワーク、またはディスクの障害が同時に発生してもオブジェクトの可用性を確保するようストレージに要件を設定します。 デフォルトは1(RAID-1)です。VMのストレージオブジェクト(VMDKなど)はESXiホスト間でミラーリングされます。
したがって、vSAN構成には少なくともn + 1個の複製(データのコピー)が含まれている必要があります。これは、クラスター内に2n + 1台のホストがあることも意味します。
例えば許容障害数が1のポリシーに従うには、たとえ1台のホストに障害が発生したとしても常に最低3台のホストを稼働させておく必要があります。 したがって、1台のホストがオフラインになったときのメンテナンスやその他の時間を考慮に入れるには、4台のホストが必要です。
推奨: vSANクラスターの場合、可用性を確保するには少なくとも4台のホストが必要です。
ただし、2台のホストと1台のリモート監視VMを想定したリモートオフィスブランチオフィス(ROBO)構成のような例外もあります。
イレイジャーコーディング
vSANのデフォルトのストレージ方式はRAID-1-データレプリケーションまたはミラーリングです。 イレイジャーコーディングは、ストレージオブジェクト/コンポーネントがクラスター内のストレージノードに分散されるRAID-5またはRAID-6です。 イレイジャーコーディングの主なメリットは、データ保護レベルを維持したまま容量効率を上げられることです。
前のセクションのFTTの計算を例として使用します。VMが2つの障害を許容する場合、RAID-1を使用するに、ストレージオブジェクトのコピーが3つ必要です。つまり、VMDKはベースVMDKのサイズの300％を消費します。 RAID-6ではVMが2つの障害に耐えることができ、VMDKのサイズの150％しか消費しません。
ここでは、パフォーマンスと容量のどちらかを選択する必要があります。 容量を節約できるのは素晴らしいことですが、イレイジャーコーディングを有効にする前にデータベースのIOパターンを考慮する必要があります。 容量効率が向上する代わりに、I/O処理が増加することになります。コンポーネントの障害が発生している間はさらに負荷が高くなるため、最高のデータベースパフォーマンスを確保するにはRAID-1を使用してください。
推奨: 本番データベースではイレイジャーコーディングを有効にしないでください。 本番環境以外で有効にしてください。
イレージャーコーディングはクラスターの必要なホスト数にも影響します。 例えばRAID-5の場合はクラスター内に最低4台のノードが必要で、RAID-6の場合は最低6台のノードが必要です。
推奨: イレイジャーコーディングの構成を計画する前に、追加ホストのコストを検討してください。
ストライピング
ストライピングはパフォーマンスを向上させるのに役立ちますが、役に立ちそうなのはハイブリッド構成だけだと思われます。
推奨: 本番データベースではストライピングを有効にしないでください。
オブジェクトスペースの予約(シンまたはシックプロビジョニング)
この設定の名前は、オブジェクトを使用してVM(VMDKなど)のコンポーネントを格納するvSANに由来しています。 デフォルトでは、VSANデータストアにプロビジョニングされるすべてのVMのオブジェクトスペースの予約は0％(シンプロビジョニング)になっています。この設定は容量を節約し、vSANのデータをより自由に配置できるようにします。 ただし、本番データベースでは予約値に100％(シックプロビジョニング)を使用し、作成時に容量を割り当てるのが最適です。 vSANの場合は、各ブロックへ初めて書き込まれるときに0が書き込まれるLazy Zeroedになります。 本番データベースの予約値に100％を選択する理由としては、データベースが拡張される際の遅延が少なくなり、必要なときにストレージを使用できることが保証されることが挙げられます。
推奨: 本番データベースのディスクの予約値には100％を使用してください。
推奨: 本番以外のインスタンスの場合、ストレージはシンプロビジョニングのままにしてください。
それぞれの機能をいつ有効化すべきですか？
通常はシステムをしばらく使用した後(システム上にアクティブなVMとユーザーが存在する状態)に可用性と容量節約の機能を有効化できます。 ただし、パフォーマンスと容量に影響します。 元のデータに加えてデータの複製が必要になるため、データを同期中は追加の容量が必要になります。 経験上、大規模なデータベースを使用するクラスターでこの種の機能を有効にすると、処理時間が非常に長くなり、可用性が低下する可能性があります。
推奨: 本番稼働を開始する前に、そして大規模なデータベースを読み込む前には必ず、事前に時間をかけて重複排除や圧縮などのストレージの機能を理解して構成するようにしてください。
ディスクバランシングや障害発生時用の空き領域を残すなど、他にも考慮事項があります。 つまり、この記事の推奨事項とベンダー固有の選択肢を考慮して物理ディスクの要件を把握する必要があります。
推奨: 多くの機能と置き換え可能な要素があります。 まずは合計GB容量の要件を見積もり、この記事の推奨事項を(アプリケーションベンダーと一緒に)確認してからHCIベンダーに相談してください。
ストレージ処理のオーバーヘッド
ホスト上でのストレージ処理のオーバーヘッドを考慮する必要があります。 かつてはエンタープライズストレージアレイのプロセッサが処理していたストレージの処理が、クラスター内の各ホストで実行されるようになっています。
各ホストのオーバーヘッドの大きさは、ワークロードと有効になっているストレージの機能によって決まります。 vSAN上のCachéで行ったテストの結果を見る限り、特に現在のサーバーで使用可能なコアの数を考慮すると、過度な処理要件はないと言えます。 VMwareはホストのCPU使用率が5〜10％になるよう計画することを推奨しています。
上記はサイジングを行う際にまず考慮すべき内容ですが、何が最適なのかは状況によって異なるため、確認が必要です。
推奨: CPU使用率が10％となる最悪のケースを想定し、実際のワークロードを監視してください。
ネットワーク
ベンダーの要件を確認してください。最小10GbEのNICを採用し、ストレージトラフィックや管理(例: vMotion)などに複数のNICを使うことを想定してください。 私は自分の苦い経験から、クラスターの最適な運用にはエンタープライズクラスのネットワークスイッチが必要であることを皆さんに伝えることができます。結局、可用性を確保するためにどんな書き込みもネットワーク経由で同期的に送信されるからです。
推奨: ストレージトラフィック用に最低10GbEの帯域幅を持つネットワークスイッチを使用してください。 ベストプラクティスに従い、ホストごとに複数のNICを用意してください。
フラッシュストレージの概要
HCIにはフラッシュストレージが必須であるため、フラッシュストレージの現状と今後の展望を確認することをお勧めします。
HCIを使用するかどうかにかかわらず、現時点でフラッシュを搭載したストレージを使用してアプリケーションを導入していないのであれば、次に購入するストレージにはフラッシュが搭載されている可能性があります。
ストレージの現状と未来
一般的に導入されているストレージソリューションの機能を確認し、用語を明確にしましょう。
回転式ディスク
昔ながらの SASまたはSATAインターフェースを備えた7,200回転、10,000回転、または15,000回転の回転式物理ディスクです。 ディスクあたりのIOPSは低いです。 このディスクは大容量にできますが、GBあたりのIOPSは減少します。 パフォーマンスを確保するため、通常は複数のディスクにデータを分散して「十分な」IOPSと大容量を実現します。
SSDディスク - SATAおよびSAS
現在、フラッシュは一般的にNANDフラッシュを使用する、SASまたはSATAインターフェースを持つSSDとして導入されています。 また、SSDにはいくらかのDRAMが書き込み可能なバッファメモリとして搭載されています。 エンタープライズSSDには停電保護機能が搭載されており、停電時にはDRAMの内容がNANDに書き込まれます。
SSDディスク - NVMe
SSDディスクと同様ですが、NVMeプロトコル(SASまたはSATAではない)とNANDフラッシュを使用します。 NVMeメディアはPCI Express(PCIe)バス経由で接続されるため、システムはホストバスアダプターやストレージファブリックのオーバーヘッドなしで直接通信でき、レイテンシが大幅に短縮されます。
ストレージアレイ
エンタープライズアレイは保護機能と拡張機能を提供します。 現在、ストレージの構成はハイブリッドアレイまたはオールフラッシュが一般的です。 ハイブリッドアレイにはNANDフラッシュのキャッシュ層のほか、7,200回転、10,000回転、または15,000回転の回転式ディスクを使用する1つ以上のキャパシティ層が含まれています。 NVMeアレイも利用できるようになっています。
ブロックモードNVDIMM
このデバイスは出荷が始まったばかりであり、非常に低いレイテンシが必要な場合に使用されます。 NVDIMMはDDRメモリソケットに装着され、レイテンシは約30ナノ秒です。 現在は8GBモジュールで出荷されているため、レガシーなデータベースアプリケーションには使用されない可能性が高いですが、新しいスケールアウトアプリケーションではこのパフォーマンスを利用できます。
3D XPoint
これは未来の技術であり、2016年11月時点では利用できません。
MicronおよびIntelによって開発されました。 また、Optane(Intel)およびQuantX(Micron)としても知られています。
少なくとも2017年までは利用できませんが、NANDと比較して容量が大きく、IOPSが10倍以上、レイテンシが10倍以上低くなるため、非常に高い耐久性と一貫したパフォーマンスが約束されます。
最初はNVMeプロトコルが採用される予定です。
SSDデバイスの耐久性
キャッシュ層とキャパシティ層のドライブを選択する際は、SSDデバイスの耐久性を考慮することが重要です。 フラッシュストレージの寿命は有限です。 SSDフラッシュのセルは、決まった回数だけ削除および再書き込みできます(読み取りに関しては制限はありません)。 デバイスのファームウェアはSSDの寿命を最大化するため、ドライブ全体に書き込みを分散するように調整します。 また、エンタープライズSSDは通常見た目よりも実際にはフラッシュの容量が大きいため(オーバープロビジョニング)、800 GBのドライブには1 TBを超えるフラッシュが搭載されている場合があります。
ストレージベンダーと話し合うために注目すべき指標は、一定年数で保証されている1日あたりのドライブ全体の書き換え可能回数(Drive Writes Per Day, DWPD)です。 例えば、1 DWPD(5年対応)の800 GB SSDは、1日に800 GBを5年間書き込むことができます。 したがって、DWPD(および年数)が多いほど耐久性が高くなります。 測定基準の計算方法を変え、指定されたSSDデバイスをテラバイト書き込み量(Terabytes Written, TBW)で表すこともできます。同じ例のTBWは、1,460 TB(800GB * 365日 * 5年)です。 どちらの方法でも、予想されるIOに基づいてSSDの寿命を知ることができます。
要約
この記事では、HCI、特にVMWare vSANバージョン6.5を導入する際に考慮すべき最も重要な機能について説明しました。 説明していないvSANの機能もあります。ここで言及していない機能については、デフォルト値を使用すべきだと考えてください。 ただし、ご質問やご意見がありましたら、コメントセクションで回答いたします。
今後の投稿ではHCIに戻る予定です。HCIは確実に発展していくアーキテクチャであるため、HCIに導入するインターシステムズのお客様が増えることを期待しています。
お知らせ
Mihoko Iijima · 2021年6月1日
開発者の皆さん、こんにちは！
いよいよ、第12回 InterSystems IRIS プログラミングコンテスト（FHIR Accelerator）の投票が、6月3日（木）US時間 から開始されます！
当初、5月31日（US時間）から投票開始予定でしたが、応募期間を延長し 6月3日が投票開始日となりました。
テーマは、InterSystems IRIS FHIR Accelerator Service (FHIRaaS) on AWS を使用して構築されたソリューションです。関連記事にご利用を開始するための手順を掲載しています。ぜひご参照ください。
➡️ 投票は 6月3日から！ これだ 🔥 と思う作品への投票、よろしくお願いします！
投票方法や新機能について：
Experts nomination:
今回は、経験豊富な審査員がベストアプリを選び、Expert Nominationで賞品をノミネートします。
↓審査員↓
⭐️ @Regilo Souza, InterSystems Service Executive⭐️ @Anton Umnikov, InterSystems Senior Cloud Solution Architect⭐️ @Patrick Jamieson, InterSystems Product Manager - Health Informatics Platform⭐️ @Evgeny Shvarov, InterSystems Developer Ecosystem Manager
Community nomination:
開発者コミュニティのメンバーは、お好みのアプリケーションに対して1位～3位を指定しながら投票できます。
開発者コミュニティでのあなたの状態
順位
1位
2位
3位
開発者コミュニティに記事を掲載したり、OpenExchange（OEX）にアプリをアップロードしたことがある方
9点
6点
3点
開発者コミュニティに1つの記事を掲載した、または 1アプリケーションを OEX にアップロードしたことがある方
6点
4点
2点
開発者コミュニティへコメントや質問を投稿したことがある方
3点
2点
1点
エキスパートレベル
順位
1位
2位
3位
グローバルマスターズの VIP レベル または、InterSystems Product Managers
15点
10点
5点
グローバルマスターズの Ambassador レベル
12点
8点
4点
グローバルマスターズの Expert レベル または DC モデレーター
9点
6点
3点
グローバルマスターズの Specialist レベル
6点
4点
2点
グローバルマスターズの Advocate レベル または インターシステムズの従業員
3点
2点
1点
投票方法についての変更点は以下の通りです
今回のコンテストでは、現時点の投票数を隠す「ブラインド投票」を行うことにしました。
そのため、アプリケーションへの投票数は 1日1回、この投稿のコメント欄に公開予定です。
メモ：新しいコメントの通知を受けるために、この投稿を購読することをお忘れなく！（記事末尾の ベルのアイコンをクリックするだけ！）
コンテストページの応募作品表示順については、コンテストに応募した時期が早ければ早いほど、上位に表示されます。
投票に参加するには？
Open Exchange へのサインインします（開発者コミュニティのアカウントを使用してください）。
投票ボタンは、開発者コミュニティ内で、質問／回答／記事の掲載／投稿に対するコメント など 記載いただいた方に対して有効になります。 ボタンが押せない場合は、コミュニティへのコメントやオリジナルの記事など、書き込みお願いします！詳細は、こちらの記事をご参照ください。
気が変わった場合は？ － 選択をキャンセルして別のアプリケーションに投票できます。
世界の IRIS 開発者が作成した ✨素敵なアプリ✨ が公開されています！ぜひ 🔥これだ🔥 と思う作品に投票お願いします！
メモ：コンテストへ応募された作品は、投票週間中にバグを修正したり、アプリケーションを改良したりすることができますので、アプリケーションのリリースを見逃さずに購読してください。
記事
Toshihiko Minamoto · 2021年7月19日
はじめに
近年、オープン認証フレームワーク（OAuth）を使って、あらゆる種類のサービスから信頼性のある方法で安全かつ効率的にリソースにアクセスするアプリケーションが増えています。 InterSystems IRIS はすでに OAuth 2.0 フレームワークに対応しており、事実コミュニティには、OAuth 2.0 と InterSystems IRIS に関する素晴らしい[記事](https://community.intersystems.com/post/intersystems-iris-open-authorization-framework-oauth-20-implementation-part-1)が掲載されています。
しかし、API 管理ツールの出現により、一部の組織はそのツールを単一の認証ポイントとして使用し、不正なリクエストが下流のサービスに到達するのを防ぎ、サービスそのものから承認/認証の複雑さを取り除いています。
ご存知かもしれませんが、InterSystems は、IRIS Enterprise ライセンス（IRIS Community Edition ではありません）で利用できる InterSystems API Management（IAM）という API 管理ツールを公開しています。 [こちら](https://community.intersystems.com/post/introducing-intersystems-api-manager)には、InterSystems API Management を紹介する素晴らしい別のコミュニティ記事が掲載されています。
これは、IAM を使って、以前に IRIS にデプロイされた認証されていないサービスに OAuth 2.0 標準に従ったセキュリティを追加する方法を説明した 3 部構成記事の最初の記事です。
サービスを保護するプロセス全体を理解しやすくするために、最初の記事では、IRIS と IAM の基本的な定義と構成を示しながら OAuth 2.0 の背景を説明します。
この連載記事のパート 2 以降では、IAM によってサービスを保護する上で考えられる 2 つのシナリオを説明します。 最初のシナリオでは、IAM は着信リクエストに存在するアクセストークンを検証し、検証が成功した場合にのみリクエストを 転送します。 2 番目のシナリオでは、IAM がアクセストークンを生成し（承認サーバーとして機能します）、それを検証します。
従って、パート 2 では、シナリオ 1 を構成するために必要な手順を詳しく説明し、パート 3 ではシナリオ 2 の構成を説明した上で、最終的な考慮事項を示します。
IAM をお試しになりたい方は、InterSystems 営業担当者にお問い合わせください。
OAuth 2.0 の背景
すべての OAuth 2.0 承認フローには基本的に以下の 4 つのグループが関わっています。
1. ユーザー
2. クライアント
3. 承認サーバー
4. リソース所有者
分かりやすくするために、この記事では「リソース所有者パスワード資格情報」OAuth フローを使用しますが、IAM ではあらゆる OAuth フローを使用できます。 また、この記事では範囲を指定しません。
注意: クライアントアプリはユーザー資格情報を直接処理するため、クライアントアプリの信頼性が非常に高い場合にのみリソース所有者パスワード資格情報フローを使用することをお勧めします。 ほとんどの場合、クライアントはファーストパーティアプリである必要があります。
以下は、一般的なリソース所有者パスワード資格情報フローの手順です。
1. ユーザーはクライアントアプリに資格情報（ユーザー名とパスワードなど）を入力します。
2. クライアントアプリは承認サーバーにユーザー資格情報と独自の ID（クライアント ID とクライアントシークレットなど）を送信します。 承認サーバーはユーザー資格情報とクライアント ID を検証し、アクセストークンを返します。
3. クライアントはトークンを使用して、リソースサーバーにあるリソースにアクセスします。
4. リソースサーバーは受け取ったアクセストークンを検証してから、クライアントに情報を返します。
これを踏まえ、IAM を使用して OAuth 2.0 を処理できるシナリオが 2 つあります。
1. IAM はバリデーターをして機能し、クライアントアプリが提供するアクセストークンを検証し、アクセストークンが有効である場合にのみリソースサーバーにリクエストを転送します。この場合、アクセストークンはサードパーティの承認サーバーによって生成されます。
2. IAM は承認サーバーとしてクライアントにアクセストークンを提供し、アクセストークンのバリデーターとしてアクセストークンを検証してから、リソースサーバーにリクエストをリダイレクトします。
IRIS と IAM の定義
この記事では、「/SampleService」という IRIS Web アプリケーションを使用します。 以下のスクリーンショットからわかるように、これは IRIS にデプロイされた認証されていない REST サービスです。
さらに、以下のスクリーンショットのとおり、IAM 側では 1 つのルートを含む「SampleIRISService」というサービスが構成されています。
また、IAM では、IAM で API を呼び出しているユーザーを識別するために、最初に資格情報の無い「CliantApp」というコンシューマーが構成されています。
上記の構成により、IAM は次の URL に送信されるすべての GET リクエストを IRIS にプロキシしています。
**http://iamhost:8000/event**
この時点では、認証は使用されていません。 したがって、認証無しで単純な GET リクエストを次の URL に送信する場合、
**http://iamhost:8000/event/1**
必要なレスポンスを得られます。
この記事では、「PostMan」というアプリを使用してリクエストを送信し、レスポンスを確認します。 以下の PostMan のスクリーンショットでは、単純な GET リクエストとそのレスポンスを確認できます。
着信リクエストに存在するアクセストークンを検証するように IAM を構成する方法を理解するには、この連載のパート 2 をお読みください。
