2019年12月17日火曜日

HCL Master (2年連続 2度目)

今朝がた 2020 年の HCL Masters が発表されました。

HCL Masters Class of 2020


10月のノミネーションから今日まではどきどきでしたが、無事に再任していただけたようで嬉しい限りです。

ちなみに、1年目となる今年(2019年)はコラボレーション分野の IBM Champion がそのまま HCL Master として選ばれました。

世界中の著名なイベント登壇者やブロガーなど多くの有名人が選ばれている中、私もその中の一人になれたことを誇りに思います。

昨年末に IBM Champion として認められてから、人とお会いする機会がずいぶんと増え、その度に励ましていただけたことが、私自身のモチベーションとなっているように感じています。もちろん、発信した情報へのレスポンスも同様ですし、こういった認証制度で認められることは非常に励みになっています。

来年は HCL Master 2年目となるわけですが、このブログやのの会といったこれまでの活動を継続しつつ、ノーツコンソーシアムやテクてく夜会といったコミュニティーへも貢献していけたらいいなと思っています。

2019年12月7日土曜日

HCL Factory Tour 4 in Tokyo に参加しました

12月4日に東京コンベンションホールで開催された HCL Factory Tour 4 in Tokyo に参加しました。

海外のイベントに参加したことの無い私にとって、こんなに興奮した Notes/Domino 関連のイベントはこれまでなかったかもしれません。

ありがたいことに HCL Master には最前列がリザーブされてました。私は2列目の中央に陣取りました。平坦な会場ではまさに特等席でした。
この距離感。最前列は HCL Master 加藤氏のみ。
この席から私の iPhone で撮影したスライドとコメントを残しておこうと思います。
※以下Notes/Domino ばかりでごめんなさい

冒頭に登壇した Richard Jefts 氏は日本市場の重要性について語りました。
Richard Jefts 氏
日本に特化した戦略と投資について。
HCL Digital Solutions にとっての日本
ノーツコンソーシアム、のの会といったコミュニティやパートナーとのエコシステム。のの会関係者としては会場や設備といった面でこれからに期待が持てました。
戦略的パートナーとコミュニティとのエコシステム
IBM Cloudインフラにあるメールを移行するためのツールの提供と、移行先となるパートナーについて。ISW の右下に小さく日本の KTrick 社の文字も。
現行のクラウドメールの移行先となるパートナーと移行ツール

3製品についてロードマップ的な発表がありました。(次の3つのスライドの製品バージョンは今月でてくるものではなく、その1ステップ先のものです)
HCL Domino V12

HCL Connections V7

HCL Sametime V12
次は Json Gary 氏です。私がこのイベントで最も楽しみにしていたセッションです。彼は Domino の進化の方向性について熱心に語りました。

現在の Domino V10 も Docker 対応を謳っていますが、OS込みのイメージでなければなりません。しかしながら将来の Domino はずっとポータブルになりそうです。
クラウドネイティブプラットフォームとしての Domino へ進化

そしてコンテナ化された Domino や DX, Sametime, Connections が Kubernates 上で動作しているイメージも提示されました。ここから数枚は勉強不足によりついていけず。
k8s で動作する Domino や Connections
イベント駆動アーキテクチャと CloudEvents
標準イベントモデルに合わせ、統合を加速
会議室の状況をモニタリングするIoT(センサー)の情報で Dominoの予約データを更新し、更新イベントを受けて Microsoft Teams へ反映する、というイメージが示されました。
IoTとDomino、Microsoft Teamsとの統合のイメージ
次の画面は、先の Domino V12 のスライドにあった Designer Reimagined に相当するものと思います。LotusScript が VSCode に表示されています。
VisualStudio Code 上の LotusScript
次のスライドにある Translation Services とは LotusScript から JavaScript への変換を意味しているのだそうです。この点については嫌な予感がしなくもない。
Project Keep の概要

続いて Andrew Manby 氏から V11 の紹介です。
その前に、ローコード/ノーコードの開発ツール「HCL LEAP」がDomino上で動くよ!とアナウンスされてきましたが、既存の「HCL LEAP」と区別され、Dominoで動くほうは「Domino Volt」となることがわかりました。Volt の図柄は稲妻でイメージしやすいですね。
Domino版の名称は Domino Volt
V11 で注目すべき3つに焦点を絞って紹介しました。

  • Domino Volt
  • Domino Nomad
  • ActiveDirectory同期

Volt, Nomad, AD同期

新たに Low-code 基盤を追加

Domino Volt の eGA は 来年1H

Nomad は iPad のほか iPhone, Android, ChromeOS にも対応

Event Publisher は「文書の追加」といった Domino 上のイベントを公開する

ユーザーはAD上のユーザーのメールアドレスを知らなくても探せるようになる

Sametime はサードパーティーのWebミーティングとの統合をサポート

Notes V11 と Verse オンプレミス (VOP) 1.0.9

Domino V11 の拡張

前回の投稿で触れました DAOS tier 2 ストレージについて、イメージが更新されていましたのでひとこと。これまでの発表(資料のP27)を下(このイベント)のイメージと比較すると、tier 2 のオブジェクトが複数のままに変わったことがわかります。どこかで検証してみたいポイントです。
DAOS tier 2 ストレージの「新しい」イメージ
DQL では全文索引とワイルドカードを使用可能に
Domino 製品戦略
新たなライセンスモデル

ここまでが昼食前。昼食はお弁当が用意されており、おいしくいただきました。※写真撮り忘れた...

そして午後です。
再び登場の Andrew Manby 氏。いよいよ軽量クライアントが出てくるかと思って勝手にわくわくしている私。
シンクライアント戦略
ブラウザ内でNotesが動く、というイメージが示されました。WebAssembly で実現する軽量クライアントはインストール不要になります。
動くデモは見られず...残念!!
Verse のロードマップ

Verse 1.0.8, 1.0.9
 Verse 1.0.10 のスライドに Progressive Web App という言葉が登場しました。これはどのブラウザでも動作するウェブアプリです。パフォーマンスが気になります。
Verse 1.0.10 と PWA

SAML で TLS 1.2 をサポート


このあと、DX と Sametime と Connections についてそれぞれのトップによるセッション、(開発者ではない)Tim Clark 氏による Domino Volt を使ったアプリ開発のデモなどありました。Volt で作成したアプリは Domino Designer で開きますが、既存アプリをモダナイズするといった用途では使えません。

ここでバッサリ省いた内容については セッションの動画が公開されましたので、そちらでご確認いただけるかもしれません。

登壇者はグローバルの製品のトップばかりでした。最高の製品・サービスであり続けるために取り組んでいる事への情熱や自信といったものが伝わってきました。

Notes/Domino V11 のダウンロードは今月(2019年12月)20日(日本時間ではないと思いますが)に利用可能になります。いよいよですね!

2019/12/11 追記
日本語のセッションの資料英語のセッションの資料が公開されました。

2019年12月1日日曜日

DAOS tier 2 ストレージ

リッチテキストフィールドに添付したファイルは通常、データベース( .nsf ファイル)内に保存されますが、添付されたファイルの代わりに「チケット」をデータベース内に保存し、ファイルの実体をデータベースの外(レポジトリ)へ移動して .nlo という拡張子の「オブジェクト」として保持する DAOS (Domino Attachment and Object Service)という機能があります。

リッチテキストへの添付が便利すぎるため、ユーザーはサイズの大きいファイルを文書へ添付しがちですが、DAOS (私はダオスと呼称しています)がすばらしいのは、文書にファイル添付してサーバー上のデータベースへ保存するとか、他のDominoへ複製するなどして文書を転送するときに、転送先のレポジトリに添付ファイルと一致する DAOS のオブジェクトがあれば、添付ファイルの実体を転送せず、添付ファイルをチケットに自動で置き換えて nsf へ保存します。レポジトリに無い場合は、実体をレポジトリに移動します。nsf のサイズとサーバーへ転送するサイズを節約してくれます。

転送と書きましたが言い方を変えると、メールデータベースで DAOS を有効にした場合、サイズが 30MB の動画ファイルを添付したメールを同じホームサーバーを使う1000人へ送ったとしても、サーバー上の1001人のメールデータベース内のメール文書にはチケットがあるだけで、添付ファイルの実体はレポジトリに移動した1つのオブジェクトだけです。DAOSが無効の場合と比較すると、サーバー内のストレージは 30MB x 1000 = 約 30GB が節約されることになります。なお DAOS はメール以外のデータベースでも設定することができます。


さて、2019年12月にリリースされる Domino の次期バージョン V11 には、DAOS のストレージを2層にして、レポジトリ(tier 1)にあるオブジェクトのうち、一定期間参照されないものを S3 互換ストレージ(tier 2)へ移動する、という拡張があります。

直近のイベントで目にした、この拡張のイメージ図(「V11新機能と今後のロードマップ」27ページ)では、複数の Domino サーバーのレポジトリ(tier 1)にあるオブジェクトが、S3 互換ストレージ (tier 2) へ移動するのですが、「実体の同じ」オブジェクトがすでに tier 2 に存在すれば、新たに tier 2 へ移動することなしに tier 1 のオブジェクトを削除する、という風に見えます。※そんな説明は資料にはありません

Domino内の複数のDBから参照される同一の添付ファイルが、Domino内の tier 1 で1つのオブジェクトで管理され、さらに複数のサーバーにある同一の添付ファイルが tier 2 で1つのオブジェクトで管理されるようなのです。

ところで、レポジトリにあるオブジェクトは拡張子が nlo のファイルですが、デフォルトでは元サーバーの鍵で暗号化されます。暗号化された nlo は、他のDominoサーバーのレポジトリに作成されたオブジェクトを持ってきても使えないようになっています。

暗号化された nlo をそのまま tier 2 へ移動したのでは、他の Domino からオブジェクトを参照できても内容を読むことができないのではないでしょうか。

tier 1 に作成されるオブジェクトで暗号化を無効にすることは現行バージョンでも可能です。notes.ini に DAOS_ENCRYPT_NLO=0 を追加しておきます。

Domino V11 ベータ2 の What's New には、tier 2 を設定するにあたり暗号化を無効にしなければならないとは書いていません。複数の Domino で tier 2 を共有する場合の設定にも触れていますが、オブジェクトの暗号化については触れていませんでした。
また、暗号化されたオブジェクトを tier 2 へ移動する際、自動で復号化される、といった細かい話にも触れていません。

もし、現状 DAOS を複数の Domino で使っていて暗号化をデフォルトのまま有効にしている場合、同一ファイルから生成された nlo でも tier 2 上では Domino の数の nlo が作成されるかもしれないのです。これでは少々つまらないですよね。

そんなことを考えながら、ノーツコンソーシアム「ザ・ノーツ研究会」11月度の活動の中で検証してみようと取り組んでみましたが、敢え無く時間切れとなってしまいました...うーん、気になる!

このノーツ研究会で検証する前に V11 ベータ2 が公開され、その What's New を読んでいたとき DAOS tier 2 のことが記載されたのを見つけた(ベータ1には記載が無かった)ので、個人で aws のアカウントを作り、無料枠内で S3 を使って DAOS tier 2 を試してみました。

以下に V11 ベータ2 での印象とか、ベータフォーラムで聞いて分かったこと、What's New に書いていないことなどを、つらつらと書き残しておこうと思います。

あ、tier 2 の有効化やその設定方法は小野様のブログが詳しいです。

S3 にはいくつもの「リージョン」があります。ベータ2の What's New に書かれているリージョンは「米国東部(バージニア北部)」のものでしたが、テスト当初は米国内の違うリージョンにバケットを作成したものの Domino からの接続がうまくいかず(サーバー文書で設定する URL などの設定に問題があった可能性はありますが)結局は米国東部のリージョンにバケットを作成して接続できました。そのせいか、私の環境からだとパフォーマンスは恐ろしく悪く、tier 1 にあった約 1GB のオブジェクトをpushできない理由がわからないときに非常に難儀しました。テストするなら小さい添付ファイルから始めることをお勧めします。

DAOS tier2 に関連した統計情報や notes.ini に追加されるいくつかのパラメータには COS という単語が登場します。これは Cloud Object Storage を省略したものかと思います。

ベータでサポートするストレージは aws S3 と MinIO の2つでした。MinIO はオンプレミスに構築できる S3 互換ストレージのようで、Docker で使えるみたいです。
ひょっとすると aws s3 互換 を謳っているサービスなら使えるのかしら...と思ってグーグル先生に「aws s3 互換」と聞くと、MinIO 以外にもたくさんヒットしました。これらが tier 2 として使えるかどうかは不明です。

tier 1 から tier 2 へ push(移動)するにあたり、ファイルが最後に参照されてからの経過日数を基準としています。これはコンソールコマンド tell daosmgr objectinfo all を投入して出力される objectinfo.txt にある AGE の数値と比較しているように思います。

tier 2 の設定を行い、それが有効になると、show tasks コマンド投入で「DAOS Manager   S3Push: Idol」が出力されます。push している最中は Idol が Processing に変わりましたが、ここではオブジェクト(.nloのファイル)の名前はわかりません。
push しているオブジェクト名とサイズを知りたい場合、notes.ini へ DEBUG_COS_PROVIDER=2 をセットしておくと、show tasks ではありませんが、tier 2 への push する時にコンソール上に出力されていました。なお、このデバッグパラメータを追加すると、プログラムディレクトリ内に aws_sdk_yyyy-mm-dd-hh.log といったログが1時間おきに作成されます。

tier 2 への push は午前2時に実行されました。この時刻を変更できるかどうかは不明です。手動で tell daosmgr objectpush 0 をコンソールへ投入すれば、午前2時を待たずにすぐさま tier 2 へ push されます。このコマンドの最後にあるゼロは参照されなくなってからの日数を指しますので、ゼロを指定すると tier 1 にあるすべての nlo が push されます。サーバー文書の DAOS タブで、参照されなくなったオブジェクトを tier 2 へ移動するまでの日数を指定します(デフォルトは1000日)が、午前2時に tier 2 へ push する場合、この値をテストだからと 1 にしても数日待っても移動しませんでした。聞けばこれはバグで7日経過しないと Push されないとのことでした。製品版では修正されていることでしょう。

サイズが大きなオブジェクトの push に時間がかかり、渋滞するのではないかと心配な場合、push スレッドを多重化しておくことができる、と教えてもらいました。notes.ini へ DAOS_S3_PUSH_THREADS=n (nはスレッドの数)を追加します。

tier 2 への push が失敗する場合、notes.ini へ DEBUG_DAOSMGR_TRACE=1 を設定すると、少なくともエラーがわかると教えてもらったのですが、エラーが出なかったこともあり未確認です。

tier 2 へ push されたオブジェクトは、対応する添付を Notes から参照すると tier 1 へ落ちてくるのかと思いきやそうではなく、data ディレクトリ配下に objectStoreTemp という名前のフォルダが作成され TMP1.tmp といったファイルが作成されました。これが tier 2 からダウンロードされたオブジェクトで、クライアントから参照された実体なのだと思います。

最後に、ベータ2 では tier 2 へ push された後、tier 1 には .nlo という拡張子が .nlx に変わっただけのように見えるオブジェクトが存在しました。ベータではフォールバックのために .nlx として残していますが、製品版では削除される、とのことでした。


Domino V11 のリリースはもうすぐです。
Domino 上で動く LEAP やまだ見ぬ軽量クライアントは少々遅れてのリリースとなるようですが、それらを含めて V11 の登場が待ち遠しいです。