以前、Azure用にOAouth2クライアントをセットアップする記事を書いた時に思ったのですが、各IdPはサンプルコードとしてPythonコードや専用のモジュールを提供しているので、それがそのまま使用できれば効率が良いのにな、と思いました。

IRISが埋め込みPython機能としてWSGIをサポートしたことにより、これが簡単に実現しそうなので、その方法をご紹介したいと思います。

導入方法

今回は、IdPとしてOKTAを使用してAuthorization Codeフローを行います。

OKTAでの設定内容

参考までに、今回使用した環境を後半に記載しています。

アプリケーションの起動

コンテナ化してありますので、コンテナのビルド環境をお持ちの方は、下記を実行してください。

git clone https://github.com/IRISMeister/iris-okta-oidc-wsgi
cd iris-okta-oidc-wsgi

python/.env.templateをpython/.envという名前でコピーを作成して、OKTAで得られる設定値を指定してください。

AUTH0_CLIENT_ID="0oaxxxxxxx"  
AUTH0_CLIENT_SECRET="qUudxxxxxxxxxxx"
AUTH0_DOMAIN="dev-xxxxx.okta.com/oauth2/default"

Debeziumをご存じでしょうか？

グローバルサミット2023にて、Debeziumを題材としたセッション「Near Real Time Analytics with InterSystems IRIS & Debezium Change Data Capture」がありましたので、ご覧になられた方もおられるかと思います。

ご興味がありましたら、グローバルサミット2023の録画アーカイブをご覧ください。

FAQによると、"dee-BEE-zee-uhm"(ディビジウム..ですかね)と読むそうです。元素周期表のように複数のDB(s)を束ねる、というニュアンスみたいです。

CDC(Change data capture)という分野のソフトウェアです。

外部データベースでの変更を追跡して、IRISに反映したいという要望は、インターオペラビリティ機能導入の動機のひとつになっています。一般的には、定期的にSELECT文のポーリングをおこなって、変更対象となるレコード群(差分。対象が少なければ全件)を外部システムから取得する方法が、お手軽で汎用性も高いですが、タイムスタンプや更新の都度に増加するようなバージョンフィールドが元テーブルに存在しない場合、どうしても、各ポーリング間で重複や見落としがでないように、受信側で工夫する必要があります。また、この方法ではデータの削除を反映することはできませんので、代替案として削除フラグを採用するといったアプリケーションでの対応が必要になります。

CDCは、DBMSのトランザクションログをキャプチャすることで、この課題への解決策を提供しています。DebeziumはRedHatが中心となっているCDCのオープンソースプロジェクトです。

こちらの内容は、今後のリリースにより変わる(不要になる)可能性があります。

バージョン2023.2以降で、IRISスタジオが非推奨となったこともあり、VSCode拡張機能を評価される方も今後増えるかと思います。

既存のCache'資産をお持ちで、ソース管理をソースコントロールフックで実施されている方などにおかれましては、その際にサーバサイド編集を選択される方もおられるかと思います。

VSCode拡張には、Cache'/IRISスタジオの「ファイルから検索」と同じ要領でサーチを行いたいというご要望に応えるための機能が備わっています。その導入方法が、VSCodeの未公開APIを使用している関係で、ひと手間かかるものとなっているため、解説します。

方法は複数ありますが、手順を簡素化するべく、なるべくGUIを使わない方法をご紹介しています。

導入方法

サーバサイドのサーチ機能は、VSCodeの"Proposed API"であるTextSearchProvider,FileSearchProvideを使用しています。 いずれこれらのAPIが安定化してStableとしてリリースされるまでの措置として、これらを使用している拡張機能はマーケットプレイスからの導入(クリックするだけの簡単インストール)が制限されています。

Azure ADをOPとして利用する

元のタイトルから外れますがAzure ADをOPとした場合に、Wepアプリケーション(CSP)とSPA+BFF形式のRPにどのような修正が必要かを調べました。
ある程度の差異は想定はしていましたが、思っていたより違うな、という印象を受けました。RP、リソースサーバ側でこれらの差異を吸収する必要がありました。

個人調べです。誤りがあるかもしれませんが、その際はご容赦ください。また、状況は刻々と変わる可能性があります。

クライアントアプリケーション編

「IRISだけでoAuth2/OpenID ConnectのSSO/SLO環境を実現する/サーバ編」 のクライアントアプリケーション編です。サーバ編の構成が既に稼働していることを前提にしています。

既にサーバ編でgit clone実行された方(ありがとうございます)、若干の変更がありますのでgit pullと./build.shの実行をお願いします。

oAuth2クライアントアプリケーション(OICD用語ではRP。以下RPと称します)の形態として、5種類用意しています。

PythonやcurlがConfidential(client_secretの秘匿性を十分に保てる)か、というと微妙ですが、あくまで利用者は開発者のみ、という位置づけです。

本記事は、あくまで執筆者の見解であり、インターシステムズの公式なドキュメントではありません。

IRISのoAuth2機能関連の情報発信は既に多数ありますが、本稿では

• 手順(ほぼ)ゼロでひとまず動作させてみる
• 設定の見通しを良くするために、役割ごとにサーバを分ける
• 目に見えない動作を確認する
• クライアント実装(PythonやAngular,CSPアプリケーション等)と合わせて理解する
• シングルサインオン/シングルログアウトを実現する

ということを主眼においています。

コミュニティ版で動作しますので、「とりあえず動かす」の手順に従って、どなたでもお試しいただけます。

現状、使用IRISバージョンはIRIS 2023.1のプレビュー版になっていますが、ソースコードは適宜変更します。

手順に沿ってコンテナを起動すると下記の環境が用意されます。この環境を使用して動作を確認します。

ユーザエージェント(ブラウザ)やPython/curlからのアクセスは、全てApache (https://webgw.localdomain/) 経由になります。青枠の中のirisclient等の文字はコンテナ名(ホスト名)です。

例えば、irisclientホストの/csp/user/MyApp.Login.clsにアクセスする場合、URLとして

 https://webgw.localdomain/irisclient/csp/user/MyApp.Login.cls

と指定します。

つまり、各エンドポイントは同一のorigin (https://webgw.localdomain) を持ちます。そのため、クロスサイト固有の課題は存在しません(カバーされません)が、仮に各サーバが別のドメインに存在しても基本的には動作するはずです。

oAuth2/OIDC(OpenID Connect)の利用シーンは多種多様です。

本例は、認証・認可サーバ,クライアントアプリケーション,リソースサーバの全てがIRISで実行されるクローズドな環境(社内や組織内での使用)を想定して、認可コードフロー(Authorization Code Flow)を実現します。分かりやすい解説が、ネットにたくさんありますので、コードフロー自身の説明は本稿では行いません。

認証・認可サーバの候補はIRIS, WindowsAD, Azure AD, AWS Cognito, Google Workspace, keycloak, OpenAMなどがあり得ます。個別に動作検証が必要です。

クライアントアプリケーション(RP)は、昨今はSPAが第一候補となると思いますが、利用環境によっては、SPA固有のセキュリティ課題に直面します。

IRISには、Confidential Clientである、従来型のWebアプリケーション(フォームをSubmitして、画面を都度再描画するタイプのWebアプリケーション)用のoAuth2関連のAPI群が用意されています。

そこで、Webアプリケーション(CSP)を選択することも考えられますが、クライアント編では、よりセキュアとされるSPA+BFF(Backend For Frontend)の構成を実現するにあたり、Webアプリケーション用APIをそのまま活用する方法をご紹介する予定です。

以下、サーバ編の動作確認には、CSPアプリケーションを使用しています。これは、新規開発にCSP(サーバページ)を使用しましょう、という事ではなく、BFF実現のために必要となる機能を理解するためです。BFFについては、クライアント編で触れます。BFFについては、こちらの説明がわかりやすかったです。

リソースサーバの役割はデータプラットフォームであるIRISは最適な選択肢です。医療系用のサーバ機能ですがFHIRリポジトリはその良い例です。本例では、至極簡単な情報を返すAPIを使用しています。

少しの努力でFHIRリポジトリを組み込むことも可能です。

サーバ編とクライアント編に分けて記載します。今回はサーバ編です。

とはいえ、クライアントとサーバが協調動作する仕組みですので、境界は少しあいまいです

オリジナルの「InterSystems IRIS で Python を使って IMAPクライアントを実装する」は、埋め込みPythonを使用してIMAPインバウンドアダプタを実装されていますが、最近メールプロバイダがあいついでoAuth2認証しか受け付けなくなってきているので、その対応をしてみました。

本稿のGitHubはこちらです。

変更点

GMAILに対してメールの送受信を可能とするためにオリジナルに以下の修正を施しています。

1. IMAP(Python版)インバウンドアダプタにoAuth2認証およびRefreshTokenによるAccessTokenの更新を追加
2. oAuth2認証およびRefreshTokenによるAccessTokenの更新機能を持つSMTPアウトバウンドアダプタを新規作成
3. IMAPにバイナリの添付ファイルの処理を追加
4. メッセージ削除に、推奨APIであるclient.uid("STORE")を使用するように変更
5. ClientIdなど、センシティブな情報をコンテナ起動時に動的に適用するように変更
6. 日本語使用時の文字化けに対処

3.添付ファイルが存在する場合、追加設定/ファイル・パスで指定したファイルパス(既定値は/var/tmp/)上に保存します。

IRISリリース2022.1のご紹介

本稿は、「InterSystems IRIS、IRIS for Health、HealthShare Health Connect 2022.1がリリースされました！」でご案内している内容を、補足解説する内容となります。

紹介ビデオ

米国本社プロダクトマネージャーによる本リリースのハイライトのご紹介ビデオ(英語)です。 https://www.intersystems.com/resources/whats-new-in-intersystems-iris-2022-1

リリース内容

年一度のEMリリースです。

• メンテナンスアップデート提供:リリース日から2年間

• セキュリティアップデート提供:リリース日から4年間

• InterSystems IRIS, InterSystems IRIS for Health

• 同時期にリリースされるモジュール

  ICM, IKO, InterSyetms Reports, InterSystems Studio

• 独立してリリースされるモジュール

  IAM, SAM, 各種ドライバ類, VS Code ObjectScript 拡張

プラットフォーム

目的

Japan Virtual Summit 2021で、Kubernetesに関するセッションを実施させていただいたのですが、AzureのアカウントやIRIS評価用ライセンスキーをお持ちの方が対象になっていました。もう少し手軽に試してみたいとお考えの開発者の方もおられると思いますので、本記事では仮想環境でも利用可能なk8sの軽量実装であるmirok8sで、IRIS Community Editionを稼働させる手順をご紹介いたします。

2022/1/7 若干の加筆・修正しました

マルチノード化する手順はこちらに記載しています。

目的

CloudFormationの記事は、Linux系のものが多いですが、Windowsでも自動化したいという需要がありそうですので、オリジナル記事を元に、CloudFormationを使用してミラークラスターをWindowsサーバにデプロイする例を実装してみました。また、簡単な実行例も追加しました。
ソースコード一式はこちらのGitレポジトリにあります。

更新: 2021年3月1日 ワンライナーで踏み台ホスト経由でWindowsに公開鍵認証する方法を追記しました

更新: 2022年11月29日 QuickStartの形式に合わせて大幅に変更しました。以前の内容はこちらに保存してあります。

更新: 2022年12月21日 踏み台ホストの使用を止め、代わりにAWS System Manager(SSM)を有効化しました。プライベートサブネット上のインスタンスへのアクセスが簡素化されます。以前の内容はこちらに保存してあります。

この記事は、GitHub Actions を使って GKE に InterSystems IRIS Solution をデプロイするの継続記事で、そこではGitHub Actions パイプラインを使って、 Terraform で作成された Google Kubernetes クラスタにzpm-registry をデプロイしています。 繰り返しにならないよう、次の項目を満たしたものを開始点とします。

訳者注) 上記の記事を読まれてから、本記事に進まれることをお勧めしますが、GKE上のサービスにドメイン名を紐づける方法を解説した単独記事としてもお読みいただけます。

この記事では、OData API 標準に基づいて開発された RESTful API サービスを利用するための IRIS クライアントの開発について説明します。

HTTP リクエストを作成し、JSON ペイロードの読み取りと書き込みを行い、それらを組み合わせて OData 用の汎用クライアントアダプタを構築する方法を確認するため、多数の組み込み IRIS ライブラリを説明します。 また、JSON を永続オブジェクトに逆シリアル化するための新しい JSON アダプタについても説明します。

RESTful API の操作

REST は World Wide Web の標準化に関する作業から作成された一連の設計原則です。 これらの原則はあらゆるクライアントサーバー通信に適用でき、HTTP API が RESTful であることを説明するためによく使用されます。

REST はステートレスなリクエスト、キャッシュ処理、統一した API 設計など、さまざまな原則を網羅しています。 ただし、詳細な実装については網羅していません。また、これらのギャップを埋めるための一般的な API 仕様は存在しません。

リモートや在宅での勤務が一般化しつつあります。

そのため、今までの集中型、オンサイトの開発体制を見直し、分散型の開発体制への移行を進めておられるユーザさんも多いのではないかと思います。

VSCodeを使用したIRISアプリケーションの開発が、コミュニティーを中心に広まり始めて久しいですが、Gitとの相性が良いこの開発ツールが今後さらに浸透していくことは間違いありません。あちらこちらで、その使いまわし方が語られていますが、ここでは、ソースコントロールとの関連を中心にご紹介したいと思います。

ObjectScript Extensionの使い方の基本については、こちらやこちらをご覧ください。

 VSCode InterSystems ObjectScript Extensionのプロダクションリリース(V1.0.x)の配布が始まりました。  

これに合わせて、今までのコミュニティーサポートに加え、InterSystemsによる公式サポートもアナウンスされています。よりいっそう安心してご利用いただけるようになりました。

目的

本記事について

InterSystems IRISをモニタリングする方法はいくつかあります。

• SNMP
• システムモニターとemail通知機能
• 管理ポータルのシステムダッシュボード
• Prometheus+Grafanaを使用
• InterSystems SAM (System Alerting and Monitoring)

本記事では上記に加えてAWSにIRISをデプロイする場合に自然な選択子となりうる方法として、CloudWatchを使用する方法をご紹介します。

AWSネイティブの各種サービスとIRISを連携させる方法の典型のご紹介を兼ねています。

内容は、Open Exchangeで公開されています。日本語のREADMEがありますのでそちらをご覧ください。
README.MDからの引用

InterSystems IRISの各種メトリクスとログをAWS CloudWatchに簡単に公開することができます。
これらメトリクスとログがあれば、IRISのデータをダッシュボードやアラートなどに統合することができます。

本稿について

ICM(InterSystems Cloud Manager)のセットアップは難しいものではありませんが、様々な理由でそもそもDockerが使いづらいという状況があり得ます。
また、セキュリティ的に堅固な環境を得るために、既存VPC内のプライベートサブネット上にIRISクラスタをデプロイする方法のひとつに、同VPC内でICM実行する方法があります。
本稿では、ICMをAWSにデプロイする作業を、CloudFormationで自動化する方法をご紹介します。ICMに関しては、こちらの記事をご覧ください。

更新: 2020年11月24日  デフォルトVPC以外でも動作するよう変更しました。

本稿について

本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。 Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。

メモリ自動設定をやめる

パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。

更新: 2020年11月20日   バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。

搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。

設定するにはiris停止状態で、iris.cpfファイル(IRISインストール先\mgr\iris.cpf)を変更します。下記はブロックサイズ8KB用(既定値です)のデータベースバッファサイズの自動構成を4096(MB)に変更する例です。

修正前

[config]
globals=0,0,0,0,0,0

修正後

[config]
globals=0,0,4096,0,0,0

詳細はこちらです。

本記事について

InterSystems IRISは、管理ポータルへのアクセス方法がデフォルトではhttpとなっており、クライアントが社内、サーバがクラウドという配置の場合、なんらかの方法でトラフィックを暗号化したいと考える方も多いかと思います。
そこで、AWS上にて稼働中のIRISの管理ポータル(あるいは各種RESTサービス)との通信を暗号化する方法をいくつかご紹介したいと思います。

本記事では、アクセスにIRIS組み込みのapacheサーバを使用しています。ベンチマーク目的や本番環境のアプリケーションからのアクセス方法としては使用しないでください。
短期間・少人数での開発・動作検証・管理目的でのアクセスを暗号化する事を想定しています。

ドメイン名とメジャーな認証局発行のSSLサーバ証明書を用意できればベストなのですが、上記のような用途の場合、コスト面でなかなか難しいと思います。
ですので、下記の証明書の使用を想定しています。
- 自己署名(いわゆるオレオレ証明書)
- 自分で建てた認証局で署名した証明書(いわゆるオレオレ認証局)

また、下記のような実行環境を想定しています。

この記事ではVMware ESXi 5.5以降の環境にCaché 2015以降を導入する場合の構成、システムのサイジング、およびキャパシティ計画のガイドラインを示します。 

ここでは、皆さんがVMware vSphere仮想化プラットフォームについてすでに理解していることを前提としています。 このガイドの推奨事項は特定のハードウェアやサイト固有の実装に特化したものではなく、vSphereの導入を計画して構成するための完全なガイドとして意図されたものでもありません。これは、皆さんが選択可能なベストプラクティス構成をチェックリストにしたものです。 これらの推奨事項は、皆さんの熟練したVMware実装チームが特定のサイトのために評価することを想定しています。 

InterSystems データプラットフォームとパフォーマンスに関する他の連載記事のリストはこちらにあります。 

注意: 本番データベースインスタンス用のVMメモリを予約し、Cachéに確実にメモリを使用させてデータベースのパフォーマンスに悪影響を与えるスワップやバルーニングの発生を防ぐ必要があることを強調するため、この記事を2017年1月3日に更新しています。 詳細については、以下のメモリセクションを参照してください。 

参考情報 

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

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

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

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

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

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

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

前回の記事では、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é）を指しています。 

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

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

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

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

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

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

spec.orgのベンチマークを使ったCPUパフォーマンスの比較 

前回の投稿では、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キャパシティプランニング 

その他の記事 

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

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

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

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

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

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

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

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