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

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

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

Durable %SYS 

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

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

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

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

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

 ワークフロー

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

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

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

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

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

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

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

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

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

この連載記事では、InterSystemsデータプラットフォーム用のPython Gatewayについて説明します。 また、InterSystems IRISからPythonコードなどを実行します。 このプロジェクトは、InterSystems IRIS環境にPythonの力を与えます。 

• 任意のPythonコードを実行する 
• InterSystems IRISからPythonへのシームレスなデータ転送 
• Python相互運用アダプタでインテリジェントな相互運用ビジネスプロセスを構築する 
• InterSystems IRISからのPythonコンテキストの保存、調査、変更、復元 

その他の記事 

現時点での連載計画です（変更される可能性があります）。 

• パート I：概要、展望、紹介 
• パート II：インストールとトラブルシューティング <-- 現在、この記事を参照しています 
• パート III：基本機能 
• パート IV：相互運用アダプタ 
• パート V：Execute関数 
• パート VI：動的ゲートウェイ 
• パート VII：プロキシゲートウェイ 
• パート VIII：使用事例とML Toolkit 

インストール 

この記事はPython Gatewayをインストールするのに役立ちます。

この記事と後続の2つの連載記事は、InterSystems製品ベースのアプリケーションでOAuth 2.0フレームワーク（簡略化のためにOAUTHとも呼ばれます）を使用する必要のある開発者またはシステム管理者向けのユーザーガイドを対象としています。 

作成者：Daniel Kutac（InterSystemsシニアセールスエンジニア） 

公開後の修正および変更の履歴 

• 2016年8月3日 - 新しいバージョンのページを反映するため、Googleのクライアント設定のスクリーンショットを修正し、Google APIのスクリーンショットを更新しました。
• 2016年8月28日 - Cache 2016.2でのJSON対応への変更を反映するため、JSON関連コードを変更しました。 
• 2017年5月3日 - Cache 2017.1でリリースされた新しいUIと機能を反映するため、テキストと画面を更新しました。 
• 2018年2月19日 - 最新の開発内容を反映するために、CachéをInterSystems IRISに変更しました。 製品名は変更されていますが、この記事はすべてのInterSystems製品（InterSystems IRIS Data Platform、Ensemble、Caché）を対象としています。 

パート1.

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はパフォーマンスとシステムの使用状況に関するメトリックの履歴データベースとして長い間利用されてきました。

1. 初めに

IRISでは、複数ノードでクラスターを構成し、ワークロードのスケールアウト、データボリュームのスケールアウトやトランザクション処理と分析処理を異なるノードで処理するマルチワークロードを実現しています。
しかし、クラスターを構成するための設定は、ノード数が増えるにつれ煩雑になり、それらを人手の作業に全て委ねると設定ミス等を招きやすいといえます。
また、クラスタの構成を処理負荷の増加に基づいて拡張する、または逆に縮小する、あるいは、データ冗長性を追加するためにミラーリングの構成を追加するなど構成変更は、想定するより多いかもしれません。
しかもクラスタ毎に同様の設定を毎回行うとなると、人手による作業では、煩雑性だけでなく俊敏性に欠けると言わざるを得ません。

そこで、IRISには、クラスター構成作業を自動化する新しいツールICM（InterSystems Cloud Manager）が用意されました。

ここでは、ICMを使用したクラウド上でのIRIS構成の自動化の手順について説明します。

2.　事前に準備するもの

以下の作業を行うためには、InterSystemsが用意している２つのDocker Imageを事前に取得する必要があります。

現時点のサポートバージョンについては、以下のドキュメントをご参照ください。

ミニマム・サポートバージョンについて
このリストに記述されていないバージョンに関しては、該当システムの保守契約があるという前提で、

1. メール、お電話等の通常のお問い合わせは受け付けます。
2. 出来うる限りの対応を努力しますが、そのバージョンでの対応が出来ず、最新バージョンへのバージョンアップによる問題解決をご提案させていただく場合がございます。

インターシステムズは、以下の理由により、出来うる限り、最新バージョンへバージョンアップしていただくことをお勧めしております。

1. 開発部門では、定期的に内部のコードレビュを実施しており、その結果、発見された機能不全等を適宜、最新バージョンに取り込んでいます。
2. 過去にお客様先で発見された障害への対応は、順次新バージョンに取り込んでいきます。障害の性質によっては、非常に大規模な改造となり、旧バージョンへの取り込み（バックポート）が不可能なものもございます。
3. 古いバージョンに対し、新バージョンに追加されたバグフィックスを取り込むこと（バックポート）は、非常に困難なケースが多く、新たな副作用を生む可能性が高くなります。　また、バージョンが古くなればなるほどバックポートは困難になっていく可能性が高まります。

お客様のシステムで発生した障害に対処するための製品修正や社内のコードレビューで新たに発見された潜在的な問題に対応するための修正などは、問題の重要度（運用に支障をきたす、アプリケーションの動作に影響があるなど）に応じて、順次新しいメジャーバージョン、メンテナンスバージョンに取り込まれていきます。

一方で、新しいバージョンのリリースには所定の時間が必要ですので、そのリリース前に該当する修正だけを適用したいというご要望にお応えするためにInterSystemsではアドホックと呼んでいる応急パッチを提供することも可能です。

しかしながら、この対応はあくまでも個別の応急処置であり、その問題が対処されたバージョンがリリースされた後には、そのバージョンをご使用いただくことを推奨致します。

この様な個別対応を繰り返し行うと、システムの構成管理が複雑化し、管理上のコストが上昇し、思わぬシステムトラブルの遠因になることもあります。

特に複数のエンドユーザー様に同じソリューションを提供する様なケースでは、システムの提供時期等によりシステム構成が変わり、適用可能なオペレーティングシステム等が変化することに伴い、全ての適用パッチを見直す必要が出てくることも想定されます。

InterSystemsは、新たなセキュリティの脆弱性が製品に見つかった場合、出来得る限り速やかにその脆弱性に対処するための修正を製品に行い、対応バージョンを出荷します。

また、InterSystemsは、セキュリティ脆弱性対応に関して、製品を修正して出荷するだけでは十分ではなく、InterSystemsの製品をお使いいただいている全てのお客様が、セキュリティ脆弱性に対応したバージョンをお使いいただくことによって、初めてそのセキュリティ脆弱性に起因するリスクを完全に排除できると考えています。

もちろん対処しなければ、必ずそのリスクが顕在化するというものでもありませんが、対処せずとも、問題がないということを100%保証することは極めて困難です。

また、セキュリティ脆弱性に対応したバージョンのご利用を推進するため、セキュリティ脆弱性への対策が施されていないバージョンに対する製品サポートはベストエフォートとなり、サポートバージョンと同等のサポート保証を得ることができない点、ご注意お願い致します。

以上のことをご理解いただき、新しいセキュリティ脆弱性に対応した製品バージョンがリリースされた際には、出来得る限り速やかにそのバージョンを導入することを推奨致します。

以下の関連情報もぜひご参照ください。

• バグフィックス対応について
• 製品サポート対応について

この連載記事では、InterSystemsデータプラットフォーム用のPython Gatewayについて説明します。 また、InterSystems IRISの最新のAI/MLツールを利用してPythonコードなどを実行します。 このプロジェクトは、InterSystems IRIS環境にPythonの力を与えます。 

• 任意のPythonコードを実行する 
• InterSystems IRISからPythonへのシームレスなデータ転送 
• Python相互運用アダプタでインテリジェントな相互運用ビジネスプロセスを構築する 
• InterSystems IRISからのPythonコンテキストの保存、調査、変更、復元 

索引 

現時点での連載計画です（変更される可能性があります）。

ここ数年の間、ハイパーコンバージドインフラストラクチャ（HCI）ソリューションが勢いを増しており、導入件数が急速に増加しています。 IT部門の意思決定者は、VMware上ですでに仮想化されているアプリケーションなどに対し、新規導入やハードウェアの更新を検討する際にHCIを考慮に入れています。 HCIを選択する理由は、単一ベンダーと取引できること、すべてのハードウェアおよびソフトウェアコンポーネント間の相互運用性が検証済みであること、IO面を中心とした高いパフォーマンス、単純にホストを追加するだけで拡張できること、導入や管理の手順が単純であることが挙げられます。 

この記事はHCIソリューションの一般的な機能を取り上げ、HCIを初めて使用する読者に紹介するために執筆しました。 その後はデータベースアプリケーションの具体的な例を使用し、InterSystems データプラットフォーム上に構築されたアプリケーションを配置する際の、キャパシティプランニングとパフォーマンスに関する構成の選択肢と推奨事項を確認します。 HCIソリューションはパフォーマンスを向上させるためにフラッシュストレージを利用しているため、選択されたフラッシュストレージオプションの特性と使用例に関するセクションも含めています。

この連載記事では、InterSystems IRIS をはじめて操作される方を対象に、IRIS のインストールから、開発環境作成、各種言語からのアクセス方法についてご紹介していきます。

以下3つのビデオは、基本操作をご紹介するビデオです。既にご存知の内容が多い場合は、各種アクセス方法をご紹介するビデオからぜひご参照ください。

基本操作編ビデオシリーズ

• その1：InterSystems IRIS Community Edition をインストールしてみよう！
  • Windows、Linux、クラウドのマーケットプレイス、インターシステムズのプライベートクラウド での InterSytems IRIS Community Edition インストール方法を解説しています。  

• その2：InterSystems IRIS で開発をはじめよう！
  • IRIS で開発を始めるために必要な準備（管理ポータルの使い方、ネームスペースの作成、IDEからIRISへ接続する方法）をご説明しています。 IDE は VS Code ／スタジオの両方の操作方法をご紹介しています。  

• その3：IRIS でクラス定義を作ろう（オブジェクト操作の練習）
  • IRIS でのクラス定義の作成方法、ObjectScript でインスタンスの生成と永続化（保存）の方法について解説しています。

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

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

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

もくじ

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

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

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

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

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

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

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

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

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

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

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

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

もくじ

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

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

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

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

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

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

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

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

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

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

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

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

57:36～最後まで　まとめ

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

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

クラス定義例

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

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

アイリスデータセットのK平均クラスタリング 

みなさん、こんにちは。 今回はアイリスデータセットでk平均アルゴリズムを使用します。 

注意：Ubuntu 18.04、Apache Zeppelin 0.8.0、python 3.6.5で以下を実行しました。 

概要 

K平均法は、クラスタリングの問題を解決する最も単純な教師なし学習アルゴリズムの1つです。 このアルゴリズムは、同じグループ内のオブジェクト（グループはクラスターです）が他のグループ内のオブジェクトよりも（意味的に）互いに類似するようにすべてのオブジェクトをグループ化します。 例えば、緑の芝生に赤いボールのある画像があるとします。 K平均法はすべてのピクセルを2つのクラスターに分割します。 1番目のクラスターにはボールのピクセルが含まれ、2番目のクラスターには芝生のピクセルが含まれます。 

アイリスデータセットは、3種のアイリスの花の特徴をいくつか含むテーブルです。 種には「Iris-setosa」、「Iris-versicolor」、「Iris-virginica」があります。 それぞれの花には5つの特徴（花びらの長さ、花びらの幅、がく片の長さ、がく片の幅、種 ）があります。 

要件の確認 

まず、すべての要件を確認しましょう。 次のように、ターミナルに「which python3」貼り付けてください。

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

優勝特典

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

🥇 1位 - $2,000 

🥈 2位 - $1,000 

🥉 3位 - $500

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

🥇 1位 - $1,000 

🥈 2位 - $500 

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

参加資格

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

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

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

コンテストの課題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

spec.

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

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

2016年10月に編集... 

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

2018年3月に編集... 

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

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

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

- CPU 

- メモリ 

- ストレージIO 

- ネットワークIO 

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

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

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

長い道のりの始まり 

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

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

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

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

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

その他の記事 

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

前のパート（1、2）では、ツリーとしてのグローバルを話題に取り上げました。 この記事では、それらを疎な配列と見なします。 

疎な配列は、ほとんどの値が同一であると想定される配列の種類です。 

疎な配列は実際には非常に大きいため、同一の要素でメモリを占有することには意味がありません。 したがって、疎な配列を整理し、重複した値の格納にメモリが浪費されないようにすることには意味があります。 

疎な配列は、J、MATLABなど一部のプログラミング言語では言語の一部になっています。 他の言語では、疎な配列を使用できるようにする特別なライブラリが存在します。 C++の場合は、Eigenなどがあります。 

次の理由により、グローバルは疎な配列を実装するのに適した候補であると言えます。 

1. 特定のノード値のみを保存し、未定義のノード値を保存しないこと。 

2. ノード値のアクセスインターフェースが、多くのプログラミング言語が多次元配列の要素にアクセスするために提供しているものとよく似ていること。 

Set ^a(1, 2, 3)=5 
Write ^a(1, 2, 3) 

3. グローバルはデータを格納するためにかなり低レベルの構造を採用しているため、優れたパフォーマンス特性を備えていること（ハードウェアによっては毎秒数十万から数千万のトランザクションを処理可能、1をご覧ください）。

先週、私たちはInterSystems IRIS Data Platformを発表しました。これは、トランザクション、分析、またはその両方に関係なく、あらゆるデータの取り組みに対応する新しい包括的なプラットフォームです。 CachéとEnsembleでお客様が慣れ親しんでいる多くの機能が取り込まれていますが、この記事では、プラットフォームの新機能の1つであるSQLシャーディングについてもう少し詳しく説明します。これはスケーラビリティに関する強力な新機能です。 

ちょうど4分41秒の時間がある方は、スケーラビリティに関するこちらの詳しい動画をご覧ください。 ヘッドホンがない方や聞き心地の良いナレーションが同僚の方の迷惑になると思う方は、どうぞ読み進めてください！ 

スケールアップとスケールアウト 

1日に何百万件という株取引を処理する場合でも、1日に数万人の患者を治療する場合でも、このような業務を支えているデータプラットフォームは、こういった大きなスケールに透過的に対処できなければなりません。 「透過的に」というのは、プラットフォームがスケーリングの面を請け負い、開発者やビジネスユーザーは処理量を気にすることなく、それぞれが専門とする業務とアプリケーションに専念することができるという意味です。 

長年にわたり、Cachéは垂直スケーラビリティをサポートしてきました。

最初の記事については、パート1を参照してください。 

3. グローバルを使用する場合のさまざまな構造 

順序付きツリーなどの構造には、さまざまな特殊ケースがあります。 グローバルを使用する上で実用的な価値があるものを見てみましょう。 

3.1 特殊ケース1  - 枝のない1つのノード 

グローバルは配列のようにも、通常の変数のようにも使用できます。 例えば、カウンターを作成する場合を考えてみましょう。 

Set ^counter = 0  ; カウンターの設定 

Set id=$Increment(^counter) ;  アトミックなインクリメント操作 

また、グローバルには値に加えて枝を持たせることができます。 一方が他方を除外することはありません。 

3.2 特殊ケース2  - 1つのノードと複数の枝 

実際、これは典型的なキー・バリューベースのデータ構造です。 また、値の代わりに値のタプルを保存すると、主キーを持つ通常のテーブルが得られます。 

グローバルに基づくテーブルを実装するには、カラムの値から文字列を作成し、主キー別にそれをグローバルに保存する必要があります。 読み取りの時に文字列をカラムに分割できるようにするため、以下のいずれかを使用することができます。

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

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

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

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

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

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

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

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

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

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