検索

1. ブロックチェーン この記事を書いている時点(2019年2月)で、ビットコインの価値はそれが絶頂期だったころの 5 分の 1 未満に下落しています。 そのため、ブロックチェーンの私の体験について誰かに話すときに最初に耳にするのは、「今頃ブロックチェーンを欲しがる人がいるのか」という偽りなく懐疑的な言葉です。 その通り。ブロックチェーンの盛り上がりは衰退しています。 ところが、それが基づいているテクノロジーはここにとどまり、特定の分野で使用され続けるでしょう。一般的にインターネットではこのテクノロジーの使用方法が記述された資料でいっぱいです。  （たとえば[medium](https://medium.com/@matteozago/50-examples-of-how-blockchains-are-taking-over-the-world-4276bf488a4b) と [forbes](https://www.forbes.com/sites/bernardmarr/2018/05/14/30-real-examples-of-blockchain-technology-in-practice/#23a4daed740d) に掲載されています）。 ご存知のように、ブロックチェーンは分散レジストリ、すなわち、レジストリの完全なコピーを格納している複数のノードに分散されたデータベースです。 レコード（トランザクション）がブロックを形成し、ブロックがブロックのチェーンを形成するところに、ブロックチェーンの鍵となる機能があります。 ブロックチェーンはアペンド演算のみをサポートしているため、 ブロックチェーンにすでに保存されたトランザクションに変更を加えることは、ほぼ不可能ということになります。 ブロックチェーンに関するチュートリアルはインターネット上にたくさんあります（ブロックチェーンについて聞いたことがない方は、[こちらの簡単な動画](https://www.youtube.com/watch?v=SSo_EIwHSd4)をまずご覧ください）。 ブロックチェーンが順調な成果を見せていた時、文字通りどこにでも、そのテクノロジーを使用するための呼び出しが複数ありました。 ただし、ブロックチェーンが必要となる可能性のあるプロジェクトやタスクには、明確な特性があります。 まず第一に、一貫性と信頼性のある大量のデータを書き込むプレーヤー/ユーザーがたくさん存在する必要がある点です。 そうであれば、誰もが信頼するサードパーティは存在しないはずです。 公開データ検証の仕組みが必要となります。 こういった条件のすべてを満たす場合、ブロックチェーンの使用を検討するのも良いかもしれません。 こういったタスクは、どの業界にも見られます。 [www.101blockchains.com](http://www.101blockchains.com/) プロジェクトでは、潜在的および既存のブロックチェーンプロジェクトに関する情報と、様々な業界でブロックチェーンテクノロジーを使用するニュアンスを集約しています。 たとえば、ブロックチェーンは、ヘルスケアの分野で次のタスクに使用することができます。 患者記録の安全なリモート管理 サプライチェーン全体で変更不可能なトランザクションによる、偽造医薬品への対策 詐欺やデータ改ざんの可能性の排除による、臨床試験の監視と有効性の改善 企業部門は通常、プライベート許可型ブロックチェーンと呼ばれる特殊なブロックチェーンを使用しています。 このようなネットワークには、トランザクションを検証するための特別なノードセットがあります。 しかし、最初の InterSystems IRIS ブロックチェーンアダプターを開発する際、非許可型ブロックチェーンに区分されるイーサリアムという種類のブロックチェーンを選択しました。イーサリアムは、単一のコントロールセンターを持たないオープンプラットフォームです。 これは、このブロックチェーンエンジンの人気と、多くのツールやライブラリを備え、十分に成熟したインフラストラクチャであることを基に採用しました。 イーサリアムのツールを使えば、誰でもプライベートブロックチェーンを作成することができます。 2. アダプター では、アダプターの話に戻りましょう。 InterSystems IRIS のアダプターは（Ensemble でも同様に）、外部システムと対話可能にする InterSystems IRIS クラスのクラスまたはパッケージです。 InterSystems IRIS アダプターは、インバウンド（外部システムが対話を開始した場合に外部システムからデータを受信）とアウトバウンド（InterSystems IRIS が対話を開始した場合に外部システムと連携）に分けられます。 IRIS Ethereum アダプターはアウトバウンドアダプターであり、ほかのほとんどの InterSystems IRIS アダプターとはわずかに異なります。 このアダプターには、小さな NodeJS モジュールも含まれています。 図 1 はこのアーキテクチャを示しています。 図 1. アダプターの NodeJS モジュールではイーサリアムと連携するための NodeJS ライブラリを使用します。 アダプターは次のことを行います。 スマートコントラクトをイーサリアムにデプロイする（スマートコントラクト、開発ツール、および例を網羅した記事を別途掲載する予定です）。 スマートコントラクトのメソッド（ブロックチェーンの状態を変更するメソッドと変更しないメソッド）を呼び出す。 トランザクションを保存する（ウォレット間で資金を送金する）。 ブロックチェーンの状態を取得するほかのメソッドを呼び出す。 すべてのリクエストをログに記録する（NodeJS モジュールによって行われ、デバッグに有効）。 OpenExchange上のアダプターのソースコード。 3. 簡単な例 アダプターには「Hello World」サンプルが付属しています。 イーサリアムを使用するには（このサンプルを実行するには）以下の作業を行います。 使用するネットワークを選択します。 Ropsten などのテストネットワークは通常、開発目的で使用できます。 このネットワークにウォレットを作成して、資金を追加します。 ローカルイーサリアムクライアント（ Geth など）をインストールするか、クラウドプロバイダー（ Infura など）と連携するための鍵を取得します。 ビジネスオペレーションを構成する際は、次の項目を設定する必要があります（図 2）。 NodeJS モジュールが動作するサーバーとポート（デフォルトポートは 3000 ） プロバイダーの設定（この場合、Infura へのアクセス） ログイン情報（ユーザー名にウォレット番号、パスワードに秘密鍵を指定します。 InterSystems IRIS はログイン情報を別のデータベースに保存します。このデータベースは、暗号化を有効にする必要があります。） 図 2. スマートコントラクトを使用するには、ファイルシステム内に（使用するスマートコントラクトごとに）フォルダを作成し、次の 2 つのファイルを配置する必要があります。*abi.txt*bytecode.txt これらのファイルには、スマートコントラクトの ABI とそのバイトコードが含まれている必要があります。 スマートコントラクトの ABI は、JSON 形式によるインターフェースの正式な記述です。 ABI とバイトコードは、スマートコントラクトのコンパイル時に作成されます。 バイトコードは、コントラクトのデプロイに必要です。 InterSystems IRIS 相互運用性テストサービスを使用して、ビジネスオペレーションをテストできます。 図 3 では、テストサービスを使用してどのようにスマートコントラクトがデプロイされるのかを示しています。 このビジネスオペレーションを呼び出すと、トランザクションのハッシュを含むメッセージが結果として返されます。 図 3. ropsten.etherscan.io（https://etherscan.io/）ブラウザを使用してこのトランザクションを見つけ、デプロイされたスマートコントラクトのアドレスを取得できます。 アダプターを使用してスマートコントラクトのメソッドを呼び出すには、運用構成の ContractFolder と ContractAddress フィールドに入力する必要があります。 スマートコントラクトの実行コードは非常に単純です。 set ..ContractABI = [].%FromJSON(..ContractFolder_"abi.txt") set contract = ..Adapter.GetContract(##class(Ethereum.Address).%New(..ContractAddress),..ContractABI) set result = contract.hello() set pResponse = ##class(Ens.StringContainer).%New(result.args) スマートコントラクトのアドレスと ABI をアダプターの GetContract メソッドに渡し、メソッドを呼び出すために使用するスマートコントラクトオブジェクトを作成します。 この場合、文字列を返す hello() メソッドはスマートコントラクトで定義されている必要があります。 この例では、hello() メソッドはブロックチェーンの状態を変更しないため、同期的に呼び出すことができますが、 ブロックチェーンの状態を変更するメソッドの実行時間は非常に長くなることがあります（トランザクションの検証を待つ必要があるため）。 このようなメソッドを呼び出すには、InterSystems IRIS が提供する遅延応答の仕組みを使用します。 アダプターは遅延応答トークンを送信する必要があり、トランザクションが承認されると、NodeJS モジュールはその実行結果を InterSystems IRIS に渡します。 これを行うには、Web アプリケーションを構成し、受信した応答を処理する追加のビジネスサービスを運用に追加する必要があります。 以下は、ブロックチェーンの状態を変更するメソッドを呼び出すためのコードです。 // EthereumAccount（ウォレット）と privateKey の取得 do ##class(Ens.Config.Credentials).GetCredentialsObj(.cred, "Ethereum.Demo.EthereumOperation", "Ens.Config.Credentials", ..Credentials) set account = ##class(Ethereum.Address).%New(cred.Username) set privateKey = cred.Password //コントラクト ABI の読み取り set ..ContractABI = [].%FromJSON(..ContractFolder_"abi.txt") // コントラクトオブジェクトの取得 set contract = ..Adapter.GetContract(##class(Ethereum.Address).%New(..ContractAddress),..ContractABI) $$$ThrowOnError(..DeferResponse(.deferred)) // gas の推定 do contract.SetOptions(account) set gasJSON = contract.EstimateGas("setName",pRequest.Name) $$$TRACE(gasJSON.gas) do contract.SetOptions(account, privateKey,  ##class(Ethereum.Wei).%New(1000000000), ##class(Ethereum.Wei).%New(100*gasJSON.gas),,deferred) set result = contract.setName(pRequest.Name) この場合、スマートコントラクトの setName() メソッドを呼び出す前に、遅延応答トークンを含む多数のパラメーターを指定する必要があります。 次の記事では、スマートコントラクトについて詳しく説明し、InterSystems IRIS Ethereum アダプターを使って実際の問題を解決する例を示します。

*この動画は、2021年2月に開催された「InterSystems Japan Virtual Summit 2021」のアーカイブです。 ソフトウェア開発技術において、プロセスの自動化、サイクルの短縮による生産性の向上を目指す考え方が普及してきました（CI/CD）。CI/CDの中核をなす技術の一つが、Dockerに代表されるコンテナです。 InterSystemsでは、Dockerコンテナで動作するIRIS data platformをリリースして、いち早く最新機能を皆様にお届けしています。この動画をご覧になって、DockerコンテナでIRISをスムーズに利用する第一歩としてください。 セッションで紹介しているリリースサイクルについては、こちらの記事をご覧ください。セッションではデモを行っています。デモをご覧になりたい方は 12:49​ からご覧ください。

InterSystems および Intel は先日、InterSystems IRIS を「Cascade Late」としても知られる第 2 世代 Intel® Xeon® スケーラブルプロセッサおよび Intel® Optane™ DC パーシステントメモリ（DCPMM）と組み合わせて一連のベンチマークを実施しました。 さまざまなワークロード設定とサーバー構成で、Intel の最新のサーバーテクノロジーを使用した InterSystems IRIS のパフォーマンスとスケーラビリティ機能を実証するのがこのベンチマークの目的です。 このレポートには、さまざまなベンチマークの結果とともに、Intel DCPMM と InterSystems IRIS のユースケースが 3 つ示されています。 ## 概要 パフォーマンスとスケーリングを実証するために 2 種類のワークロードが使用されています。読み取り集中型のワークロードと書き込み集中型のワークロードです。 このように分けて実証するのは、読み取り集中型ワークロードにおけるデータベースキャッシュ効率の増加と、書き込み集中型ワークロードにおけるトランザクションジャーナルの書き込みスループットの増加のそれぞれに特化したユースケースで、Intel DCPMM の影響を示すためです。 両方のユースケースシナリオにおいて、InterSystems IRIS のスループット、スケーラビリティ、およびパフォーマンスの大幅なゲインが達成されています。 * **読み取り集中型ワークロード**では、4 ソケットサーバーと、合計約 1.2 TB のデータを持つデータセットを使用する大量の長期実行分析クエリが使用されました。 DCPMM を「Memory Mode」で使用した場合のベンチマーク比較では、メモリの少ない前世代の Intel E7v4 シリーズプロセッサと比べた場合、経過実行時間が大幅に短縮され、およそ 6 倍高速になりました。 E7v4 と、DCPMM を使った最新のサーバーを同じメモリサイズで比較した場合は、20% の改善が見られました。 これは、DCPMM による InterSystems IRIS データベースキャッシュ機能の向上と最新の Intel プロセッサアーキテクチャによるものです。 * **書き込み集中型ワークロード**では、2 ソケットサーバーと InterSystems HL7 メッセージングのベンチマークが使用されました。多数のインバウンドインターフェースで構成されており、各メッセージには複数の変換が伴い、インバウンドメッセージごとに 4 つのアウトバウンドメッセージが使用されています。 高スループットを維持する上で重要なコンポーネントの 1 つは、IRIS for Health のメッセージ耐久性保証で、その操作においては、トランザクションのジャーナル書き込みのパフォーマンスが重要となります。 「APP DIRECT」モードで DCPMM を使用して、DAX XFS でトランザクションのジャーナル用の XFS ファイルシステムを提供した場合、このベンチマークのメッセージスループットには 60% の向上が示されました。 テスト結果と構成を要約すると、DCPMM は適切に設定された InterSystems IRIS とワークロードで使用された場合にスループットを大幅に向上させることができます。 高レベルのメリットとしては、読み取り集中型ワークロードではデータベースのキャッシュ効率の向上とディスク I/O ブロック読み取りの抑制、書き込み集中型ワークロードではジャーナルの書き込みスループットの向上を得られます。 さらに、古いハードウェアを更新し、パフォーマンスとスケーリングの改善を検討しているユーザーにとって、DCPMM を備えた Cascade Lake に基づくサーバーは優れた更新パスとなります。 InterSystems のテクノロジーアーキテクトと相談しながら、既存のワークロードに推奨される構成についてのアドバイスを得ることができます。 * * * ### 読み取り集中型ワークロードベンチマーク 読み取り集中型ワークロードでは、512 GiB と 2 TiB のデータベースキャッシュサイズの E7v4（Broadwell）と Intel® Optane™ DC パーシステントメモリ（DCPMM）を使用した 1 TB と 2 TB のデータベースキャッシュサイズの最新の第 2 世代 Intel® Xeon® スケーラブルプロセッサ（Cascade Lake）と比較する分析クエリベンチマークを使用しました。 より大規模なキャッシュの影響とパフォーマンスの向上を示すために、さまざまなグローバルバッファサイズで複数のワークロードを実行しました。 構成を反復するごとに、COLD と WARM で実行しています。 COLD は、データベースキャッシュにデータが事前に入力されていない場合で、 WARM は、データベースキャッシュがすでにアクティブになっており、ディスクからの物理的な読み取りを減らすために、データが入力済みである（または少なくと可能な限り入力されている）ことを示します。   #### ハードウェア構成 古い 4 ソケット E7v4（Broadwell）ホストを DCPMM を使った 4 ソケット Cascade Lake サーバーと比較しました。 この比較が選択されたのは、InterSystems IRIS を使ってハードウェアの更新を検討している既存のお客様がパフォーマンスの向上を得られることを実証するためです。 バージョン間のソフトウェアの最適化が要因とならないように、すべてのテストには同じバージョンの InterSystems IRIS が使用されました。 ディスクパフォーマンスが比較の要因とならないように、すべてのサーバーには同一のストレージアレイにある同一のストレージが使用されています。 ワーキングセットは 1.2 TB のデータベースです。 図 1 にはこのハードウェア構成と、それぞれの 4 ソケット構成の比較が示されています。 図 1: ハードウェア構成 | サーバー #1 の構成 | サーバー #2 の構成 | | ------------------------------------- | ------------------------------------ | | プロセッサ: 4 x E7-8890 v4 @ 2.5Ghz | プロセッサ: 4 x Platinum 8280L @ 2.6Ghz | | メモリ: 2TiB DRAM | メモリ: 3TiB DCPMM + 768GiB DRAM | | ストレージ: 16Gbps FC all-flash SAN @ 2TiB | ストレージ: 16Gbps FC all-flash SAN @ TiB | |   | DCPMM: Memory Mode のみ |   #### ベンチマークの結果と結論 512 GiB を 1 TiB か 2 TiB のいずれかの DCPMM バッファプールサイズと比較した場合、経過実行時間に大幅な短縮が見られます（約 6 分の 1）。 さらに、2 TiB E7v4 DRAM と 2 TiB Cascade Lake DCPMM の構成を比較した場合には約 20% の改善も見られました。 バッファプールのサイズが同じであるとした場合、この 20% の増加は、ほぼ新しいプロセッサのアーキテクチャとプロセッサのコア数の増加によるものだと考えられますが、 それでも、テストされた 4 ソケット Cascade Lake にインストールされていたが 24 x 128 GiB DCPMM のみであることを考慮すると深い意義があります。DCPMM は 12 TiB までスケーリングすることが可能であり、これは E7v4 が同じ 4 ソケットサーバーのフットプリントでサポートできるメモリの約 4 倍のメモリです。 以下の図 2 に示されるグラフは、この比較の結果を示しています。 両方のグラフの y 軸は経過時間（値が小さくなるほど良）で、さまざまな構成で得た結果が比較されています。   ##### 図 2: 各種構成の経過時間の比較  * * * ### 書き込み集中型ワークロードベンチマーク このベンチマークのワークロードは、すべての T4 タイプのワークロードを使用した HL7v2 メッセージングワークロードです。 * _T4 ワークロードは、ルーティングエンジンを使って、個別に変更されたメッセージを 4 つの各アウトバウントインターフェースにルーティングしました。 平均して、インバウンドメッセージの 4 つのセグメントが変換ごとに変更されました（4 つの変換で 1 件につき 4 件）。 各インバウンドメッセージでは、4 つのデータ変換の実行により 4 つのメッセージがアウトバウンドに送信され、5 つの HL7 メッセージオブジェクトがデータベースに作成されました。_ 各システムは 128 個のインバウンドビジネスサービスと各インバウンドインターフェースに送信される 4800 件のメッセージ（インバウンドメッセージ合計 614,400 件、アウトバウンドメッセージ合計 2,457,600 件）で構成されています。 このベンチマークワークロードのスループットの単位は「1秒あたりのメッセージ数」です。 トランザクションジャーナルのスループットとレイテンシは高スループットを維持する上で重要なコンポーネントであるため、ベンチマーク実行中のジャーナルの書き込みにも関心があります（記録されています）。 IRIS for Health のメッセージ耐久性保証のパフォーマンスに直接影響を与えるため、その操作において、トランザクションジャーナルの書き込みパフォーマンスが重要となります。 ジャーナルのスループットが低下すると、アプリケーションプロセスによってジャーナルバッファの可用性が阻止されてしまいます。   #### ハードウェア構成 書き込み集中型ワークロードでは、2 ソケットサーバーを使用することにしました。 192 GB の DRAM と 1.5 TiB の DCPMM しかないため、この構成は前述の 4 ソケット構成よりも小さくなります。 DCPMM を使用した Cascade Lake のワークロードを以前の初代 Intel® Xeon® スケーラブルプロセッサ（Skylake）サーバーに比較しました。 両サーバーには 750GiB Intel® Optane™ SSD DC P4800X ドライブがローカル接続されています。 図 3 にはこのハードウェア構成と、それぞれの 2 ソケット構成の比較が示されています。 図 3: 書き込み集中型ワークロードのハードウェア構成 | サーバー #1 の構成 | サーバー #2 の構成 | | ------------------------------------- | ------------------------------------ | | プロセッサ: 2 x Gold 6152 @ 2.1Ghz | プロセッサ: 2 x Gold 6252 @ 2.1Ghz | | メモリ: 192GiB DRAM | メモリ: 1.5TiB DCPMM + 192GiB DRAM | | ストレージ: 2 x 750GiB P4800X Optane SSD | ストレージ: 2 x 750GiB P4800X Optane SSD | |   | DCPMM: Memory Mode ＆ App Direct モード | #### ベンチマークの結果と結論 テスト 1: このテストでは、図 3 のサーバー #1 構成に示される Skylake サーバーにおいて前述の**_T4 ワークロード_**を実行しました。 Skylake サーバーは、2010 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 3355 件のインバウンドメッセージの持続的なスループットを示しました。 テスト 2: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて、DCPMM の _**Memory Mode**_ を指定して同じワークロードを実行しました。 これは、2400 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4684 件のインバウンドメッセージの持続的なスループットという大幅な向上を示しました。 **これは、テスト 1 に比較すると 39% の増加です。** テスト 3: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、DCPMM による何らかの実行を構成せずに実行しました。 このテストの目的は、DRAM のみを使用した Cascade Lake のパフォーマンスとスループットを DCPMM と DRAM を使用した Cascade Lake に比較して測定することです。 DCPMM が使用されていない場合でもスループットは（比較的小さいとは言え）向上したという、特に驚くことでもない結果が出ました。 これは、2540 ジャーナル書き込み/秒のジャーナルファイル書き込み速度で約 4845 件のインバウンドメッセージの持続的なスループットという向上を示しました。 DCPMM は DRAM に比べてより高いレイテンシがあり、更新が大量に流入すればパフォーマンスが低下するため、予想された動作と言えます。 別の見方をすると、まったく同じサーバーで DCPMM を Memory Mode で使用する場合、書き込みの取り込みワークロードに 5% 未満の低下があることになります。 また、Skylake を Cascade Lake（DRAM のみ）に比較した場合、**テスト 1 の Skylake サーバーに比べて 44% の増加が得られています。** テスト 4: このテストでは、図 3 のサーバー #2 構成に示される Cascade Lake サーバーにおいて同じワークロードを実行しましたが、今度は DCPMM を App Direct Mode に指定し、App Direct Mode をジャーナルファイルシステム用にマウントされた DAX XFS として使用して実行しました。 これは 2630/秒のジャーナルファイル書き込み速度で 1 秒あたり 5399 件のインバウンドメッセージというさらに高いスループットを示しました。 この種のワークロードでは App Direct Mode の DCPMM がより適した DCPMM の使用方法であることが示されています。 これらの結果を最初の Skylake 構成と比較すると、**テスト 1 の Skylake サーバーに比べ、スループットが 60% 増加しています。**    * * * ## InterSystems IRIS の推奨される Intel DCPMM ユースケース Intel® Optane™ DC パーシステントメモリを使用することで InterSystems IRIS にメリットが与えられるユースケースと構成にはいくつかあります。 ### Memory Mode このモードは、単一の InterSystems IRIS デプロイや大規模な InterSystems IRIS シャードクラスタでの膨大なデータベースキャッシュに最適です。後者の環境ではより多く（またはすべて）のデータベースをメモリにキャッシュできます。 DCPMM と DRAM の比率は最大 8:1 にすることをお勧めします。「ホットメモリ」を L4 キャッシュレイヤーとして機能する DRAM に保持する際に重要です。 これは、リソース占有やその他のメモリキャッシュラインなど、共有内部 IRIS メモリ構造において特に重要となります。      ### App Direct Mode（DAX XFS）– ジャーナルディスクデバイス このモードは、DCPMM をトランザクションジャーナルファイルのディスクデバイスとして使用する場合に最適です。 DCPMM は Linux にマウントされた XFS ファイルシステムとしてオペレーティングシステムに表示されます。 DAX XFS を使用するメリットは、これによって PCIe バスのオーバーヘッドとファイルシステムからのダイレクトメモリアクセスが緩和されることにあります。 HL7v2 ベンチマークの結果に示されるように、書き込みレイテンシによって HL7 メッセージングのスループットは大幅に向上します。 また、ストレージには従来のディスクデバイスと同様に、再起動や電源サイクル時における永続性と耐久性が備わっています。      ### App Direct Mode（DAX XFS）– ジャーナル + 書き込みイメージジャーナル（WIJ）ディスクデバイス このユースケースでは、App Direct モードの用法がトランザクションジャーナルと書き込みイメージジャーナル（WIJ）の両方に拡張されます。 両ファイルは書き込み集中型であるため、超低レイテンシと永続性のメリットを確実に得られます。      ### Dual Mode: Memory + App Direct Modes DCPMM を Dual Mode で使用すると DCPMM のメリットが拡大し、トランザクションジャーナルや書き込みイメージジャーナルデバイスで大規模なデータベースキャッシュと超低レイテンシを実現できるようになります。 このユースケースでは、DCPMM は OS にマウントされた XFS ファイルシステムとオペレーティングシステムの RAM として表示されます。 これは、DCPMM の一定の割合を DAX XFS に割り当て、残りを Memory Mode に割り当てることで可能です。 前述のように、インストールされている DRAM はプロセッサの L4 のようなキャッシュとして機能します。      ### 「疑似」Dual Mode 疑似 Dual Mode 寄りにユースケースモデルを拡張するために、OLTPタイプのワークロード用と分析または大規模なクエリーニーズ用に高速のインバウンドトランザクションと更新が伴うトランザクションと分析の並行ワークロード（HTAP ワークロードとしても知られています）タイプのワークロードがあり、さらに [InterSystems IRIS 共有クラスタ](https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GSCALE_sharding#GSCALE_sharding_reference_plan)内ではそれぞれの InterSystems IRIS ノードタイプが DCPMM のさまざまなモードで稼働しています。 この例では、グローバルバッファの大規模データベースキャッシュと、トランザクションワークロード用に DAX XFS として Dual Mode または App Direct のいずれかで実行する[データノード](https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GSCALE_sharding#GSCALE_sharding_reference_plan_basic)のメリットを得られるように、DCPMM Memory Mode で実行する大規模なクエリ/分析ワークロードを処理する InterSystems IRIS [計算ノード](https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GSCALE_sharding#GSCALE_sharding_reference_plan_qs)が追加されています。    * * * ## まとめ インフラストラクチャの選択に関して言えば、InterSystems IRIS には多数のオプションが提供されています。 インフラストラクチャの要件はアプリケーション、ワークロードプロファイル、およびビジネスニーズによって決まり、これらのテクノロジーとインフラストラクチャの選択が、ビジネスにおけるアプリケーションの成功、採用、および重要性を左右します。 第 2 世代 Intel® Xeon® スケーラブルプロセッサと Intel® Optane™ DC パーシステントメモリを使用した InterSystems IRIS は、ビジネスに大きな影響を与える InterSystems IRIS ベースアプリケーションに画期的なスケーリング性能とスループット性能を与えることができます。 **InterSystems IRIS と Intel DCPMM 対応サーバーには、次のようなメリットがあります。** * Memory Mode の DCPMM を使用した InterSystems IRIS または InterSystems IRIS for Health データベースキャッシュにマルチテラバイトのデータベースが完全に収まるようにメモリ容量を増加します。 ストレージ（ディスク）からの読み取りと比較した場合、サイズが増加するにつれてシステムメモリを利用する InterSystems IRIS の実証されたメモリキャッシュ機能によって、コードを変更することなくクエリへの応答パフォーマンスを 6 倍向上させることができます。 * 同一のプロセッサを使って、利用可能な最速の NVMe ドライブから、App Direct モードによって DAX XFS ファイルシステムとして DCPMM を利用するようにトランザクションジャーナルディスクを変更するだけで、HL7 変換など、InterSystems IRIS と InterSystems IRIS for Health に基づく高速データ相互運用性スループットアプリケーションのパフォーマンスを最大 60% 増のスループットに改善します。 メモリ速度のデータ転送とデータの永続性を活用することで、InterSystems IRIS と InterSystems IRIS for Health に大きなメリットが与えられます。 * 読み取り集中型ワークロードか書き込み集中型ワークロードか、またはその両方のワークロードかに関係なく、Mixed Mode の DCPMM を使った 1 つのリソースコンポーネントの為だけにサーバー全体を過剰に割り当てることなく、必要に応じて計算リソースを拡大します。 お客様の InterSystems IRIS ベースのアプリケーションに最適なハードウェア構成についてのご相談は、InterSystems テクノロジーアーキテクトにお問い合わせください。

開発者の皆さん、こんにちは！次のコンテストのテーマが発表されました！ 🏆 InterSystems AI Programming Contest 🏆 応募期間は 2021年6月28日～7月18日 です！ 💰 賞金総額： $8,750 💰 （投票期間は 2021年7月19日～7月25日、勝者発表は 7月26日を予定しています） 優勝特典 １、審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 1位 - $4,000 🥈 2位 - $2,000 🥉 3位 - $1,000 2、開発者コミュニティで多く票を集めたソリューションには、以下の賞金が贈られます。 🥇 1位 - $1000 🥈 2位 - $500 🥉 3位 - $250 複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます。 参加資格 どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます） 👥 開発者がチームを組んで共同でアプリケーションを作成し、応募することもできます！ 1チーム 2～5名 までご参加いただけます。 チームでご応募いただく場合は、アプリケーションの README にチームメンバー名の記載をお忘れなく！！（開発者コミュニティのプロファイルのリンクもお願いします） コンテストのスケジュール 6月28日～7月18日 応募期間（Open Exchange へ作成されたアプリケーションをアップロードいただける期間＝3週間です。この期間内であればアップロード後も自由に編集できます。） 7月19日～7月25 投票（1週間） 7月26日 勝者発表（US時間に発表します） コンテストのテーマ 🤖 Artificial Intelligence and Machine Learning 🤖 InterSystems IRIS を使用した AI/ML ソリューションを開発してください。 IRIS を使用して、ライブラリ、パッケージ、ツール、AI/ML ソリューションを作成いただき、ご応募ください。 応募要件は以下の通りです。 1、応募可能なアプリケーション Open Exchange アプリケーションの新規作成、または既存アプリケーションであっても大幅に改善されているものであればご応募いただけます。 コミュニティの担当チームは、コンテストへの応募を承認する前に申請された全アプリケーションをレビューします。 2、アプリケーションは、InterSystems IRIS の AI/ML 機能のいずれかを使用してください。 3、アプリケーションは、IRIS Community Edition 、IRIS for Health Community Edition、IRIS Advanced Analytics Community Edition のいずれかで動作する必要があります。 4、アプリケーションはオープンソースとして、GitHub で公開する必要があります。 5、アプリケーションの README ファイルは、英語で記述してください（日本語で記述したものがあればそのまま掲載いただき、英文の追記をお願いします）。また、インストール手順や、アプリケーションがどのように動作するかの説明、またはビデオデモを含めてください。 6、InterSystems ObjectScript で記述したソースコードがある場合は、（XMLでエクスポートしたファイルではなく）UDL 形式 で提供する必要があります。例 上記要件は、変更される場合もあります。予めご了承ください。 Helpful resources 1. 開発環境テンプレート InterSystems IntegragedML template：こちらの記事に含まれるビデオに、テンプレートの使い方（日本語）をご紹介しています。 00:46～17:55 をご参照ください。 IRIS R Gateway template 2. データインポートツール Data Import Wizard CSVGEN - CSV インポートユーティリティ CSVGEN-UI - CSVGEN の Web UI 版 3. ドキュメント Using IntegratedML 4. オンラインコース（英語） Learn IntegratedML in InterSystems IRIS Preparing Your Data for Machine Learning Predictive Modeling with the Machine Learning Toolkit 5. IntegratedML ー SQLから始める機械学習（ビデオ：日本語） 6. コンテスト応募方法（このページ末尾のビデオをご参照ください） 審査及び投票ルール 投票ルールは近日公開します。 皆様からの✨素敵な✨プロジェクトをお待ちしております！コミュニティのコーディングマラソンに参加して、優勝を目指しましょう！(ง`0´)ง ❗️ コンテスト規約については、こちらをご参照ください。❗️ ご応募方法について 以下の応募方法ビデオをご参照ください。 以下の応募方法ビデオをご参照ください。 以下、コンテストに応募する迄の手順をご説明します。 コンテスト応募までの流れは以下の通りです（※ビデオでは、3番以降の内容をご紹介しています）。 1、IRISプログラミングコンテスト用テンプレートを使用して、開発環境を準備します。 2、コンテスト用アプリケーションを作成します。 3、コンテストの準備が完了したら、ソースコードをローカルのGitリポジトリへコミットします。 初回コミット時に、Gitの初期設定がないためコミットが失敗することがあります。その場合は、以下のコマンドでGitユーザ名とEmailを設定します。 git config --global user.name "ここにユーザ名" git config --global user.email "ここにメールアドレス” 4、ローカルのGitリポジトリのコミットが完了したら、リモートのGitリポジトリを作成します。 リポジトリ作成後、リモートリポジトリのURLをコピーします。 5、リモートのGitリポジトリへPushします。 git push ここにリモートのリポジトリのURL 6、OpenExchangeにログインし、アプリケーションを追加します。 ※事前にDeveloper communityでユーザアカウントを作成する必要があります。ログイン後、Profile→Applications　から　Application　をクリックし、4 でコピーしたリモートのGitリポジトリのURLを設定します。 アプリケーションを登録すると、画面右上に「Send Approval」のボタンが表示されるので、クリックします。 再度作成したアプリケーションを開くと、「Apply for Contest」ボタンが表示されるので、クリックすると応募が完了します。

これは InterSystems FAQ サイトの記事です。 答え：必要ありません。 InterSystems 製品では、クライアント機能用に特別なライセンスを設けておりません。 通常のサーバーライセンス（サブスクリプションを含む）を保有していれば、そのサーバーライセンスで許容しているキャパシティに応じて、複数のクライアントシステムにクライアント機能をインストールして利用することができます。

この記事では、InterSystems IRIS プラットフォームを使用して基本的な IMAP クライアントを記述する方法を説明します。 はじめに IMAP の概要を確認してから、本題の IMAP コマンドとクライアント実装について説明します。 最後に、IRIS 相互運用性アプリケーションでこの IMAP クライアントを簡単に使用します。 この記事では IMAP を詳しく説明していません。 詳細な情報については、この記事のリソースをご覧ください。 IMAP の概要 ユーザーは IMAP（Internet Message Access Protocol）を使ってメールを取得できます。 IMAP は 1980 年代に Marc Crispin によって提唱されました。以来、このプロトコルは RFC 3501 として公開され、改訂されています。 この記事の執筆時点での最新バージョンは、IMAP4rev1 です。 このプロトコルは取得のみを目的に設計されていることに十分に注意してください。 メールを送信するのであれば、SMTP（Simple Mail Transfer Protocol）という別のプロトコルを使用する必要があります。 また、メールの取得には、IMAP よりも古い POP3（Post Office Protocol version 3）があります。これも IMAP と同様に一般的に使用されています。 基本的な IMAP コマンドを試す POP3 と同様に、IMAP はプレーンテキストプロトコルです。 Telnet や OpenSSL などの TCP クライアントを使用して、自分で簡単にコマンドを試すことができます。 まず、IMAP ホストとメールサーバーポートが必要です。 たとえば以下は、この記事の執筆時点での、Microsoft Outlook サービスに接続するためのホストとポートです。 outlook.office365.com:993 TCP クライアントを使ってこのサーバーに接続してみましょう。 以下のコマンドを入力して ENTER キーを押します。 -crlf フラグを使用しているところに注意してください。 IMAP の改行コードはキャリッジリターンとラインフィード（CRLF）であるため、IMAP にはこのフラグが必要です。 $ openssl s_client -connect outlook.office365.com:993 -crlf -quiet Enter キーを押すと、IMAP サーバーから情報が提示され、入力待ちとなります。 depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert ... * OK The Microsoft Exchange IMAP4 service is ready. [...] この時点で、最初の IMAP コマンドである CAPACITY コマンドを実行できます。 名前からわかるように、これはサーバーが提供できる機能を提示するコマンドです。 最初の行は IMAP コマンド自体であり、残りの行はその出力です。これは、ここで示すすべての IMAP コマンドに共通しています。 TAG1 CAPABILITY * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+ TAG1 OK CAPABILITY completed. CAPABILITY コマンドの前にある TAG1 というトークンに注意してください。 すべての IMAP コマンドの前にはタグを配置する必要があり、任意の文字列を使用できます。 このタグによって、サーバーの応答先であるコマンドインスタンスを識別しています。 一般に、任意のプレフィックスに単純なカウンターを使用したものがあらゆるニーズに対応できます。 IMAP サーバーの応答は、コマンドの発行に使用したタグ、コマンドのステータスを示すフラグ、コマンドとステータスに関連するその他の情報となります。 許可されているステータスは、OK（成功）、NO（失敗）、および BAD（誤ったコマンド）です。 LOGIN コマンドでは、引数としてユーザーとパスワードが想定されています。 まず、誰かが無効なユーザー名とパスワードを入力した場合にサーバーがどのように応答するかを確認してみましょう。 TAG2 LOGIN user@outlook.com wrong-password TAG2 NO LOGIN failed. コマンドタグに続くのは NO ステータスであることに注意してください。 次に、有効なログインを試してみましょう。 TAG3 LOGIN user@outlook.com password TAG3 OK LOGIN completed. これでログインできました。 セッションを終了するには、LOGOUT コマンドを使用します。 TAG4 LOGOUT * BYE Microsoft Exchange Server IMAP4 server signing off. TAG4 OK LOGOUT completed. IMAP クライアントを実装するには他のコマンドが必要であるため、もう一度 IMAP サーバーに接続してログインする必要があります。 では、受信トレイに関する情報を取得しましょう。 まず、アクセスしようとしているメールボックスがどれかをサーバーに伝える必要があります。この場合は INBOX です。 TAG5 SELECT "INBOX" * 14 EXISTS * 0 RECENT ... TAG5 OK [READ-WRITE] SELECT completed. これで、受信トレイのメッセージにアクセスする準備は整いましたが、メッセージを参照する方法が必要です。 この方法には、メッセージ番号または一意の識別子（UID）を使用する 2 つがあります。 メッセージ番号は、1 から始まり、受信トレイ内のメッセージ数までの単純なカウンターです。 メッセージが削除されると、後続のすべてのメッセージの番号が 1 つずつ減ります。 要素の 1 つが削除された配列として考えるとよいでしょう。 一方 UID は、他のメッセージに何が起ころうとも、その値を保持します。 UID は SEARCH コマンドを使って取得できます。 このコマンドには、特定の UID を取得する場合はメッセージ番号を、ディレクトリ内のすべての UID を取得する場合は ALL パラメーターを指定できます。 以下の例では、メッセージ番号 1 の UID を検索しています。UID は 483 です。 TAG6 UID SEARCH 1 * SEARCH 483 TAG6 OK SEARCH completed. 次に、ヘッダー、本文、添付ファイルなどのメッセージ情報を取得してみましょう。 これには FETCH コマンドを使用します。 このコマンドには多数のパラメーターがあります。詳細は、RFC 3501 をご覧ください。 この記事では、IMAP クライアントを実装するというニーズに関連するパラメーターのみを説明しています。 このデモで必要となる最初の情報は、メッセージのサイズです。 この情報は、RFC822.SIZE パラメーターを使って取得できます。 TAG7 FETCH 1 RFC822.SIZE * 1 FETCH (RFC822.SIZE 70988) TAG7 OK FETCH completed. ここでは、メッセージ番号 1 のサイズは 70,988 バイトであることが示されています。 メッセージ番号の代わりに UID を使用してメッセージ情報をフェッチすることも可能です。 TAG8 UID FETCH 483 RFC822.SIZE * 1 FETCH (RFC822.SIZE 70988 UID 483) TAG8 OK FETCH completed. メッセージヘッダーの基本的な From（送信者）、To（宛先）、Sbuject（件名）を取得することもできます。 TAG9 FETCH 1 (FLAGS BODY[HEADER.FIELDS (FROM TO DATE SUBJECT)]) * 1 FETCH (FLAGS (\Seen) BODY[HEADER.FIELDS (FROM TO DATE SUBJECT)] {157} Date: Thu, 22 Apr 2021 15:49:05 +0000 From: Another User <anotheruser@outlook.com> To: user@outlook.com Subject: Greetings from Another User! FLAGS (\Seen)) TAG9 OK FETCH completed. 次に、メッセージ本文を取得しましょう。 以下のコマンドを使用して、本文の全コンテンツを取得できます。 TAG10 FETCH 1 BODY[] * 1 FETCH (BODY[] {9599} ... MIME-Version: 1.0 --00000000000041bd3405c3403048 Content-Type: multipart/alternative; boundary="00000000000041bd3205c3403046" --00000000000041bd3205c3403046 Content-Type: text/plain; charset="UTF-8" ... --00000000000041bd3405c3403048 Content-Type: image/png; name="download.png" Content-Disposition: attachment; filename="download.png" ... TAG10 OK FETCH completed. 上記のコードでは、いくつかのブロックが -- -- の間の 16 進数で区切られているのがわかります。これはパートと呼ばれるもので、 パートが複数含まれるメッセージはマルチパートメッセージと呼ばれます。 コマンドにパートインデックスを渡すと、パートを直接取得することができます。 メッセージを削除するために、プロトコルには、STORE と EXPUNGE という、メッセージを削除済みとしてマークし、操作をコミットするコマンドがあります。 TAG11 STORE 1 +FLAGS (\Deleted) * 0 EXISTS * 0 RECENT TAG11 OK [READ-WRITE] SELECT completed; now in selected state TAG12 EXPUNGE EXPUNGE: TAG12 OK EXPUNGE completed 最後は NOOP というシンプルなコマンドです。 このコマンドは、keep-alive ストラテジーを実装するためだけに使用されます。 デフォルトでは、IMAP セッションはコマンドなしで 30 分後に閉じられるようになっています。 そのため、NOOP コマンドを発行することで、接続をアクティブな状態に維持することができます。 TAG17 NOOP TAG17 OK NOOP completed. これで、IMAP の概要は終了です。 さらに詳しい情報が必要な方は、Web 上の多数あるお役立ち記事をご覧ください（一部をリソースのセクションに記載しました）。もちろん、RFC 3501 もご参考ください。 リソース Atmail の「IMAP 101: Manual IMAP Sessions」 Fastmail の「Why is IMAP better than POP?」 IETF の「Internet Message Access Protocol」 IETF の「Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies」 Nylas の「Everything you need to know about IMAP」 次回パートでは、IRIS 内でこれらのコマンドを使用し、実際の動作を確認します！ それではまた！  

## 最初のパートでは、IMAP プロトコルコマンドについて簡単に説明しました。このパートでは、IRIS を使用してこれらのコマンドを実装し、独自の IMAP クライアントを作成してみましょう！ ## IRIS Email フレームワーク IRIS プラットフォームには電子メールを操作するためのデフォルトのインターフェースとクラスがあります。 これらのアーティファクトは元々 POP3 実装用に設計されていますが、 これらのインターフェースとクラスを IMAP クライアントの実装に使用して拡張できないということではありません。 それでは、このことについて説明しましょう。 %Net.FetchMailProtocol: メールを取得するための基本クラスです。 IMAP クライアントはこれを拡張しています。 %Net.MailMessage: MIME メッセージです。 %Net.MailMessagePart. を拡張します。 %Net.MailMessagePart: マルチパートメッセージの MIME メッセージをカプセル化します。 このクラスにはそれ自体の配列があり、メッセージのサブパートをツリーで表現できるようにします。 %Net.MIMEReader: このユーティリティは、メッセージの MIME コンテンツを解析するメソッドで、%Net.MIMEPart インスタンスを生成します。 %Net.MIMEPart: メッセージの MIME パートをカプセル化し、それらに関する情報を取得するためのメソッドを提供します。 IMAP クライアントの実装 このセクションでは、IMAP クライアント、インバウンドアダプタ、および単純なプロダクションに関する実装内容を紹介します。 スペースを節約するために、ほとんどの実装メソッドは説明していないことに注意してください。 代わりに、それぞれの実装の完全な詳細へのリンクを付けています。 完全なソースコードは、GitHub から入手できます。 基本的な IMAP クライアントの作成 前のパートで説明したように、IMAP は TCP を介すプレーンテキストベースのプロトコルです。 つまり、そのようなプロトコル向けにクライアントを実装するベースコードは TCP クライアントということになります。 IRIS プラットフォームには、OPEN、USE、READ、WRITE、および CLOSE という I/O 操作を実行するための標準の ObjectScript コマンドが提供されています。 以下に、MS Outlook サーバーに接続し、ログインしてからログアウトする方法例を簡単に示します。 ClassMethod SimpleTest() { // connection configuration SET dev = "|TCP|993" SET host = "outlook.office365.com" SET port = "993" SET mode = "C" SET sslConfig = "ISC.FeatureTracker.SSL.Config" SET timeout = 30 // connection to MS Outlook IMAP server OPEN dev:(host:port:mode:/TLS=sslConfig):timeout THROW:('$TEST) ##class(%Exception.General).%New("Sorry, can't connect...") USE dev READ resp($INCREMENT(resp)):timeout WRITE "TAG1 LOGIN user@outlook.com password", ! READ resp($INCREMENT(resp)):timeout WRITE "TAG2 LOGOUT", ! READ resp($INCREMENT(resp)):timeout CLOSE dev // come back to default device (terminal) and prints responses USE 0 ZWRITE resp } この出力は以下のようになります。 USER>d ##class(dc.Demo.Test).SimpleTest() resp=3 resp(1)="* OK The Microsoft Exchange IMAP4 service is ready. [QwBQ..AA==]"_$c(13,10) resp(2)="TAG1 OK LOGIN completed."_$c(13,10) resp(3)="* BYE Microsoft Exchange Server IMAP4 server signing off."_$c(13,10)_"TAG2 OK LOGOUT completed."_$c(13,10) このコードにはいくつかのハイライトがあります。 mode 変数を C に設定します。これはキャリッジリターンモードです。 IMAP の場合、この設定は必須です。 フラグ /TLS によって安全な通信レイヤー（SSL）を確立します。 このフラグ値を有効な SSL IRIS 接続に設定する必要があります。 OPEN コマンドによって、接続を開始します。 特殊なブール変数の $TEST は、タイムアウト付きのコマンドが成功した場合またはタイムアウトが期限切れになった場合に 1 を返します。 この例では、OPEN コマンドが 30 秒を超えると、コードは例外をスローします。 接続が確立したら、コマンド USE によって TCP デバイスが所有され、すべての READ と WRITE コマンドがこのデバイスにリダイレクトされるようになります。 WRITE コマンドが IMAP サーバーにコマンドを発行し、READ コマンドがその出力を取得します。 接続を終了するために、CLOSE コマンドを使用します。 デバイスを所有すると、READ と WRITE へのすべての呼び出しは、dev 変数に指定されているデバイスで、USE dev コマンドを使用した後に実行されます。 ターミナルに戻ってもう一度書き込む場合は、先に USE 0 コマンドを発行する必要があります。 それぞれの READ コマンドには、サーバーの応答を格納するバッファがありますが、容量が制限されています。 応答のサイズがこの制限を上回る場合は、別の READ コマンドを発行して全応答を読み取る必要があります。 もちろん、バッファサイズを増やすこともできますが、制限を超えるような状況に対処する準備を整えておく方が適しています。 前のパートで説明したように、IMAP の各コマンドにはタグが必要です。 このタグは、コードが完全な応答を取得したか、別の READ コマンドを発行する必要があるかどうかをチェックする上で役立ちます。 この場合は、ReadResponse メソッドを実装して、コードが確実にメッセージ全体を読み取るようにしています。 IMAP の %Net.FetchMailProtocol インターフェースの実装 %Net.FetchMailProtocol 抽象クラスは、IRIS プラットフォームでの電子メールの取得を抽象化します。 実装するのは以下のメソッドです。 Connect: IMAP サーバーへの接続を確立し、ユーザーをログインさせます。 GetMailBoxStatus: メールボックスのサイズとその中のメッセージの件数を取得します。 GetSizeOfMessages: メッセージ番号で識別される 1 件またはすべてのメッセージのサイズを取得します。 GetMessageUIDArray: 受信トレイ内の 1 件またはすべてのメッセージ UID を配列で取得します。 GetMessageUID: メッセージ番号に対応する UID を取得します。 Fetch: メッセージ番号で、メッセージのコンテンツ（またはマルチパートコンテンツ）を取得します。 %Net.MailMessage オブジェクトにカプセル化されたメッセージコンテンツを取得します。 FetchFromStream: これは Fetch と同じですが、IMAP サーバーを呼び出す代わりに、%BinaryStream オブジェクトにカプセル化された EML メッセージコンテンツからコンテンツを取得します。 FetchMessage: これは Fetch と同じですが、ByRef 変数で特定のメッセージヘッダーを返します。 FetchMessageInfo: メッセージヘッダーとメッセージのテキストのみを取得します。 DeleteMessage: 削除用の配列にメッセージを追加します。 RollbackDeletes: 削除用の配列をクリーンアップします。 QuitAndCommit: 削除用の配列のすべてのメッセージを削除し、IMAP サーバーから切断します。 QuitAndRollback: 削除用の配列をクリーンアップし、IMAP サーバーから切断します。 Ping: セッションをアクティブに維持するように IMAP に ping を送信します。 まず、インターフェースを実装するために、dc.Demo.IMAP という新しいクラスを作成します。 このクラスはいくつかのプロパティを継承します。IMAP サーバーへの接続を確立するように設定する必要があります。  また、dc.Demo.IMAPHelper というヘルパークラスも作成します。 このクラスは、IMAP 応答のメソッドを解析し、マルチパートメッセージのすべてもパートを取得し、コマンドを送信して応答全体が読み取られるようにするメソッドなどの周辺機能を格納します。 最初に実装するメソッドは、Connect メソッドです。 このメソッドは、クラスプロパティにカプセル化された構成を使用して、IMAP サーバーへの接続を確立します。 ログインも発行します。 このメソッドは、IRIS プラットフォームの OPEN コマンドを使用して IMAP サーバーへの接続を確立し、IMAP コマンドの LOGIN を使用してサーバーへの認証を行います。 次に実装するメソッドは GetMailBoxStatus です。 このメソッドは、SELECT コマンドを使用してメールボックスを選択し、メールボックス内のメッセージ件数などの追加情報を集めます。 IMAP には、すべてのメッセージのサイズを取得するためにすぐに使用できるコマンドがありません。 もちろん、すべてのメッセージを反復処理して、サイズの合計を計算することは可能ですが、 この方法では、処理速度の低下の問題が発生する可能性があります。 そこで、この実装では、すべてのメッセージのサイズは取得しません。 次のメソッドは GetSizeOfMessages です。 このメソッドは、受信トレイ内の 1 件以上のメッセージのサイズを取得します。 メッセージ番号が定義されていない場合、GetMailBoxStatus メソッドで説明した IMAP の制限と同じ理由で例外がスローされます。 ここでは、IMAP コマンドの FETCH <message_number> (RFC822.SIZE) を使用して、番号でメッセージのサイズを取得します。 次は、GetMessageUIDArray メソッドで、これは IMAP コマンドの SELECT と UID SEARCH [ALL | <message_number>] を使用して応答を解析し、UID 配列を取得します。 そして GetMessageUID メソッドを実装します。 このメソッドは、定義されたメッセージ番号の UID を取得して、GetMessageUIDArray メソッドと同じロジックを使用します。 その後に、Fetch メソッドを実装します。 これは、IMAP コマンドの SELECT と FETCH <message_number> BODY を使用して、MIME format でエンコードされているメッセージのコンテンツを取得します。 幸いなことに、IRIS プラットフォームには、MIME コンテンツのリーダーである %Net.MIMEReader クラスがあります。 このクラスは、ストリーム内のメッセージを取得して、解析済みのメッセージを %Net.MIMEPart オブジェクトで返します。 このメソッドは、MIME コンテンツを取得したら、%Net.MailMessage オブジェクトを作成し、%Net.MIMEPart オブジェクトのデータを挿入してそれを返します。 MIME コンテンツは、dc.Demo.IMAPHelper クラスの GetMailMessageParts メソッドを介して %Net.MailMessagePart オブジェクトにマッピングする %Net.MIMEPart オブジェクトにカプセル化されています。 次のメソッドは、FetchFromStream です。 このメソッドは、EML メッセージと共にストリームオブジェクトを取得し、それを %Net.MailMessage オブジェクトに変換します。 このメソッドはサーバーからコンテンツを取得しません。 次は、Fetch メソッドの特殊ケースである FetchMessage と FetchMessageInfo メソッドです。 DeleteMessage メソッドは、メッセージを削除するようにマークするのに対し、RollbackDeletes メソッドは、削除用にマークされたメッセージの配列をクリーンアップするだけです。 次は、QuitAndCommit メソッドです。 これは、IMAP サーバーから切断し、メッセージを削除するための CommitMarkedAsDeleted メソッドを呼び出します。 QuitAndRollback メソッドは、IMAP サーバーから切断して、削除用にマークされたメッセージの配列をクリーンアップするだけです。 最後のメソッドは Ping で、これは NOOP コマンドを発行して IMAP セッションをアクティブに維持します。 IMAP のインバウンドアダプタの実装 IRIS プラットフォームにおけるインバウンドメールの基本クラスは EnsLib.EMail.InboundAdapter です。 このインバウンドアダプタには、以下の構成が必要です。 メールサーバーのホストアドレス メールサーバーのポート サーバーにアクセスするためのユーザー名とパスワードを格納する資格情報 ID SSL 構成 このクラスを拡張し、新しい dc.Demo.IMAPInboundAdapter という IMAP インバウンドアダプタが作成されました。 この新しいアダプタを使用するために、Mailbox 本番パラメーターにどのメールボックスを使用するのかを設定します。 デフォルト値は INBOX です。 実装は単純なもので、MailServer プロパティをオーバーライドして、そのタイプを dc.Demo.POP3ToIMAPAdapter IMAP クライアントに設定するだけです。 基本のアダプタクラスは POP3 コマンド用に設計されているため、このアダプタは POP3 フローを IMAP フローにマッピングします。 したがって、この POP3 から IMAP へのアダプタを使用すると、元のすべてのインバウンドアダプタロジックを実行しながら、POP3 コマンドの代わりに IMAP コマンドを使用することができます。 dc.Demo.POP3ToIMAPAdapter クラスでは、サーバー通信のプロキシとして、タイプ dc.Demo.IMAP の IMAP クライアント IMAPClient を使用しますが、 dc.Demo.POP3ToIMAPAdapter は %Net.POP3 を拡張しているため、%Net.FetchMailProtocol のすべての抽象メソッドをオーバーライドする必要があります。 また、%Net.POP3 クライアントが直接実装していた ConnectPort と FetchMessageHeaders という新しいメソッドを実装する必要がありました。 同様に、ConnectedGet と SSLConfigurationSet メソッドを作成して、%New.POP3 が直接実装していたプロパティを設定して取得しました。 単純なプロダクションのセットアップ すべてのクラスが連携するように、単純なプロダクションをセットアップします。 IRIS プロダクションに関する詳細については、プロダクションの作成 をご覧ください。 このプロダクションには、IMAP インバウンドアダプタを使って新着メッセージをチェックするビジネスサービスとビジネスオペレーションが含まれています。 このコードは、Demo.Loan.FindRateProduction の相互運用性サンプルを変更したものです。 要するに、このプロダクションでは以下のことを行います。 GetMessageUIDArray メソッドを使用して、構成済みのメールボックスに存在するすべてのメッセージを取得する メッセージをループし、Fetch メソッドでフェッチされた出力をトレースする 各メッセージの件名が、「[IMAP test] で開始」という基準に一致しているかどうかをチェックする メッセージの件名が基準に一致する場合は送信者に返信し、そうでない場合はメッセージを無視する それらのメッセージを削除して、もう一度解析されないようにする この例では、Yahoo メールの IMAP サーバーである imap.mail.yahoo.com（ポート 993）を構成します。 また、「ISC FeatureTacker.SSL.Config」というデフォルトの IRIS SSL 構成を使用します。 次に、ユーザー名とパスワードを含む、imap-test という資格情報を以下のように構成します。 以下の画像が示すように、プロダクションが開始され、IMAP サーバーに新着メッセージを照会し続けます。 新着メッセージがある場合、インバウンドアダプタは、ヘッダーや件名といった情報を取得し、その情報に基づいてプロダクションでさらにアクションを実行できるようにします。 この例では、プロダクションはメッセージの件名が「[IMAP test]」で開始しているかどうかをチェックし、送信者にメッセージを送り返します。 メッセージがこの基準に一致していない場合は、そのまま無視されます。 まとめ この記事では、IMAP クライアントの実装について説明しました。 最初に、IMAP とその主要コマンドに関するいくつかの重要な背景を確認しました。 次に、クライアントと IRIS プラットフォームからクライアントに接続する方法など、実装を詳しく説明しました。 また、IMAP を使用するためのデフォルトの相互運用性アダプタの拡張機能と、単純なプロダクションの例も示しました。 IMAP とその設定についてさらに理解し、IRIS への接続方法を学習したため、アプリケーションにメール機能をセットアップできるようになったことでしょう。 ここで言及した IMAP 関連トピックの詳細については、以下のリソースをご覧ください。 リソース Atmail の「IMAP 101: Manual IMAP Sessions」 Fastmail の「Why is IMAP better than POP?」 IETF の「Internet Message Access Protocol」 IETF の「Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies」 InterSystems の「I/O Devices and Commands」 InterSystems の「Using the Email Inbound Adapter」 Nylas の「Everything you need to know about IMAP」  

ObjectScript パッケージマネージャ ZPM のライフサイクルにおけるマイルストーンをここに発表させていただきます。このパッケージマネージャは、ObjectScript コードや 配置構成設定、バージョン情報などを便利にパッケージ化する機能を開発者に提供し てきました。 ここ数年のうちに、多くの開発ワークフローに不可欠な存在として大きく進化しました。 その結果、インターシステムズは所有するコンポーネントをパッケージ化するのに使用することとし、コミュニティのGitHubリポジトリをコーポレートリポジトリに移行、InterSystems Package Manager (IPM) に改名することとなりました。IPMはオープンソースのままです。コミュニティのメンバーは、コードをレビューし、プルリクエストを提出することができます。この変更により、従業員以外の方がコードベースに変更を加えることができないような方法で、ソフトウェアのセキュリティを確保することができるようになりました。また、データと一緒にコードをインストールできるソフトウェアでは、より高いレベルのセキュリティと信頼性が重要です。 ですから、 ZPM の存続を祝い、IPM の誕生を歓迎し、貢献いただいた皆さんに感謝したいと思います。特に、Nikolay Soloviev ならびに@Dmitry.Maslennikov には開発者ニーズを掘り起こし、スキルと融合し、素晴らしいソフトウェアの構築に貢献いただきました。 --- https://github.com/intersystems/ipm

開発者の皆さん、こんにちは！ 次のプログラミングコンテストの詳細が決定し「IRIS Cloud SQLのデータを利用してAI/MLソリューションを作成する」がテーマとなりました。 🏆 InterSystems IRIS Cloud SQL and IntegratedML コンテスト 🏆 期間： 2023年4月3日～23日 賞金総額: $13,500 テーマ 💡 InterSystems IRIS Cloud SQL with IntegratedML コンテスト 💡 このコンテストでは、InterSystems IRIS Cloud SQL を利用してデータ操作を行うフルスタック、フロントエンド、バックエンドアプリケーションの開発を行っていただきます。また、オプションとして IntegratedML を利用した AI/ML ソリューションの開発もコンテストのテーマに含まれています。 作成いただくアプリケーションは、ライブラリ、パッケージ、ツール、またはバックエンドで InterSystems IRIS SQL Cloud を使用する SQL または AI/ML ソリューションであれば何でも構いません。 基本的には、IntegratedMLにより提供されるAutoMLオプションを含め、InterSystems IRIS をSQLエンジンとして 100%使用することがコンテスト応募の要件となります。 InterSystems IRIS Cloud SQLについての詳細は、ドキュメント：Welcome to InterSystems IRIS Cloud SQL! をご参照ください。また、IntegratedMLを含めた情報については、ドキュメント：Welcome to InterSystems IRIS Cloud IntegratedML! をご参照ください。 応募要件について: 応募可能なアプリケーション Open Exchange アプリケーションの新規作成、または既存アプリケーションであっても大幅に改善されているものであればご応募いただけます。 コミュニティの担当チームは、コンテストへの応募を承認する前に申請された全アプリケーションをレビューします。 全てのアプリケーションは、IRIS Community Edition 、IRIS for Health Community Edition 、IRIS Advanced Analytics Community Editionで動作する必要があります。 アプリケーションは、以下のいずれかのタイプで作成してください。 UI フレームワーク IDE データベース管理 モニタリング デプロイツール など アプリケーションはオープンソースであり、GitHubで公開されている必要があります。 アプリケーションの README ファイルは、英語で記述してください（日本語で記述したものがあればそのまま掲載いただき、英文の追記をお願いします。翻訳アプリを使用しますが翻訳をお手伝いすることもできますのでお気軽にお知らせください！）。また、インストール手順や、アプリケーションがどのように動作するかの説明、またはビデオデモを含めてください 1人の開発者は最大3つのアプリケーションを応募できます。 入賞得点： 1. Experts Nomination - 審査員から多く票を集めたアプリケーションには、以下の賞金が贈られます。 🥇 1位 - $5,000 🥈 2位 - $3,000 🥉 3位 - $1,500 🏅 4位 - $750 🏅 5位- $500 🌟 6-10位 - $100 2. Community winners - 開発者コミュニティで多く票を集めたソリューションには、以下の賞金が贈られます。 🥇 1位 - $750 🥈 2位 - $500 🥉 3位 - $250 複数の参加者が同数の票を獲得した場合、全参加者が勝者となり賞金は勝者間で分配されます スケジュール: 🛠 アプリケーション開発と応募期間： 2023年4月3日 (00:00 EST): コンテスト開始！ 2023年4月16日 (23:59 EST): 応募締め切り日 ✅ 投票期間: 2023年4月17日 (00:00 EST): 投票開始！ 2023年4月23日 (23:59 EST): 投票終了日 応募、投票期間中、アップロードしたアプリケーションは改良できます。 参加資格： どなたでもご参加いただけます！（InterSystems 開発者コミュニティのアカウントを作成するだけでご応募いただけます） 👥開発者がチームを組んで共同でアプリケーションを作成し、応募することもできます！ 1チーム 2～5名 までご参加いただけます。 チームでご応募いただく場合は、アプリケーションの README にチームメンバー名の記載をお忘れなく！！（開発者コミュニティのプロファイルのリンクもお願いします） Helpful resources ✓ Documentation: InterSystems IRIS Cloud SQL InterSystems IRIS Cloud IntegratedML ✓ Tools: irissqlcli - python SQL terminal for InterSystems IRIS irissqlcli（IRIS SQLの高度なターミナル）：InterSystemsデベロッパーツールコンテスト2023入賞作品のご紹介 IRIS Cloud SQLへの接続方法 irissqlcli -h your-iris-cloud-sql-server -p 1972 -u SQLAdmin -n USER -W DBeaver - SQL-driven database tool. DBeaver and IRIS. ✓ アプリケーション例: iris-cloud-sql-demo ✓ オンラインラーニング資料： Connect to InterSystems IRIS Cloud SQL via Python, C++, Java, .NET. ✓コンテストへの応募方法 Need Help? ご質問がある場合は、この投稿へコメントいただくか、InterSystems の Discord server チャンネルにご参加ください！ 皆様からのアプリケーションのご応募、お待ちしております！👍 ❗️ コンテストに参加された場合、こちらに記載されているコンテスト規約に同意したものとみなされます。ご応募の際、ご一読いただきますよう、お願い申し上げます❗️ ご応募方法について 以下の応募方法ビデオをご参照ください。 以下、コンテストに応募する迄の手順をご説明します。 コンテスト応募までの流れは以下の通りです（※ビデオでは、3番以降の内容をご紹介しています）。 1、IRISプログラミングコンテスト用テンプレートを使用して、開発環境を準備します。 2、コンテスト用アプリケーションを作成します。 3、コンテストの準備が完了したら、ソースコードをローカルのGitリポジトリへコミットします。 初回コミット時に、Gitの初期設定がないためコミットが失敗することがあります。その場合は、以下のコマンドでGitユーザ名とEmailを設定します。 git config --global user.name "ここにユーザ名" git config --global user.email "ここにメールアドレス” 4、ローカルのGitリポジトリのコミットが完了したら、リモートのGitリポジトリを作成します。 リポジトリ作成後、リモートリポジトリのURLをコピーします。 5、リモートのGitリポジトリへPushします。 git push ここにリモートのリポジトリのURL 6、OpenExchangeにログインし、アプリケーションを追加します。 ※事前にDeveloper communityでユーザアカウントを作成する必要があります。ログイン後、Profile→Applications　から　Application　をクリックし、4 でコピーしたリモートのGitリポジトリのURLを設定します。 アプリケーションを登録すると、画面右上に「Send Approval」のボタンが表示されるので、クリックします。 再度作成したアプリケーションを開くと、「Apply for Contest」ボタンが表示されるので、クリックすると応募が完了します。

InterSystems Kubernetes Operator (IKO) 3.5 が一般公開されました。 IKO 3.5では、多数のバグフィックスとともに、重要な新機能が追加されています。 主な内容は以下の通りです Web Gateway、ECP、Mirroring、Super Server、IAM間でのTLSのセットアップを簡素化。 コンピュートノードやデータノードとともにサイドカーコンテナを実行する機能 - コンピュートノードとともにWebゲートウェイをスケーリングするのに最適な機能です。 IRIS 2023.1以降、IKO 3.5を使用する場合、CPF configmapとIRIS 秘密鍵はIRISインスタンスによって自動的に処理されます。 initContainerがUID/GIDとイメージの両方で設定できるようになりました。 IKOがtopologySpreadConstraintsをサポートし、ポッドのスケジューリングをより簡単に制御できるようになりました。 より幅広いIRISインスタンスに対応する互換性バージョン コンピュートノードの自動スケール化 (体験版) IKO は ARM でも実行可能 IKOのダウンロード、インストール、および使用方法については、インストールガイドに従ってください。 IKO 3.5の詳細なドキュメントでは、IKOとそれをInterSystems IRISおよびInterSystems IRIS for Healthで使用するための詳細情報を提供しています。 IKOは、WRCのダウンロードページ（Kubernetesで検索）からダウンロードすることができます。 コンテナは、InterSystems Container Registryから入手できます。 IKOは、使いやすいirisClusterリソース定義を提供することで、KubernetesにおけるInterSystems IRISまたはInterSystems IRIS for Healthでの作業を簡素化します。簡単なシャーディング、ミラーリング、ECPの設定など、機能の全リストはドキュメントを参照してください。

企業はグローバルコンピューティングインフラストラクチャを迅速かつ効率的に成長させて管理すると同時に、資本コストと費用を最適化して管理する必要があります。 Amazon Web Services（AWS）および Elastic Compute Cloud（EC2）コンピューティングおよびストレージサービスは、非常に堅牢なグローバルコンピューティングインフラストラクチャを提供することにより、最も要求の厳しいCachéベースのアプリケーションのニーズを満たします。 企業は Amazon EC2 インフラストラクチャを利用し、コンピューティング能力を迅速にプロビジョニングしたり、既存のオンプレミスインフラストラクチャをクラウドに迅速かつ柔軟に拡張したりできます。 AWSは、セキュリティ、ネットワーキング、コンピューティング、ストレージのための豊富なサービスセットと堅牢でエンタープライズレベルの仕組みを提供します。 AWS の中核となっているのは、Amazon EC2 です。 さまざまな OS とマシン構成（CPU、RAM、ネットワークなど）をサポートするクラウドコンピューティングインフラストラクチャです。 AWS は、Amazon マシンイメージ（AMI）と呼ばれる構成済みの仮想マシン（VM）イメージを、さまざまな Linux® および Windows ディストリビューションとバージョンを含むゲスト OS と共に提供しています。AWS で実行される仮想化インスタンスの基盤として、追加のソフトウェアが使用される場合もあります。 このような AMI を最初に使用し、追加のソフトウェアやデータなどをインスタンス化してインストールまたは構成し、アプリケーション固有またはワークロード固有の AMI を作成できます。  あらゆるプラットフォームやデプロイメントモデルと同様に、パフォーマンス、可用性、運用、管理手順などのアプリケーション環境に関わるすべての側面が正しく機能するように注意を払う必要があります。  このドキュメントでは、次のような各分野の詳細について説明しています。 * **ネットワークのセットアップと構成。** このセクションでは、リファレンスアーキテクチャ内のさまざまなレイヤーとロールの論理サーバーグループをサポートするサブネットなど、AWS 内で Caché ベースのアプリケーションのネットワークをセットアップする方法について説明します。 * **サーバーのセットアップと構成。** このセクションでは、各レイヤーのさまざまなサーバーの設計に関連するサービスとリソースについて説明します。 また、アベイラビリティーゾーン全体で高可用性を実現するためのアーキテクチャも取り上げます。 * **セキュリティ。** このセクションではインスタンスとネットワークのセキュリティを構成し、ソリューション全体やレイヤーとインスタンス間で認可済みアクセスを実現する方法など、AWS のセキュリティメカニズムについて説明します。 * **デプロイと管理。** このセクションでは、パッケージ化、デプロイ、監視、および管理の詳細について説明します。  # アーキテクチャとデプロイシナリオ このドキュメントでは、Caché、Ensemble、HealthShare、TrakCare、および DeepSee、iKnow、CSP、Zen、Zen Mojo といった関連する組み込みテクノロジーなどの InterSystems のテクノロジーに基づく堅牢かつパフォーマンスと可用性の高いアプリケーションを提供する AWS 内のいくつかのリファレンスアーキテクチャをサンプルとして提供します。 Caché と関連コンポーネントを AWS でホストする方法を理解するため、まずは典型的な Caché デプロイのアーキテクチャとコンポーネントを確認し、いくつかの一般的なシナリオとトポロジを探っていきましょう。 ## Caché アーキテクチャのレビュー InterSystems のデータプラットフォームは絶え間なく進化しており、高度なデータベース管理システムと迅速なアプリケーション開発環境を提供することで、複雑なデータモデルの処理と分析、および Web アプリケーションとモバイルアプリケーションの開発に飛躍的進歩をもたらしています。 これは、複数モードのデータアクセスを提供する新世代のデータベーステクノロジーです。 データは単一の統合データディクショナリに1回だけ記述され、オブジェクトアクセス、高性能 SQL、および強力な多次元アクセスによりすぐに利用できます（これらはすべて同じデータに同時にアクセスできます）。 アクセス可能な Caché の高レベルアーキテクチャコンポーネントの階層とサービスを図1に示します。これらの一般的な階層は、InterSystems TrakCare および HealthShare 製品の両方にも適用されます。 **_図 1: 高レベルのコンポーネント階層_**  ##一般的なデプロイシナリオ デプロイにはさまざまな組み合わせが可能ですが、このドキュメントではハイブリッドモデルと完全なクラウドホストモデルの 2 つのシナリオについて説明します。  ###ハイブリッドモデル このシナリオでは、企業はオンプレミスのエンタープライズリソースと AWS EC2 リソースの両方を、必要に応じて災害復旧、社内メンテナンスでの不測の事態、プラットフォームの変更計画、または短期的あるいは長期的な能力の増強に活用したいと考えています。 このモデルは、オンプレミスのフェイルオーバーミラーメンバーセットに対して高レベルの可用性を提供し、事業継続性と災害復旧を実現できます。   このシナリオでのこのモデルは、オンプレミスデプロイと AWS アベイラビリティーゾーン間の接続に VPN トンネルを利用し、AWS リソースを企業のデータセンターの拡張先として提供しています。 _AWS Direct Connect_ などの他の接続方法もあります。 ただし、このドキュメントの中では説明していません。  AWS Direct Connect に関する詳細については、こちらを参照してください。 この例の Amazon Virtual Private Cloud（VPC）を設定してオンプレミスのデータセンターの災害復旧に対応する方法については、こちらを参照してください。 _**図 2: オンプレミスの障害復旧に AWS VPC を使用するハイブリッドモデル**_  上記の例は、AWS VPC に VPN で接続されたオンプレミスデータセンター内で動作するフェイルオーバーミラーペアを示しています。 図の中の VPC は、特定 AWS リージョンにある 2 つのアベイラビリティーゾーンで複数のサブネットを提供しています。 レジリエンシーを高めるため、2 つの災害復旧（DR）非同期ミラーメンバー（各アベイラビリティーゾーンに 1 つ）があります。    ###クラウドホストモデル このシナリオでは、データレイヤーとプレゼンテーションレイヤーの両方を含む Caché ベースのアプリケーションは、単一 AWS リージョン内の複数のアベイラビリティーゾーンを使用して AWS クラウド内に完全に維持されています。 同じVPNトンネル、AWS Direct Connect、さらには純粋なインターネット接続モデルも利用できます。 **_図 3: 完全な本番ワークロードに対応したクラウドホストモデル_**  上記の図 3 の例は、VPC 内にアプリケーションの本番環境全体をデプロイするデプロイモデルを示しています。 このモデルは、アベイラビリティーゾーン間の同期的なフェイルオーバーミラーリングに対応した 2 つのアベイラビリティーゾーンと共に、ロードバランシングされた Web サーバーと関連するアプリケーションサーバーを ECP クライアントとして活用しています。 それぞれの層は、ネットワークセキュリティ制御のために個別のセキュリティグループに分離されています。 IPアドレスと一定範囲のポートは、アプリケーションのニーズに応じて必要な場合にのみ開かれます。 # ストレージとコンピューティングリソース ###ストレージ 複数のストレージタイプを選択できます。 このリファレンスアーキテクチャでは、_Amazon Elastic Block Store_（Amazon EBS）と _Amazon EC2 Instance Store_ インスタンスストア（エフェメラルドライブとも呼ばれます）のボリュームについて想定されるいくつかの使用事例を説明します。 さまざまなストレージオプションの詳細は、こちらとこちらをご覧ください。 ### Elastic Block Storage（EBS） EBS は、Linux または Windows で従来型のファイルシステムとしてフォーマットおよびマウント可能で、Amazon EC2 インスタンス（仮想マシン）で使用する耐久性のあるブロックレベルのストレージを提供します。また、最も重要な事ですが、ボリュームはデータベースにとって重要な単一の Amazon EC2 インスタントの稼働期間とは独立して存続するインスタンス外のストレージになっています。 さらに、Amazon EBS はボリュームのポイントインタイムスナップショットを作成し、Amazon S3 に保存する機能を提供します。 これらのスナップショットは新しい Amazon EBS ボリュームの開始ポイントとして、および長期的な耐久性の確保を目的としてデータを保護するために使用できます。 同じスナップショットを使用して必要な数のボリュームをインスタンス化することができます。 これらのスナップショットは AWS リージョン間でコピーできるため、複数の AWS リージョンを地理的な拡張、データセンターの移行、災害復旧により簡単に活用できるようになっています。 Amazon EBS ボリュームのサイズの範囲は 1 GB から 16 TB の範囲で、1 GB 単位で割り当てられます。 Amazon EBS 内には、マグネティックボリューム、汎用（SSD）、プロビジョンド IOPS（SSD）という 3 種類のタイプがあります。 次のサブセクションでは、それぞれについて簡単に説明します。 ### マグネティックボリューム マグネティックボリュームは、中程度または突発的な I/O 要件を持つアプリケーションにコスト効率の高いストレージを提供します。 マグネティックボリュームは平均で毎秒約 100 件の入出力操作（IOPS）を実現するように設計されており、ベストエフォートで数百 IOPS にバーストする機能を備えています。 バースト機能がインスタンスの起動時間を高速にするため、マグネティックボリュームは起動ボリュームとしての使用にも適しています。 ### 汎用（SSD） 汎用（SSD）ボリュームは、幅広いワークロードに適した費用対効果の高いストレージを提供します。 これらのボリュームは、数ミリ秒のレイテンシ、長時間にわたって 3,000 IOPS までバーストする機能、3 IOPS/GB から最大 10,000 IOPS（3,334 GBの場合）までのベースラインパフォーマンスを提供します。 汎用（SSD）ボリュームのサイズは 1 GB から 16 TB の範囲です。 ### プロビジョンド IOPS（SSD） プロビジョンド IOPS（SSD）ボリュームは、ランダムアクセス I/O スループットにおけるストレージのパフォーマンスと整合性に影響されやすいデータベースワークロードなど、I/O 集中型のワークロードに予測可能な高パフォーマンスを提供するように設計されています。 ボリュームの作成時に IOPS レートを指定すると、Amazon EBS は 1 年間のうち 99.9% の時間についてプロビジョニングされた IOPS の 10% の範囲内でパフォーマンスを提供します。 プロビジョンド IOPS（SSD）ボリュームのサイズは 4 GB から 16 TB の範囲で、ボリュームごとに最大20,000 IOPS をプロビジョニングできます。 プロビジョニングされた IOPS とリクエストされたボリュームサイズの最大比率は 30 です。例えば、3,000 IOPS のボリュームのサイズは少なくとも 100 GB である必要があります。 プロビジョンド IOPS（SSD）ボリュームのスループットは、プロビジョニングされた IOPS ごとに 256 KB であり、最大で 320 MB/秒となります（1,280 IOPS の場合）。 このドキュメントで説明するアーキテクチャでは EBS ボリュームを使用しています。予測可能な低レイテンシの入出力操作毎秒（IOPS）とスループットが必要な本番ワークロードに適しているためです。 すべての VM タイプが EBS ストレージにアクセスできるわけではないため、特定の EC2 インスタンスのタイプを選択する際には注意が必要です。 注意: Amazon EBS ボリュームはネットワークに接続されたデバイスであるため、Amazon EC2 インスタンスによって実行される他のネットワーク I/O と共有ネットワークの全体的な負荷も、個々の Amazon EBS ボリュームのパフォーマンスに影響を与える可能性があります。 Amazon EC2 インスタンスが Amazon EBS ボリュームでプロビジョンド IOPS を十分に活用できるようにするには、選択した Amazon EC2 インスタンスのタイプを Amazon EBS 最適化インスタンスとして起動してください。  EBS ボリュームの詳細については、こちらを参照してください。 ### EC2 インスタンスストレージ（エフェメラルドライブ） EC2 インスタンスストレージは、稼働中の Amazon EC2 インスタンスをホストしているのと同じ物理サーバー上に構成され、接続されたディスクストレージのブロックで構成されています。 提供されるディスクストレージの容量は、Amazon EC2 インスタンスのタイプによって異なります。 インスタンスストレージを提供する Amazon EC2 インスタンスファミリーでは、インスタンスが大きいほど、インスタンスストアのボリュームが大きくなる傾向があります。 Amazon EC2 インスタンスファミリーにはストレージ最適化（I2）と高密度ストレージ（D2）があり、それぞれが特定の使用事例を対象とした特殊な用途のインスタンスストレージを提供しています。 例えば、I2 インスタンスは 365,000 超のランダム読み取り IOPS と 315,000 書き込み IOPS に対応できる非常に高速な SSD ベースのインスタンスストレージを提供し、コスト的に魅力的な価格モデルを提供しています。 このストレージは EBS ボリュームのように永続的ではなく、インスタンスの存続期間中のみ使用できるものであるため、接続を解除したり別のインスタンスに接続したりすることはできません。 インスタンスストレージは、絶えず変化する情報を一時的に保存するためのものです。 InterSystems のテクノロジーと製品の領域では、エンタープライズサービスバス（ESB）としての Ensemble や Health Connect の使用、エンタープライズキャッシュプロトコル（ECP）を使用するアプリケーションサーバー、または CSP Gateway と Web サーバーの使用などが、このタイプのストレージとストレージ最適化インスタンスタイプに適した使用事例になるでしょう。また、プロビジョニングツールと自動化ツールを使用することで、これらの効率を合理化して柔軟性を高めることができます。 インスタンスストアの詳細については、こちらを参照してください。 ## コンピューティング ### EC2 インスタンス さまざまな使用事例に最適化された多数のインスタンスタイプを利用できます。 インスタンスタイプは、CPU、メモリ、ストレージ、ネットワーク容量のさまざまな組み合わせで構成されており、それらを無数に組み合わせてアプリケーションのリソース要件を適切なサイズに調整できます。 このドキュメントでは、_Amazon EC2 の M4_ 汎用インスタンスタイプを適切な環境のサイジングを行うために参照しています。また、これらのインスタンスは EBS ボリュームの機能と最適化を提供しています。 アプリケーションの容量要件と価格モデルに基づいて、他のインスタンスを使用することもできます。 M4 インスタンスは最新世代の_汎用_インスタンスです。 このファミリーは、コンピューティング、メモリ、ネットワークリソースをバランスよく提供しているため、多くのアプリケーションに適しています。 仮想 CPU の数は 2 個から 64 個、メモリ容量は 8 GB から 256 GB を提供し、対応する専用 EBS 帯域幅が決まっています。 個々のインスタンスタイプに加えて、専用ホスト、スポットインスタンス、リザーブドインスタンス、専用インスタンスなどの階層化された分類もあり、それぞれ価格、パフォーマンス、分離の程度が異なります。 現在利用可能なインスタンスの可用性と詳細については、こちらを参照してください。 # 可用性と運用 ## Web/アプリサーバーの負荷分散 Cachéベースのアプリケーションには、外部および内部の負荷分散されたWebサーバーが必要となる場合があります。 外部のロードバランサーはインターネットまたは WAN（VPN または Direct Connect）経由でのアクセスに使用され、内部のロードバランサーは内部トラフィックに使用される可能性があります。 AWS Elastic Load Balancing は、アプリケーションロードバランサーとクラシックロードバランサーの 2 種類のロードバランサーを提供します。 ### クラシックロードバランサー クラシックロードバランサーは、アプリケーションやネットワークレベルの情報に基づいてトラフィックをルーティングし、高可用性、自動スケーリング、堅牢なセキュリティが必要な複数の EC2 インスタンス間でのトラフィックを単純にロードバランシングするのに適しています。仕様の詳細と機能については、こちらを参照してください。 ### アプリケーションロードバランサー アプリケーションロードバランサーは Elastic Load Balancing サービスの負荷分散オプションであり、アプリケーションレイヤーで動作し、1 つ以上の Amazon EC2 インスタンスで実行されている複数のサービスやコンテナ全体の内容に応じてルーティングのルールを定義する機能を提供します。 さらに、WebSockets および HTTP/2 に対応しています。仕様の詳細と機能については、こちらを参照してください。 ### 例 次の例では最高レベルの可用性を提供するため、独立したアベイラビリティーゾーンに 3 つの Web サーバーのセットが定義されています。 Web サーバーのロードバランサーは、ユーザーセッションを Cookie を使用する特定の EC2 インスタンスに固定する機能を提供する_スティッキーセッション_を使用して構成する必要があります。 ユーザーがアプリケーションにアクセスし続けると、トラフィックは同じインスタンスにルーティングされます。  次の図4では、AWS 内のクラシックロードバランサーの簡単な例を示しています。 **_図 4: クラシックロードバランサーの例_**  ## データベースミラーリング Caché ベースのアプリケーションを AWS にデプロイする場合、Caché データベースサーバーの高可用性を確保するには、同期的なデータベースミラーリングを使用して特定のプライマリ AWS リージョンで高可用性を確保し、稼働時間サービスレベル契約の要件によっては非同期なデータベースミラーリングを使用して災害復旧用のセカンダリ AWS リージョン内のホットスタンバイにデータを複製する必要があります。 データベースミラーは、フェイルオーバーメンバーと呼ばれる2つのデータベースシステムの論理グループです。これらのメンバーはネットワークでのみ接続された物理的に独立したシステムです。 ミラーは、2 つのシステムを解決した後、自動的に片方をプライマリシステムとするため、もう片方は自動的にバックアップシステムになります。 外部クライアントワークステーションまたはほかのコンピュータは、ミラーリング構成中に指定されたミラーの仮想IP（VIP）を介してミラーに接続します。 ミラーVIPは、ミラーのプライマリシステムのインターフェイスに自動的にバインドされます。  注意: AWS ではミラー VIP を構成することはできないため、代替ソリューションが考案されています。 ただし、サブネット間のミラーリングはサポートされています。 AWS にデータベースミラーをデプロイするための現在推奨されているのは、3 つの異なるアベイラビリティーゾーンの同じ VPC に 3 つのインスタンス（プライマリ、バックアップ、アービター）を構成することです。 こうすることで、AWS は常に 99.95% の SLA でこれらの VM のうち少なくとも 2 つが外部に接続されていることを保証します。 その結果、データベースのデータ自体の適切な分離と冗長性を提供しています。 AWS EC2 のサービスレベル契約に関する詳細については、こちらを参照してください。 フェイルオーバーメンバー間のネットワーク遅延には厳密な上限はありません。 **遅延の増加による影響は、アプリケーションによって異なります。** フェイルオーバーメンバー間のラウンドトリップ時間がディスク書き込みサービス時間と同じである場合、影響はありません。 ただし、アプリケーションがデータの永続化（ジャーナル同期と呼ばれることもあります）を待つ必要がある場合はラウンドトリップ時間が問題になることがあります。 データベースミラーリングとネットワーク遅延に関する詳細については、こちらを参照してください。 ### 仮想 IP アドレスと自動フェイルオーバー ほとんどの IaaS クラウドプロバイダーには、データベースのフェイルオーバー設計で一般的に使用される仮想 IP（VIP）アドレスを提供する機能がありません。 この問題を解決するために ECP クライアントや CSP Gateway などの最も一般的に使用される接続方法が Caché、Ensemble、HealthShare 内で拡張されたため、VIP の機能を使用してこれらをミラー対応にする必要はなくなりました。  xDBC、TCP/IP ソケットによる直接接続などの接続方法や、その他の直接接続プロトコルについては引き続き VIP を使用する必要があります。 この問題を解決するため、InterSystems のデータベースミラーリングテクノロジーは、AWS の Elastic Load Balancer（ELB）とやり取りして VIP のような機能を実現する API を使用することで、AWS 内でこれらの接続方法に対して自動フェイルオーバーを提供できるようにしています。その結果、AWS 内で完全かつ堅牢な高可用性を実現しています。  さらに、AWS は最近になってアプリケーションロードバランサーと呼ばれる新しいタイプの ELB を導入しました。 このタイプのロードバランサーはレイヤー 7 で実行され、コンテンツベースのルーティングをサポートし、コンテナで実行されるアプリケーションをサポートしています。 コンテンツベースのルーティングは、パーティション分割されたデータやデータシャーディングを使用するビッグデータタイプのプロジェクトのデプロイで特に役に立ちます。  仮想 IP の場合と同様に、これは唐突なネットワーク構成の変更であり、フェイルオーバーが発生していることを障害が発生したプライマリミラーメンバーに接続されている既存のクライアントに通知するアプリケーションロジックを必要としないものです。 障害の性質によっては、障害そのもの、アプリケーションのタイムアウトやエラー、新しいプライマリによる古いプライマリインスタンスの強制停止、あるいはクライアントが使用した TCP キープアライブタイマーの失効が原因でこれらの接続が終了する可能性があります。 その結果、ユーザーは再接続してログインする必要になるかもしれません。 この動作はアプリケーションの動作によって決まります。 利用可能なさまざまなタイプの ELB に関する詳細については、こちらをご覧ください。 #### **AWS EC2 インスタンスから AWS Elastic Load Balancer メソッドの呼び出し** このモデルでは、ELB はフェイルオーバーミラーメンバーと潜在的な DR 非同期ミラーメンバーの両方が定義され、現在のプライマリミラーメンバーであるアクティブなエントリが 1 つだけのサーバープールか、アクティブなミラーメンバーのエントリを 1 つ持つサーバープールのみを持つことができます。  _**図 5: Elastic Load Balancer と対話する API メソッド（内部）**_  ミラーメンバーがプライマリミラーメンバーになると、新しいプライマリミラーメンバーの ELB を調整/指示するために API 呼び出しが EC2 インスタンスから AWS ELB に発行されます。  _**図 6: ロードバランサーの API を使用したミラーメンバー B へのフェイルオーバー**_  同様のモデルは、プライマリミラーメンバーとバックアップミラーメンバーの両方が利用できなくなった場合の DR 非同期ミラーメンバーの昇格にも適用されます。 _**図 7: ロードバランサーの API を使用した DR 非同期ミラーのプライマリへの昇格**_  標準の推奨される DR 手順のとおり、上記図 6 の DR メンバーの昇格では非同期複製によるデータ損失の可能性があるため、人間による判断が必要になります。 ただし、その操作を実行した後は ELB 上での管理操作は必要ありません。 昇格中に API が呼び出されると、トラフィックが自動的にルーティングされます。 #### **API の詳細** AWS ロードバランサのリソースを呼び出すためのこの API は、具体的には次のようにプロシージャコールの一部として ^ZMIRROR ルーチンで定義されています。   $$CheckBecomePrimaryOK^ZMIRROR() このプロシージャの中に、AWS ELB REST API、コマンドラインインターフェイスなどから使用するために選択した API ロジックまたはメソッドを挿入します。 ELB と効果的かつ安全に対話するには、AWS Identity and Access Management（IAM）ロールを使用してください。これにより、長期間有効な認証情報を EC2 インスタンスに配布する必要がなくなります。 IAM ロールは、Caché が AWS ELB と対話するために使用できる一時的な権限を提供します。EC2 インスタンスに割り当てられた IAM ロールの使用に関する詳細は、こちらを参照してください。 #### AWS Elastic Load Balancer のポーリングメソッド 2017.1で利用可能な CSP Gateway の _mirror_status.cxw_ ページを使用するポーリングメソッドは、ELB サーバープールに追加された各ミラーメンバーに対する ELB ヘルスモニターのポーリングメソッドとして使用できます。 プライマリミラーのみが「SUCCESS」に応答するため、ネットワークトラフィックはアクティブなプライマリミラーメンバーのみに送信されます。  このメソッドでは、^ZMIRROR にロジックを追加する必要はありません。 ほとんどの負荷分散ネットワークアプライアンスには、ステータスチェックの実行頻度に制限があることに注意してください。 通常、最高頻度は一般的にほとんどの稼働時間サービスレベル契約で許容される 5 秒以上に設定されています。 次のリソースの HTTP リクエストは、ローカルキャッシュ構成のミラーメンバーのステータスをテストします。 **_ `/csp/bin/mirror_status.cxw`_** それ以外の場合、ミラーステータスリクエストのパスを実際の CSP ページのリクエストに使用されるのと同じ階層構造を使用し、適切なキャッシュサーバーとネームスペースに解決する必要があります。 例: /csp/user/ パスにある構成サービスアプリケーションのミラーステータスをテストする場合は次のようになります。 **_ `/csp/user/mirror_status.cxw`_** 注意: ミラーライセンスチェックを実行しても、CSP ライセンスは消費されません。 ターゲットインスタンスがアクティブなプライマリメンバーであるかどうかに応じて、ゲートウェイは以下の CSP 応答のいずれかを返します。 **** 成功（プライマリメンバーである）** ===============================    HTTP/1.1 200 OK    Content-Type: text/plain    Connection: close    Content-Length: 7    SUCCESS **** 失敗（プライマリメンバーではない）** ===============================    HTTP/1.1 503 Service Unavailable    Content-Type: text/plain    Connection: close    Content-Length: 6    FAILED **** 失敗（キャッシュサーバーが _Mirror_Status.cxw_ のリクエストをサポートしていない）** ===============================    HTTP/1.1 500 Internal Server Error    Content-Type: text/plain    Connection: close    Content-Length: 6    FAILED 次の図は、ポーリングメソッドを使用するさまざまなシナリオを表しています。 _**図 8: すべてのミラーメンバーへのポーリング**_  上の図 8 のように、すべてのミラーメンバーは動作しており、プライマリミラーメンバーのみがロードバランサーに「SUCCESS」を返しているため、ネットワークトラフィックはこのミラーメンバーにのみ送信されます。 _**図 9: ポーリングを使用したミラーメンバー B へのフェイルオーバー**_  次の図は、DR 非同期ミラーメンバーの負荷分散プールへの昇格を表しています。これは通常、同じ負荷分散ネットワークアプライアンスがすべてのミラーメンバーにサービスを提供していることを前提としています（地理的に分割されたシナリオについては、この記事の後半で説明します）。 標準の推奨される DR 手順のとおり、DR メンバーの昇格では非同期複製によるデータ損失の可能性があるため、人間による判断が必要になります。 ただし、その操作を実行した後は ELB 上での管理操作は必要ありません。 新しいプライマリは自動的に検出されます。 **_図 10: ポーリングを使用した DR 非同期ミラーメンバーのフェイルオーバーと昇格_**  ## バックアップと復元 バックアップ操作には、いくつかのオプションがあります。 InterSystems 製品を使用した AWS のデプロイでは、次の 3 つのオプションを実行できます。 最初の 2 つのオプションは、スナップショットを作成する前にデータベースによるディスクへの書き込みを一時停止し、スナップショットに成功したら更新を再開するというスナップショットタイプの手順を使用しています。 いずれかのスナップショット方式を使用してクリーンなバックアップを作成するには、次のおおまかな手順を実行します。 * データベースのFreeze API呼び出しにより、データベースへの書き込みを一時停止する。 * OS とデータディスクのスナップショットを作成する。 * データベースのThaw API呼び出しにより、Cachéの書き込みを再開する。 * バックアップファシリティはバックアップ場所にアーカイブする。 クリーンで一貫したバックアップを確保するために、整合性チェックなどの追加手順を定期的に追加することができます。 どのオプションを使用するかという決定ポイントは、組織の運用要件とポリシーによって異なります。 さまざまなオプションをさらに詳しく検討するには、InterSystemsにご相談ください。 ### EBS スナップショット EBS スナップショットは、高可用性で低コストの Amazon S3 ストレージにポイントインタイムスナップショットを作成するための非常に高速で効率的な方法です。 EBS スナップショットと共に InterSystems External Freeze および Thaw API の機能を使って、実質的に 24 時間 365 日の運用レジリエンシーとクリーンな定期バックアップを実現できます。 Amazon CloudWatch Events などの AWS が提供するサービスか、Cloud Ranger や N2W Software Cloud Protection Manager などの市場で入手可能なサードパーティ製ソリューションを使用してプロセスを自動化する方法は多数存在します。 また、AWS ダイレクト API を呼び出し、独自にカスタマイズしたバックアップソリューションをプログラムで作成することができます。API の活用方法の詳細については、こちらとこちらをご覧ください。 注意: InterSystems はこれらのサードパーティ製品を推奨または明示的に検証していません。 テストと検証はお客様の責任で実施してください。 ### 論理ボリュームマネージャのスナップショット 別の方法として、市場に出回っている多くのサードパーティ製バックアップツールを使用する場合は、VM そのものにバックアップエージェントを展開し、Linux の論理ボリュームマネージャ（LVM）のスナップショットか Windows のボリュームシャドウコピーサービス（VSS）と組み合わせてファイルレベルのバックアップを活用することができます。 このモデルには、Linux および Windows ベースのインスタンスをファイルレベルで復元できるというメリットがあります。 このソリューションで注意すべき点は、AWS やほとんどの IaaS クラウドプロバイダはテープメディアを提供しないため、すべてのバックアップリポジトリは短期アーカイブ用のディスクベースになっており、長期保管（LTR）を行うには Amazon S3 の低コストストレージ、そして最終的には Amazon Glacier を活用できるということです。 このモデルを使用する場合は、ディスクベースのバックアップリポジトリを最も効率的に使用できるように、重複除去テクノロジーをサポートするバックアップ製品を使用することを強くお勧めします。 こういったクラウド対応のバックアップ製品には、Commvault、EMC Networker、HPE Data Protector、Veritas Netbackup などさまざまな製品があります。  注意: InterSystems はこれらのサードパーティ製品を推奨または明示的に検証していません。 テストと検証はお客様の責任で実施してください。 ### Caché Online Backup 小規模なデプロイでは、組み込みの Caché Online Backup ファシリティもオプションとして考えられます。 InterSystems のデータベースオンラインバックアップユーティリティは、データベース内のすべてのブロックをキャプチャしてデータベースファイルにデータをバックアップし、出力をシーケンシャルファイルに書き込みます。 この、InterSystems独自のバックアップメカニズムは、本番システムのユーザーにダウンタイムを引き起こさないように設計されています。  AWS ではオンラインバックアップが完了した後、バックアップ出力ファイルとシステムが使用中のその他すべてのファイルをファイル共有（CIFS/NFS）として機能する EC2 にコピーする必要があります。 このプロセスは、仮想マシン内でスクリプト化して実行しなければなりません。 オンラインバックアップは、バックアップに低コストのソリューションを実装したい小規模サイト向けのエントリーレベルのアプローチですが、 データベースのサイズが大きくなるにつれ、スナップショットテクノロジーを使った外部バックアップがベストプラクティスとして推奨されます。外部ファイルのバックアップ、より高速な復元時間、エンタープライズ全体のデータビューと管理ツールなどのメリットがあります。 ## 災害復旧 AWS に Caché ベースのアプリケーションをデプロイする場合は、ネットワーク、サーバー、ストレージなどの DR リソースを異なる AWS リージョンか、最小限の独立したアベイラビリティーゾーンに配置することをお勧めします。 指定された DR AWS リージョンに必要な容量は、組織のニーズによって異なります。 ほとんどの場合、DRモードでの運用時には本番容量の100%が必要となりますが、弾性モデルとして必要になるまでは、より少ない容量をプロビジョニングできます。 容量が少ないと Web サーバーとアプリケーションサーバーの数が減り、データベースサーバーに使用できる EC2 インスタンスタイプがさらに小さくなる可能性があります。また、昇格時には EBS ボリュームが大きな EC2インスタンスタイプに接続されます。  非同期データベースミラーリングは、DR AWS リージョンの EC2 インスタンスに対する継続的な複製処理を実行するために使用されます。 ミラーリングは、データベースのトランザクションジャーナルを使用して、プライマリシステムのパフォーマンスへの影響を最小限に抑えながら、TCP/IPネットワーク経由で更新を複製します。 これらの DR 非同期ミラーメンバーには、ジャーナルファイルの圧縮と暗号化を構成することを強くお勧めします。 アプリケーションにアクセスする公開インターネット上のすべての外部クライアントは、追加の DNS サービスである Amazon Route53 経由でルーティングされます。 Amazon Route53 は、トラフィックを現在アクティブなデータセンターに転送するスイッチとして使用されます。Amazon Route53 は、主に次の 3 つの機能を実行します。 * **ドメイン登録** – Amazon Route53では、example.com などのドメイン名を登録できます。 * **ドメインネームシステム（DNS）サービス** – Amazon Route53 は、www.example.com などのわかりやすいドメイン名を 192.0.2.1 などの IP アドレスに変換します。 Amazon Route53 は世界中のネットワークに展開された権威 DNS サーバーを使用して DNS クエリに応答し、レイテンシを削減します。 * **ヘルスチェック** – Amazon Route53 はインターネット経由でアプリケーションに自動的にリクエストを送信し、到達可能であり、利用可能であり、機能していることを確認しています。 これらの機能に関する詳細は、こちらを参照してください。 このドキュメントでは、DNS フェイルオーバーと Route53 ヘルスチェックについて説明します。ヘルスチェックの監視と DNS フェイルオーバーの詳細は、こちらとこちらを参照してください。 Route53 は、各エンドポイントに通常のリクエストを送信してその応答を検証することで機能します。 エンドポイントが有効なレスポンスを提供できない場合、 DNSレスポンスには含まれなくなり、代わりに利用可能な代替エンドポイントを返します。 このようにして、ユーザートラフィックは障害のあるエンドポイントから離れ、利用可能なエンドポイントに向けられます。 上記の方法を使用すると、特定のリージョンと特定のミラーメンバーへのトラフィックのみが許可されます。 これは、この記事で前述した InterSystems CSP Gateway から提示される mirror_status.cxw ページであるエンドポイント定義によって制御されます。 プライマリミラーメンバーのみが、ヘルスチェックからの「SUCCESS」を HTTP 200 として報告します。 次の図は、フェイルオーバールーティングポリシーの概要を表しています。 この方法やその他の詳細については、こちらを参照してください。 _**図 11: Amazon Route53 のフェイルオーバールーティングポリシー**_  常に、エンドポイント監視に基づいて、1つのリージョンのみがオンライン状態を報告します。 これにより、トラフィックは常に1つのリージョンにのみ流れるようになります。 エンドポイント監視は、指定されたプライマリ AWS リージョンのアプリケーションがダウン状態であり、セカンダリ AWS リージョンのアプリケーションがライブになっていることを検出するため、リージョン間のフェイルオーバーにさらに手順を追加する必要はありません。 これは、DR 非同期ミラーメンバーが手動でプライマリに昇格されると、CSP Gateway が Elastic Load Balancer のエンドポイント監視に HTTP 200 を報告できるようになるためです。 上記のソリューションの代替案は多くあり、組織の運用要件やサービスレベル契約に基づいてカスタマイズすることができます。 ## モニタリング Amazon CloudWatch は、すべての AWS クラウドリソースとアプリケーションに監視サービスを提供できます。 Amazon CloudWatch を使用し、メトリックの収集と追跡、ログファイルの収集と監視、アラームの設定、AWS リソースの変更への自動対応を行うことができます。 Amazon CloudWatch は、Amazon EC2 インスタンス、アプリケーションとサービスによって生成されたカスタム指標、およびアプリケーションが生成したログファイルなどの AWS リソースを監視できます。 Amazon CloudWatch を使用し、システム全体のリソース使用率、アプリケーションパフォーマンス、運用状態を可視化できます。   詳細については、こちらを参照してください。 自動プロビジョニング 現在、Terraform、Cloud Forms、Open Stack、Amazon 独自の CloudFormation など、数多くのツールが市場に出回っています。 これらのツールを使用し、Chef / Puppet / Ansible などのその他のツールと組み合わせることで、DevOps に対応した完全な Infrastructure-as-Code を提供したり、アプリケーションの立ち上げを完全に自動化したりできます。 Amazon CloudFormation の詳細については、こちらを参照してください。 # ネットワーク接続 アプリケーションの接続要件に応じて、インターネット、VPN、または Amazon Direct Connect を使用した専用リンクのいずれかを使用して複数の接続モデルを利用することができます。 選択方法は、アプリケーションとユーザーのニーズによって異なります。 これら 3 つの方法の帯域幅使用率はそれぞれ異なるため、AWS 担当者に相談するか Amazon マネジメントコンソールで特定のリージョンで使用可能な接続オプションを確認することをお勧めします。 # セキュリティ パブリック IaaS クラウドプロバイダーにアプリケーションをデプロイするかどうかを決定するには注意が必要です。 組織のセキュリティコンプライアンスを維持するには、組織の標準セキュリティポリシーまたはクラウド専用に作成された新しいポリシーに従う必要があります。 また、組織のデータが国外に保存され、データが存在する国の法律に準拠している場合には関連するデータの主権を把握しておく必要があります。 クラウドデプロイメントには、クライアントデータセンターと物理的なセキュリティ管理の外にデータが置かれるため、付加リスクが伴います。 使用中でないデータ（データベースとジャーナル）と使用中のデータ（ネットワーク通信）には、InterSystemsのデータベースとジャーナル暗号化と合わせて、前者にはAESを、後者にはSSL/TLS暗号化を使用することを強くお勧めします。 すべての暗号化キー管理と同様に、データの安全を確保し、不要なデータアクセスやセキュリティ違反を防止するには、組織のポリシーに基づいて、適切な手順を文書化し、それに従う必要があります。 Amazonは、Caché ベースのアプリケーションに非常に安全な運用環境を提供するための広範なドキュメントと事例を提供しています。こちらで参照できる Identity Access Management（IAM）に関するさまざまなディスカッションのトピックを確認してください。 # アーキテクチャ図の例 下の図は、データベースミラーリング（同期フェイルオーバーと DR 非同期）、ECP を使用したアプリケーションサーバー、負荷分散された複数の Web サーバーの構成で高可用性を提供する典型的な Caché のインストール環境を表しています。 ## TrakCareの例 次の図は、負荷分散された複数の Web サーバー、ECP クライアントとしての 2 台のプリントサーバー、データベースミラーで構成される典型的な TrakCare のデプロイを表しています。 仮想IPアドレスは、ECPまたはCSP Gatewayに関連付けられていない接続にのみ使用されます。 ECPクライアントとCSP Gatewayはミラー対応であり、VIPを必要としません。 Direct Connect を使用している場合、災害復旧シナリオで有効にできる複数の回線やリージョンアクセスなどのオプションがあります。 電気通信事業者に相談し、事業者がサポートする高可用性と災害復旧シナリオを理解することが重要です。 下のサンプルリファレンスアーキテクチャ図には、アクティブまたはプライマリリージョンにおける高可用性と、プライマリ AWS リージョンが利用不可である場合の別の AWS リージョンへの災害復旧が含まれます。 また、この例では、データベースミラーには、1つのミラーセット内にTrakCare DB、TrakCare Analytics、およびIntegrationネームスペースが含まれています。 _**図 12: TrakCare AWS リファレンスアーキテクチャ図 – 物理アーキテクチャ**_  さらに、次の図は、関連するインストールされたエンドユーザ向けソフトウェア製品と機能的な目的で、より論理的なアーキテクチャを示しています。 _**図 13: TrakCare AWS リファレンスアーキテクチャ図 – 論理アーキテクチャ**_  ## HealthShare の例 次の図は、負荷分散される複数のWebサーバーと、Information Exchange、Patient Index、Personal Community、Health Insight、Health Connectといった複数のHealthShare製品による典型的なHealthSharaeデプロイメントを示しています。 それぞれの製品は、複数のアベイラビリティーゾーン内に 1 組のデータベースミラーを含めて高可用性を実現しています。 仮想IPアドレスは、ECPまたはCSP Gatewayに関連付けられていない接続にのみ使用されます。 HealthShare製品間のWebサービス通信に使用されるCSP Gatewayはミラー対応であり、VIPを必要としません。 下のサンプルリファレンスアーキテクチャ図には、アクティブまたはプライマリリージョンにおける高可用性と、プライマリリージョンが利用不可である場合の別の AWS リージョンへの災害復旧が含まれます。  _**図 14: HealthShare AWS リファレンスアーキテクチャ図 – 物理アーキテクチャ**_  さらに、次の図は、関連するインストール済みのエンドユーザ向けのソフトウェア製品、接続要件と手法、およびそれぞれの機能的な目的で、より論理的なアーキテクチャを示しています。 _**図 15: HealthShare AWS リファレンスアーキテクチャ図 – 論理アーキテクチャ**_  #

この度、InterSystems IRIS Data Platform、InterSystems IRIS for Health、HealthShare Health Connect、および InterSystems IRIS Studio の 2022.3 をリリースしました。 2022.3 は、継続的デリバリー（CD）リリースです。2022.3では、SQL管理、クラウド統合、KafkaおよびJMSアダプタ、SQL Loaderなどの分野にて、多くのアップデートや機能強化が実施されました。 新たにFHIR SQL BuilderとColumnar Storageの機能が含まれていますが、いずれもまだ実験的な機能です（本番用ではなく、アクティブなEarly Access Programが実施されています）。 リリース・ハイライト プラットホームの更新 InterSystems IRIS Data Platform 2022.3 では、実運用ワークロード向けに以下のOSのサポートが追加されます。 Oracle Linux 9 SUSE 15 SP4. SQL 機能強化 InterSystems IRIS SQL では、システムで読み取り可能なクエリ・プランの形式を提供するようになりました。この新しいオプションを使用すると、$SYSTEM.SQL.Explain() メソッドは、アクセスするテーブルとインデックスに関する詳細な情報を含む JSON ベースのクエリプランを生成するようになりました。以前のXMLベースの形式では、異なるステップを記述するために簡単な英語のフレーズを使用していましたが、新しい形式は、より徹底した分析やクエリプランのグラフ表示を行いたいツールから利用しやすくなっています。 このリリースでは、SQL文のランタイムパラメータをサンプリングするオプトイン機能を導入しています。ステートメントインデックスはすでに、詳細なランタイム統計や各SQL文のクエリプランなど、豊富なメタデータを記録しており、通常、キャッシュドクエリのコードをパラメータ化するプレースホルダに任意のリテラルを代入しています。現在、ステートメントインデックスは、これらのパラメータの実行値のサンプリングで拡張することができます。これらを正規化されたSQL文と組み合わせることができ、例えば、別の環境に対して実行される代表的な負荷を構築したり、新たなハードウェア環境のベンチマークや異なるインデックスセットでの実験などが可能です。 InterSystems IRIS SQL は、CREATE SCHEMA および DROP SCHEMA コマンドをサポートし、アプリケーション環境の設定と消去のスクリプトに含めることができるようになりました。 スピード・スケール・セキュリティ このリリースでは、InterSystems IRIS シャードクラスタに対して完全な弾力性が提供されます。DBA は API メソッドを呼び出して、シャードを削除するようにマークできるようになりました。このメソッドが発行されると、指定されたシャードからクラスタ内の他のデータノードにデータが直ちにオフロードされ、すべてのデータバケットが他のシャードに正常に移動されると、そのノードが自動的に切断されます。このプロセスはオンラインリバランシングと同じメカニズムを利用しているため、ユーザーはデータの移動中もシャードされたテーブルへの問い合わせやデータの取り込みを継続することができます。 アナリティクス・AI InterSystems Reports (Logi Report 19.2)のバージョンを更新しました。 主な改善点は以下の通りです。 ブックマーク機能 - Webレポート上のパラメータやフィルタを保存可能 Report Studio は、Report Server 上で利用でき、Server から直接レポートの追加編集が可能です。 Adaptive Analytics（AtScale2022.3）の更新版 主な改善点は以下の通りです。 Microsoft Excel のタイムライン機能をサポート データカタログベンダーにAtSCale Semantic Layerを公開するためのData Catalog API これらの機能の詳細については、以下のリンクから入手できます。 InterSystems IRIS 2022.3 documentation and release notes InterSystems IRIS for Health 2022.3 documentation and release notes HealthShare Health Connect 2022.3 documentation and release notes ソフトウェアの入手方法 通常通り、CDリリースには、サポートされているすべてのプラットフォーム用の古典的なインストール・パッケージと、Dockerコンテナ形式のコンテナ・イメージが付属しています。 完全なリストについては、サポートされるプラットフォームに関するドキュメントを参照してください。 インストール・パッケージとプレビュー・キーは、WRC の Continuous Delivery Releases サイトまたは評価サービスの Web サイトから入手できます。 InterSystems IRIS Studio は、コンポーネント配布ページで入手できます InterSystems IRIS および IRIS for Health の Enterprise Edition と Community Edition の両方、および対応するすべてのコンポーネントのコンテナ・イメージは、新しい InterSystems Container Registry の Web インターフェースから入手できます。 docker コマンドについての詳細は、こちらの投稿をご覧ください: Announcing the InterSystems Container Registry web user interfaceこのリリースのビルド番号は 2022.3.0.606.0 です。 FHIR SQL Builder 先に説明した通り、 FHIR SQL Builder 実験的な機能であり、アクティブな EAP (Early Access Program) の一部です。この機能をご試用いただくには IRIS for HealthのプロダクトマネージャであるPatrick Jamieson (patrick.jamieson@intersystems.com) までご連絡ください。

開発者の皆さん、こんにちは！ InterSystems セキュリティコンテスト は終了し、投票結果が発表されました！ この記事では、コンテスト受賞者を発表します！ 受賞された開発者の皆さん、👏おめでとうございます！🎊 🏆 Experts Nomination - 特別に選ばれた審査員によって選出されました。 🥇 1位 - $4,000 は、iris-disguise を開発された @Henry.HamonPereira さんに贈られました！ 🥈 2位 - $2,000 は、zap-api-scan-sample を開発された @José.Pereira さん @Henrique.GonçalvesDias さんに贈られました！ 🥉 3位 - $1,000 は、iris-saml-example を開発された @Dmitry.Maslennikov さんに贈られました！ さらに！ 🏅 $100 - API Security Mediator を開発された @Yuri.Gomes さんに贈られました！ 🏅 $100 - Data_APP_Security を開発された @Muhammad.Waseem さんに贈られました！ 🏅 $100 - Server Manager 3.0 Preview を開発された @John.Murray さんに贈られました！ 🏅 $100 - IRIS Middlewares を開発された @davimassaru.teixeiramuta v 🏅 $100 - isc-apptools-lockdow を開発された @MikhailenkoSergey さんに贈られました！ 🏅 $100 - Audit Mediator を開発された @Yuri.Gomes さんに贈られました！ 🏅 $100 - passwords-tool を開発された @Dmitry.Maslennikov さんに贈られました！ 🏅 $100 - appmsw-dbdeploy を開発された @MikhailenkoSergey さんに贈られました！ 🏆 Community Nomination - 最も多くの票を獲得したアプリケーションに贈られます。 🥇 1位 - $1,000 は、zap-api-scan-sample を開発された @José.Pereira さん @Henrique.GonçalvesDias さんに贈られました！ 🥈 2位 - $500 は、iris-disguise を開発された @Henry.HamonPereira さんに贈られました！ 🥉 3位 - $250 は、API Security Mediator を開発された @Yuri.Gomes さんに贈られました！ 🎊 受賞者の皆様、おめでとうございます！👏 今回も、コンテストにご注目いただきありがとうございました！ どうもありがとうございます。

開発者の皆さん、こんにちは！ 今週から データセットコンテスト の投票が始まります！ InterSystems IRIS を使い開発されたベストソリューションにぜひ、投票をお願いします！ 🔥 投票はこちらから！ 🔥 投票方法については、以下ご参照ください。 Experts nomination: インターシステムズの経験豊富な審査員がベストアプリを選び、Expert Nominationで賞品をノミネートします。 ⭐️ @Benjamin.DeBoe, Product Manager⭐️ @Robert.Kuszewski, Product Manager⭐️ @Raj.Singh5479, Product Manager⭐️ @Carmen.Logue, Product Manager⭐️ @Stefan.Wittmann, Product Manager⭐️ @Thomas.Dyar, Product Manager⭐️ @Eduard.Lebedyuk, Sales Engineer⭐️ @Guillaume.Rongier7183, Sales Engineer⭐️ @Evgeny.Shvarov, 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 へのサインインします（開発者コミュニティのアカウントを使用してください）。 投票ボタンは、開発者コミュニティ内で、質問／回答／記事の掲載／投稿に対するコメント など 記載いただいた方に対して有効になります。 ボタンが押せない場合は、コミュニティへのコメントやオリジナルの記事など、書き込みお願いします！詳細は、こちらの記事をご参照ください。 気が変わった場合は？　－　選択をキャンセルして別のアプリケーションに投票できます。 ぜひ 🔥これだ🔥 と思う作品に投票お願いします！ メモ：コンテストへ応募された作品は、投票週間中にバグを修正したり、アプリケーションを改良したりすることができますので、アプリケーションのリリースを見逃さずに購読してください。

開発者の皆さん、こんにちは！ InterSystems Interoperability コンテスト 2021 の投票でポイントが加算される「テクノロジーボーナス」が発表されました！ 加点があるテクノロジは以下の内容です： Business Process BPL または Business Rule の使用 カスタムアダプタの使用 Production EXtension(PEX) Java または .NET の使用 ワークフローエンジンの使用 Docker コンテナの使用 ZPM パッケージによるデプロイ オンラインデモ公開 Code Quality pass コミュニティに記事を投稿する YouTubeでビデオを公開する 詳細は以下の通りです。 Business Process BPL または Business Rules の使用 - 3 point ​​​IRIS Interoperabilityプロダクションの主要な機能の1つのビジネス・プロセスを BPL（Business Process Language）で記述した場合、加点されます。 ビジネス・プロセスについて詳細はドキュメントをご参照ください。 ビジネス・ルールはノーコード／ローコードのアプローチで Interoperabilityプロダクションの処理を管理できます。InterSystems IRISでは、ビジネス・ルール用エディタを用意しています。また、クラス定義に記述することもできます。 Business Process／Business Ruleのボーナスは、Interoperabilityプロダクションの開発にビジネス・プロセスやビジネス・ルールを使用した場合に加点されます。 ビジネス・ルールの例 ビジネス・ルールについて詳細はドキュメントをご参照ください。 カスタムアダプタの使用 - 2 point InterSystems Interoperabilityプロダクションでは、外部システムとの通信するビジネス・サービスやビジネス・オペレーションで使用できるインバウンド／アウトバウンドアダプタを提供しています。ファイルやEmailのようなアダプタはすぐにご利用いただけますし、独自にアダプタを開発することもできます。 あなたのプロダクションで、独自のカスタムインバンド／アウトバウンドアダプタを開発した場合、加点されます。 カスタムアダプタの例 アダプタについて詳細は、ドキュメントをご参照ください。 Production EXtension (PEX) の使用 - 4 points PEX は、Interoperabilityプロダクションの Java / .NETの拡張機能です。 Java / .NETのPEXをあなたのInteroperabilityプロダクションで使用した場合、加点されます。 PEX デモ PEXについて詳細はドキュメントをご参照ください。 Workflow エンジンの使用 - 2 point ワークフローエンジンは、ユーザ間のタスクの分配を自動化できるIRIS Interoperabilityの機能の1つです。 あなたのInteroperabilityプロダクションの中で、ワークフローエンジンを使用した場合、加点されます。 ワークフローについて詳細はドキュメントをご参照ください。 コミュニティが公開するモジュール： WorkflowAPI と WorkflowUI-ngx もあります。これらは、Angularで動作するワークフローエンジンで、優れたUIレイヤを提供しています。 Docker コンテナの利用 - 2 ポイント 応募するアプリケーションが Docker コンテナ版 InterSystems IRIS を使用している場合、Docker コンテナボーナスポイントを獲得できます。テンプレートの用意もあります。 ZPM Package のデプロイ - 2 ポイント　 フルスタックアプリケーションの ZPM(ObjectScript Package Manager) パッケージをビルドして公開し、一緒にデプロイできるようにすると、ボーナスポイントを獲得できます。 zpm "install your-multi-model-solution" ZPM クライアントをインストールして IRIS にログインしてコマンドを実行します。 ZPM について／ZPM Documentation あなたのアプリケーションのオンラインデモを作成する - 3 ポイント オンラインデモとしてアプリケーションをクラウドにプロビジョニングすると、さらに3ポイント獲得できます。 開発環境テンプレートやその他のデプロイメントオプションを使用することができます。例 サンプルアプリケーションの使用方法についてはビデオをご参照ください。 Code quality analysis with zero bugs - 1 ポイント コード管理のために、Githubアクションに code quality を含め（例）、ObjectScript のバグを 0 にした場合にボーナスポイントを獲得できます。 開発者コミュニティに記事を Upする - 2 ポイント 作成したアプリケーション／プロジェクトの概要を開発者コミュニティの記事として投稿した場合、1 記事に対して 2 ポイント獲得できます。 また、他言語へ記事を翻訳し、掲載した場合も同様にポイントを獲得できます。 Video on YouTube - 3 ポイント 開発した作品の動画を作成し、YouTube に掲載した場合、3ポイント獲得できます。 ※ ボーナスポイントについては、変更される可能性もあります。予めご了承ください。