備考欄に感想を書くタイプのエンジニア

それで出世が遅れ(ry

SharePoint でブラウザから newform.aspx をカスタマイズする

はじめに

社員同士の情報共有とかコラボレーションとか言われるようになって久しいですが、自分がいわゆる SIer っぽい仕事をしなくなって導入とか運用という観点から Microsoft 製品と関わることもほとんどなくなっていた昨今。時代の流れか(?)今いる組織にも SharePoint ベースのチームサイトが導入されました。Notes から SharePoint への移行という SIer あるある案件でしたが、よくある話で素のまま使うのはちょっと…ということでどちらかというとエンドユーザー側の、権限が制限された中でどこまでカスタマイズができるのかなと探っていたのでした。

今回は、SharePoint のリストやライブラリで新しいアイテムを追加するときに表示される newform.aspxソースコードを編集することなくカスタマイズできることが分かったのでその話です。

実行環境

  • SharePoint Server 2013 (管理者ではないので詳細バージョンは不明)
  • IE11 (11.0.85、お察しください)
  • Microsoft Edge (Ver. 41.16299.665.0)

実際に動作を確認したのは SharePoint Server 2013、オンプレミス版ですが、SharePoint Server 2016 および SharePoint Online でも同じ機能、画面はあるので利用可能だと思います。特に Online はオンプレミス版よりも制限が大きい可能性が高いので使えるかもしれません。

最近のブラウザには開発者ツールが搭載されているので、newform.aspx を制御している CSS ファイルを特定するのは全然難しくないのですが、CSS を編集するのは影響範囲も大きいですし、そもそもサーバー上にあるファイルを直接編集する権限もない、そういう環境です。同じ理由で代替ファイルをアップロードする方法も使えません。

ちなみに Sharepoint をカスタマイズしたことがある方の中には SharePoint Designer というツールがあることをご存知の方がいらっしゃるかもしれませんが、SharePoint Designer は 1) ファイルサイズが大きすぎて社内のネットワークからダウンロードできない(負荷が大きくなるとかそういう理由で遮断される)。 2) インストールできない。という残念な条件が整っていたため利用できませんでした。このブログは 21 世紀平成最後の年に書かれています。

あと、SharePoint Designer は 2013 のバージョンで終了、今後は Microsoft Flow を使ってねという話もありますし、こういった使い方を知っておくのもいいかと思います。

本文を書くテキストボックスの横幅が狭い

ことの発端は、主に情報共有などのためにノウハウや技術情報を書くにあたってアイテムを作成する際に、本文を書くためのテキストボックスの幅が規定では 386 px、日本語ではわずか 33 文字で改行されてしまいます。縦はスクロールバーではなくテキスト量に合わせて伸びるのでまだましですが、できるなら横幅をもっと広くしたいという要望でした。

それで、結論から言うと次の手順でテキストボックスの幅を広げることが可能です。

  1. 新しいアイテムを作成する際に本文のテキストボックスの幅を広げたいリストまたはライブラリを開き、[リスト] タブから [フォーム Web パーツ] をクリックし、[既定の新しいフォーム] を選択します。
  2. [新しいフォーム] の編集ページが開いたら、[メイン] 領域内にある [Web パーツの追加] をクリックします。
  3. 追加する Web パーツの [カテゴリ] 項目から [フォーム] を、[パーツ] 項目から [HTML フォームの Web パーツ] を選択し、[追加] をクリックします。
  4. [HTML フォームの Web パーツ] の右端にあるドロップダウンリストから [Web パーツの編集] をクリックします
  5. 画面右端に表示された Web パーツの編集メニューの [フォーム コンテンツ] 項目から [ソースエディター…] をクリックします。
  6. [テキスト エディター] ウィンドウが開いたらはじめから書き込まれている内容をすべて削除し、後述の内容を入力して [保存] をクリックします。
  7. [テキスト エディター] ウィンドウが閉じたら、Web パーツ編集メニューの下部にある [適用] ボタンをクリックし、書き込んだ内容が反映されていたら [OK] をクリックして編集を終了します。
  8. さらに [ページ] タブにある [編集の終了] ボタンもクリックして [既定の新しいフォーム] の編集を終了します。

テキスト エディターに書き込むコード

<style type="text/css" >

/*width (幅) の値は任意です。*/
.ms-rtefield {width:800px;}

</style>

コードの解説

見ての通りでただ1行追加するだけの話なのですが、.ms-rtefield はリッチテキストフィールドのことで、これを指定した場合、SharePoint でいうところの [複数行テキスト(かつリッチ テキスト)] の列の横幅が上書きされると思われます。つまり厳密には同じページに [複数行テキスト(かつリッチ テキスト)] の列が複数ある場合はそれらすべてに影響します。

一方、同じページにある [1行テキスト] の横幅には影響がありません。影響がないということは Web パーツの列のすべての横幅がそろわないということでもありますので、[1行テキスト] のテキストエリアがやたらと横に伸びても横幅をそろえたい場合は .ms-long の横幅を指定すれば影響範囲がもう少し大きくなります。

実際にこの設定を行った後に、広がったテキストボックスの部分のソースを見てみると、body 要素に直接上の内容が書き込まれており、いわゆるカスケーディングの優先順位の仕組みを利用して通常は外部 CSS ファイルで指定されている内容を特定の部分だけ上書きしているように見えます。SharePoint Server のディレクトリにある newform.aspx ファイルを直接確認したわけではありませんが、おそらく設定を変更したタイミングで対象のリストのディレクトリにある newform.aspx ファイルの更新日時が変わっていると思います。

他にもやってみた

完全に余談ですが、構造が複雑なので要素を特定するところは意外に骨が折れるものの案外簡単に設定を上書きできるんだなと思い、単なる思い付きで [保存] ボタンの色だけ変えてみようかと思って追加したのが以下のコードです。

テキスト エディターに書き込むコード

<style type="text/css" >

/*background-color (背景色) の値は任意です。*/
input#ctl00_ctl33_g_c8d55b6b_5167_4750_b0cb_e1d95eb871ba_ctl00_toolBarTbl_RightRptControls_ctl00_ctl00_diidIOSaveItem {background-color:#69f0ae;}
input#ctl00_ctl33_g_c8d55b6b_5167_4750_b0cb_e1d95eb871ba_ctl00_toolBarTbl_RightRptControls_ctl00_ctl00_diidIOSaveItem:hover {background-color:#9fffe0;}

</style>

何だこれはと思うかもしれませんが、各 newform.aspx にある [保存] ボタンはそれぞれ個別の id が割り当てられており、特定の [保存] ボタンの背景色のみを変更する場合はこういう可読性の低い指定をしないといけませんでした。上の本文のテキストボックスも同様に、そこだけの設定を変える場合はこういった個別の id を指定する必要があります。newform.aspx が参照している CSS ファイルを見ると input[type=submit] という要素もあるのですが、これで指定してしまうと、当たり前ですが同じ要素のボタンは全部色が変わります。ご利用は計画的に。

注意点として

見ての通りファイルの内容を書き換える機能ですので、セキュリティの観点からルートのサイトコレクション上では利用できません。カスタムスクリプトを実行するような機能を実装した Web パーツをルートのサイトコレクションに設置したい場合は、グローバル管理者の権限でサイトの設定を変更する必要があるようです。詳細は Missing web part and features in office 365 から。

Cisco Telepresence Endpoint で短縮ダイヤルのような機能をマクロで実装した

はじめに

2017 年 11 月に Cisco Telepresence Endpoint 用ファームウェア CE9.2.1 がリリースされ、新しくマクロ開発フレームワークが導入されました。このマクロフレームワークでは xAPI と呼ばれる API を利用して、通常テレビ会議専用端末には標準で実装されていない設定項目を追加したり、イベント駆動の動作を実装したり、一連の動作を自動化したりできるようになります。JavaScript での実装になるので、JavaScript が書ける人であれば xAPI のドキュメントをちょっと読めば簡単なマクロはすぐに書けてしまいます。

また、室内制御(In-room Control)と呼ばれる拡張機能と併せることで、GUI 上にボタンやウィジェットを追加し、そこから作成したマクロを実行することも可能になります。

xAPI についてはドキュメントが公開されているので、利用している端末のシリーズに合わせて参照してもらえればいいかと思います(端末によって若干利用できる API が異なります)。

実際に実装してみる

昨年末に Cicso Systems Japan Advent Calendar 2017 で「シスコビデオ会議システムのマクロ機能で音楽プレイヤーを作ってみた」という記事が公開されていたので、写経してもよかったんですが、せっかくなので独自に何か作ってみようということで考えたのが短縮ダイヤルのような機能です。

テレビ会議の世界(?)で全然知らない人からテレビ会議のコールがあったり、逆に全然知らない人にコールしたりというようなシーンは基本的にはなくて、だいたい決まった人や場所にコールすることが多いかと思います。

Ciscoテレビ会議端末には発着履歴からコールしたり、お気に入りに登録したりする機能はありますが、本体画面上または Touch 10 上で最低 3 タップする必要があります。リモコンだともう少しボタンを押す回数が増えます。そこで、この回数をもう少し減らせないかなと考えたわけです。

結果としてタップ操作の場合は 2 タップまで減らせました。一方でリモコンの場合、ホーム画面で発信ボタン押すことでいきなり発信ページが開くのですが、設置したマクロではそのような動作を実装できないので、実装したマクロを実行するボタンを選択するために余計にボタンを押さなければならず、発信までにボタンを押す必要がある回数が増えてしまいました…。リモコンを使う端末は今の製品ラインナップの中では少数派なので無視しましょう。そうしましょう。

コードを見てもらえばわかる通り、とりあえず実装してみるかというノリで書いたので、連絡先がべた書きになっているのですが、このアドレスが使われなくなったりした場合にマクロのせいでメンテナンスをする手間が増えるのは嫌なので、テレビ会議端末のローカルアドレス帳の情報を呼び出すような実装に変えようかなと思っています。あと、別の人や場所を短縮に登録しなおしたいという場合も想定して編集もできれば、結構いい感じのマクロになりそうです。

マクロの構成ファイルはこちらで公開しています。

まとめ

マクロや室内制御拡張機能テレビ会議端末の Web コンソール上での実装となりますが、それぞれ *.js ファイルと *.xml ファイルでインポート/エクスポートできるので、大規模展開みたいなシーンではちょっと力不足な感じは否めないものの、端末以外の場所で構成を保存したり、コードを編集したりする分には特に問題ないかなと思います(SSH から直接コミットできたりするともっといいですが)。

ここでその是非を論じるつもりはありませんが、Ciscoテレビ会議端末は端末もしくはリモコンや Touch 10 のようなデバイスからは直接詳細な設定をするよりも、UI/UX をシンプルにしつつテレビ会議で利用する機能の操作に絞っていく傾向にあるように思いますが、もしそこに何か不満や付け足したい機能があったとするとマクロは非常に便利なものだと思います。

専門用語を使った定型に近い文章を英語で書くための勉強方法

この記事はプログラマのための 英語・外国語 Advent Clendar 2017 21 日目の投稿です。

IT 系のエンジニアが英語を使うといった場合に考えられるシチュエーションの一つに、ドキュメントや、利用ガイド、あるいは readme.md のようなあまりカジュアルではない文章を英語で書くということがあると思います。

近年の Google 翻訳の進化により、日本語の文章をそのまま Google 翻訳に投げ込めばほとんど問題がない英文が出てくるのは確かなのですが、ほんのちょっとしたところで文脈を考慮しない(できない)ことに起因して、意図していない微妙なニュアンスの違いが出てくることがよくあります。

特に上述のような媒体では、情報発信者の意図を確認することのコストが会話やチャットのようなリアルタイムコミュニケーションよりも高くなることから、できれば一度文章を読んだときにより多くの人が同じように解釈できる文章を書くのが良いと考えています。

そこで、大量のサンプルを通してこのような文章を書く方法の一つとして、Microsoft の公式ウェブサイトにある多言語翻訳されたドキュメントを利用する方法を紹介したいと思います。

実際に Microsoft のウェブサイトを利用してまず文章を英訳してみる

例えば、次の一文を考えます。別にコマンドプロンプトじゃなくても CURL じゃなくても構いません。どこにでも使えそうで簡単な文章のように見えます。

コマンドプロンプトを開き、CURL をインストールしたディレクトリに移動し、次のコマンドを実行します。

これぐらいならサンプルなどなくても訳せそうでしょうか。早速 Microsoft の英語の文章を見てみます。

Open a command prompt, navigate to the directory where you installed CURL, and run the following command.

Apache Spark streaming: Process data from Azure Event Hubs with Spark cluster on HDInsight

実は例示した文章は、上の参照リンクの日本語版から抜粋してきた文章であって、単に対応する文章を同じページの英語版から同じように抜粋しただけです。

それはともかくとして、この短い文章の中にも初学者が使い方を間違えやすい冠詞 a や、関係副詞 where、そして and の使い方が含まれています。そして「コマンドを実行する」という言葉を英訳するときに、実行という言葉に引きずられてついつい execute を使いたくなるかもしれませんし間違いではないと思いますが、こういうときによく使うのは run でしょう。これは文脈に依存した動詞の選択と言ってもいいかもしれません。Google さんがいい見本を見せてくれます。

Open a command prompt, change to the directory where CURL was installed, and execute the following command. — Google 翻訳

また、where 句以下の文章についても Google 翻訳は決して間違えているわけではありません。ただ、実は上述のリンク先のページを最初から読んでいくと、該当する文章(手順)の前に CURL をインストールする手順があることから、文章の読み手が CURL をインストールしているであろうことが文脈上想定できます。そういった意味で、Microsoft が書くように

...the directory where you installed CURL,

としたほうが、より自然だと言えるのではないでしょうか。 では、これはどうでしょう。日本語だと何の変哲もない、よく見かける表現です。

日本語:

アプリケーションが実行されると、各コンポーネントの横に緑色のチェックボックスが表示されます。

Google 翻訳版:

When the application runs, a green check box appears next to each component.

別に間違えていません。では Microsoft はこれをどう訳すのでしょうか。

Microsoft 版:

Once the application is running, each component has a green checkbox next to it.

Google との違いは a green check box を主語にするのか each component を主語にするのかという点です。いかがでしょうか。何度も言いますが Google 翻訳が間違えているというつもりはありません。でももし、あー Microsoft の英文のほうが好きかなーという印象を受けたのであれば、それは比較する意味があったと言えるのではないでしょうか。

この方法の利点

  • 同じ意味の文章で日本語 - 英語間を行き来できる
  • サンプルの文章の品質がそれなりに高い
  • サンプルをとれる技術的領域が広い
  • 結構面白い

この方法の利点は、日本語だと全く気にも留めない、誰でも翻訳できそうな表現を英語で表現する際でも、そういう風に言うのかということを学べる点と、Microsoft のウェブサイトを指定して適当に検索しても Microsoft が扱う技術領域が広いおかげでだいたい何かサンプルが見つかる点にあります。

あと、上の例で挙げたようにどうしても日本語に引きずられて対応する英単語を考えがちな場合は、こうやってたくさんのサンプルに触れることで、日本語→英語ではなかなか出てこない単語を使って同じ表現ができるようになってきますし、英語のドキュメントを読んでいても「あ、これ進研ゼミで出たやつだ!」的に同じような文章によく出くわすようになると思います。

この方法の欠点

  • 面倒な上に(特にシングルモニターでは)効率が悪い
  • Google 翻訳の精度の向上に伴ってこの方法の優位性がなくなりつつある
  • それなりの英語を理解できないとあまり有用ではない
  • 文章のパターンや特有の単語の使い方を覚える仕組みはない

数年前ぐらいまでは Google 翻訳の精度がそれほどよくなくて、自動翻訳しましたねと一目見てわかるくらいでしたが、以前と比べて翻訳精度が高くなたこともあり、手軽さでは敵わなくなってきています。

また、日本語と英語を比較するのにはやはり同時に同じページを見られるほうが良いので、ラップトップやスマートフォン等でこの方法を使うのは割と面倒です。

加えて、語学学習用ウェブサービスやアプリケーションとは違って、覚えるための仕組みは組み込まれていないので、その観点からどうかしたいのであれば、別途方法を考える必要があります。

おわりに

今となっては単なる昔話になってしまいますが、私がこの手の文章をよく書いていた当時は Microsoft 製品を主に扱うインフラエンジニアだったこともあって、Microsoft のウェブサイトにはお世話になりました。今は日本語のページから英語のページに移動しなくてもポップアップ機能で対応する英文を表示することができるようになっていますが、当時は URL の言語設定の部分(ja-jp, en-us)だけを書き換えて両方のページをうろうろしすぎて、Google から bot 扱いされることもしばしばでした。

最近では Microsoft のウェブサイトだけではなく、MozillaAWSGCPApple 等のウェブサイトでも同様の方法で日英文を比較することができる場合がありますので、ご自身が携わる分野があれば確認してみてはいかがでしょうか。ただし、有志による翻訳や、機械翻訳によって情報量が異なったり、参考にならなかったりする場合がありますのでご注意ください。

TX 本始めました

私は TX 業界で生業を行っているわけではないので、TX 本と言えばアレみたいな共通認識があるのかすらよく知りませんがこれです。

Transactional Information Systems: Theory, Algorithms, and Practice of Concurrency Control and Recovery (The Morgan Kaufmann Series in Data Management Systems)

この本のことを知ったのはもう4年も前のことで、きっかけは TX本勉強会終了 に書いてあったこれです。

TX本は、ミドルウェアやDBAでトップ・エンジニアを目指すのであれば、是非挑戦されることを勧めます。内容・難易度ともにS級クラスであることは保証させて頂きます。トップ・エンジニアではなくても、エンジニアであれば、いつかは挑戦を志してほしいですね。 それだけのテキストです。(強調は筆者)

これを読んだ当時私は SIer の端くれで、比較的実務に直結しやすい技術書は読む一方で、論文の類やを読んで楽しむ習慣はまだなく、まさにエンジニアとして挑戦してやろうと思いこの本を手にし、以降何度か読破に挑戦するもののあえなく撃沈ということを繰り返していました。今回は、これまでのように暇を見つけてドバっと読むのではなくて、少量(2,3 ページ程度)をルーチン化(平日は毎日)して隙間時間を利用して読んでいく手法に作戦を変更したところ、現時点で1か月弱続けることができているので、このままうまくいくといいなと思いながら読み進めています。

当時、というかつい最近まで 800 ページを超える鈍器を抱えて読むしかなかったと思うのですが、いま Amazon でこの本を探すとなんと Kindle 版なるものがいつの間にか出ています、すばらしい。

論文紹介: In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか

※これは システム系論文紹介 Advent Calendar 2016: ADVENTAR 1 日目の記事です。

昨今話題に事欠かない In-Memory DBMS ですが、暇に任せて Hekaton 関連で何か(←忘れました)を調べていたときに出くわした論文がこちらです。タイトルは

Larger-than-Memory Data Management on Modern Storage Hardware for In-Memory OLTP Database Systems

一応和訳しておくと In-Memory OLAP データベースシステムにおいて、現代のストレージハードウェア上にあるメモリよりも大きなサイズのデータをどのように管理するのか、という感じでしょうか。

先に結論を言うと後述する通り、今日では HDD だけではない、さまざまなストレージ技術を利用したストレージデバイスが利用可能で、それらをメモリの外の二次ストレージとして利用するときには、それぞれのストレージにとって最適な利用方法があり、その方法いかんでパフォーマンスが何倍にも向上したり、逆にかなり落ち込んだりします、ということを検証、考察したのが本論文の主な内容になります。

知っておくとよい予備知識

ご覧の通り、知っておくとよい予備知識を並べただけで読まないといけない文章(英語論文含む)が積もってしまって大変なことになってしまうのですが、これらの知識なしに上述のような論文に記述されている結論を読んでも「ふーん、まぁそうだよね…。」ぐらいの感想しか出てこないかと思うので、背景まで含めて読んでいただくとよりよいかと思います。

ストレージ関連で言うと、メモリのサイズを上回るデータを退避させる対象の二次ストレージとして、おなじみの HDD や NAND ベースの SSD の他に、次のようなストレージが本論文中で挙げられています。あと、NVRAM は non-volatile RAM、つまり不揮発性ランダムアクセスメモリについても言及があります。

ストレージ関連

一方、in-memory DBMS に関しては以下の DBMS が言及されています。最初に MongoDB のリンクを置いたのは、1章で仮想メモリにアクセスした際にアクセス対象のデータが物理メモリ上になくページフォールトが発生し、トランザクションのパフォーマンスに影響が出る最近の例として挙げられていたためです。具体的に言うとメモリ管理に MMAPv1 を使っている Ver. 3.0 以前の MongoDB です(Ver. 3.0 以降は Storage Engine として WiredTiger を選択できるため改善が可能です)。

DBMS 関連
その他

論文の概要

in-memory DBMS は OLTP のワークロードの処理において、従来のディスクストレージの利用を前提とした DBMS よりも遥かに優れた性能を発揮しますが、それは現状扱う対象のデータベースのサイズが物理メモリよりも小さい場合に限られています。その制約がボトルネックになることを回避するための方法として、アクセス頻度の低いデータをメモリに留めておくのではなく、二次ストレージに退避させることで、物理メモリをアクセス頻度がより高いデータの処理により多く割り当てようという考え方があります。

この論文では、では具体的にどういった方法でデータを二次ストレージに退避させるのか、退避させたデータをどのようにメモリに戻すのかということ、それに加えて HDD やそれ以外のストレージデバイスを二次ストレージとして利用するときにそれらがパフォーマンスにどのような影響を与えるのか、そういった包括的なデザインをどのように決定し構成すればいいのかということを5つの異なるストレージテクノロジーを採用したストレージデバイスを用いることで評価しています。

評価の対象ストレージデバイ

in-memory DBMS の一つである H-Store DBMS に対して以下の5つの異なるパフォーマンス特性を持つストレージデバイスを二次ストレージとして利用します。

  • HDD、いわゆる従来型の磁気記憶装置。昨今は SMR(後述) や PMR(Perpendicular Magnetic Recording, 垂直磁気記録方式) 特別するために CMR(Conventional Magnetic Recording) と呼ばれることもあるようです
  • SMR HDD、瓦記録あるいはシングル時期記録方式と呼ばれる記録方式を採用した HDD
  • NAND ベース SSD、いわゆる普通の SSD
  • 3D-XPoint、2層のクロスポイント構造を用いた大容量メモリ。今回はそれと同様の技術を用いたエミュレーター利用します
  • NVRAM、不揮発性ランダムアクセスメモリのこと。これには PCM(相変化メモリ)、メモリスター、STT-MRAM(スピン注入磁気反転型磁気メモリ)を含んでいます

DBMS 側のコールドデータの扱い方に関する方針(ポリシー)の説明

まず、ホットではないデータを二次ストレージに退避させるために、DBMS が何らかの指標をもとに退避させるデータを特定する必要があります。本論文中ではその方法として H-Store DBMSApache Geode が採用しているオンラインのアプローチと Siberia や VoltDB が採用しているオフラインのアプローチの2つについて説明しています。簡単に言うと、オンラインのアプローチでは LRU (Least Recently Used) アルゴリズムに基づいたリストを管理し、もっともアクセス頻度が少ないデータを二次ストレージに退避させます。一方オフラインのアプローチでは、データへのアクセスをログに残し、別の専用スレッドでこのログからアクセス頻度を解析し、どのデータがコールドなのかを特定します。

次にデータを退避したという情報をどういう手段でメモリに保持しておくのかという問題に対し、H-Store DBMS、Hekaton、および VoltDB が採用しているそれぞれの方法について説明していますが、詳しくは H-Store に関しては H-Store 公式のアンチキャッシュに関するドキュメント、Hekaton については、すでに紹介済みの Trekking Through Siberia: Managing Cold Data in a Memory - Optimized Database あたりを確認しておくとよいと思います。

二次ストレージへのアクセス方法とその方針(ポリシー)の説明

次の章ではコールドデータストレージに採用されているテクノロジーに密接にかかわるポリシーとしてコールドストレージへのアクセス方法とその方針について大きく以下の3つの観点から説明しています。

  • コールドな状態のデータをどのように取得するのか
  • どのような状況でコールドデータをメモリにマージするのか
  • ブロック単位でのアクセスとバイト単位でのアクセス

より具体的な手法については、その次の実験解析の章でそれぞれのストレージデバイスに対していくつかの条件ごとのパフォーマンスを計測するという形でこれらのポリシーの決定がパフォーマンスに及ぼす影響について検証を行っています。

実験解析

H-Store DBMS が構成された dual socket の Intel Xeon E5-4620 2.60GHz(ソケットあたり 8 コア)の CPU と 432GB の DDR2 RAM を搭載しているマシンに各種二次ストレージを接続し、それぞれ前項の観点からパフォーマンスを計測しています。詳細は論文を見ていただいたほうがいいかと思いますが、取得するデータブロックのサイズや取得方法、アクセスパターン分布の違いが各ストレージデバイスの特性を露わにし、特性に応じたパフォーマンスを出していることがわかるかと思います。また TPC-C を利用したベンチマーク結果の他に Voter や TATP といったベンチマークの結果を見ていると、NVRAM のパフォーマンスが DRAM に迫っている様子が見られます。一方で、処理内容に対して適切な構成を行わずにただレイテンシーの低いストレージを使っても、それこそ最適化された HDD ほどにもパフォーマンスが出ない状況もある、ということがわかります。

関連する研究

今回実験をするにあたって利用した H-Store DMBS が採用しているアンチキャッシュというアーキテクチャですが、これはメモリ上にあるデータをディスク上にキャッシュすることに反する、つまりより多くのデータをメモリに最適化された状態でメモリ上に保持しつつ、ディスクをデータのホストとしてではなく、アクセス頻度がほとんどなくなったコールドデータ用の拡張ストレージとして利用するアーキテクチャです。他方、キャッシュするということは一般的に、パフォーマンスを向上させるためにディスクのデータをメモリ上にキャッシュするという意味になります。このアーキテクチャは OS における仮想メモリスワップと同じような考え方にもとづいて実装されているとのこと。

本論文では、H-Store DBMS を利用していたためか、上記の実際の動作について多くの説明がこの章でなされていますが、同じ in-memory DBMS でも Microsoft の Siberia や VoltDB (EPFL のカスタマイズ済み)、Apache Geode、MemSQL 等それぞれ異なったポリシーのもとに異なった実装でコールドデータを扱っていることにも触れており、それぞれがどのように違うのかという興味をそそられます。

結論

実験の結果として、採用しているストレージ技術が異なったハードウェアデバイスを利用する場合にはそれぞれに適した構成を DBMS 側で実施することで、いわゆる既定値のような構成でデータ処理を行った場合と比べて3倍以上のパフォーマンスの改善が見られるということがわかったと結論づけています。あと、私が個人的に実験解析の章で NVRAM のパフォーマンスが DRAM のパフォーマンスに迫っている状況を見て驚いたのですが、それは執筆者も同じだったようで、論文のくくりとしてそのことに言及していました。

感想

たまたまこの論文を見つけたときにはなかなか面白い論文だなと思っていたのですが、参考文献を読んだり同じようなキーワードで検索したりすると同じような研究があちこちでされており、ある意味でホットな話題なんだなという印象を受けました。論文の内容自体もそうですが、予備知識の方で列挙した内容についても極めてハードウェアと関連した事が多いです。DBMS のチューニングはするが DBMS が利用するストレージで採用されている技術のことなど知らない、と言うことは簡単ですがその結果、単にそのことを考慮しないだけで安易にデータ処理のパフォーマンスを1/3以下にしてしまうことになりかねないということを今後の DBMS の設計に関して言えばよく理解しておく必要があるなと思います。

余談で本論文では話題になりませんでしたが、in-memory DBMS といえば他に Oracle の TimesTen や SAP HANA、MIT の Silo、CWI の MonetDB などがありますし、包括的に現状を理解するのであればこれらに関しても同じように学習しておく必要がありますね。

Exchange 2013 CU6 以降の Workload Management の扱い方

先日、これと似たような出来事にでくわしまして。

FIX: Mailbox migration from Exchange Server 2007 to Exchange Server 2013 is very slow

トラブルシューティング等紆余曲折あった中で上の KB と Workload Management の話が出てきて、そういえば Workload Management のポリシーを管理する PowerShell のコマンドがあったんじゃなかったかなと、調べてみたところ…

The -ResourcePolicy, -WorkloadManagementPolicy and *-WorkloadPolicy system workload management cmdlets have been deprecated. System workload management settings should be customized only under the direction of Microsoft Customer Service and Support. ―Exchange workload management

いつの間にかなくなっていました。実際には CU6 からなくなっていたようで、つまり2年以上前になくなっていた(現在は CU14)わけなのでした。普段使うようなコマンドじゃないので全然気が付きませんでした。

じゃあ、CU6 以降、Workload Management (ポリシー)はどうやって管理するのかというと、上の引用にある通り Microsoft サポートが状況を鑑みて必要と判断できるときに方法をお伝えします、という感じでしょうか。ところが話にはもう少し続きがあって、ちょうど CU6 以降から追加されたのが次の PowerShell コマンドなのですが、

  • Get-SettingOverride
  • New-SettingOverride
  • Remove-SettingOverride
  • Set-SettingOverride

冒頭でリンクを張った KB 内にも記載があるように New-SettingOverride-Component パラメーターに WorkloadManagement という引数がありまして、Workload Management の既定の設定内容を変更できるようになっています(もちろん引数はほかにもあります)。

しかし、これらのコマンドで Get-Help してみると、出力された SYNOPSIS 欄(日本語だと概要?)に Microsoft のサポートから指示があった場合に使ってください、という旨の記載があります。実際 Exchange 側で設けている閾値を大きく変更する(または無効化する)ことにもなりますので、用法・用量を守って正しくお使いください。

ちなみに Microsoft は上述の方針を変えるつもりはないようで、公式にこれらのコマンドのリファレンスになるウェブサイトはリリースから2年以上たった今でも見当たりません。もっとも CU11 以降は閾値がより適正な値(十分に大きい、つまり閾値ボトルネックにならないレベルに大きい閾値)に変更されたようで、Workload Management のポリシーを規定値から変更する必要というかそんな機会はほとんどやってこなさそうではありますが、掘るといろいろ出てきそうな部分でもあります。

最近学んだこと: CasperJS を利用して Amazon での買物を自動化する

ここ1週間ほど、ウェブサイトのテスト目的で CasperJS を利用していて、せっかくなので公開できるレベルのコードもなにか書いておこうと思ったのでした。とは言え、特定のウェブサイトに対するテスト スクリプトなんて一般化して公開できないので、なぜか CasperJS で Amazon で買い物する動作をコードにしました。

※後述のコードは 2016 年 6 月時点での Amazon.co.jp のウェブサイトのナビゲーション要素を利用している都合上、ウェブサイトの構成が変わったり刷新されたりすると使えなくなります。

したこと

PhantomJS と CasperJS をインストールする

実行環境は以下の通りですが、wget する場合に Bitbucket を利用する例がネットに散見されるものの、どうも現在何らかの理由で使えないようなので、こちらを使うと良さそうです。CasperJS は公式にあるように $ git clone git://github.com/casperjs/casperjs.git しました。

環境
  • OS: Amazon Linux AMI release 2016.3
  • PhantomJS: 2.1.1
  • CasperJS: 1.1.1

コードを書く

書きました。

変わったところと言えば、注文する商品がアルコールを含む商品扱いされているため、[注文の確定] をする際に

[お客様の年齢確認をさせていただいております。: 20歳未満のお客様の酒類の購入や飲酒は日本の法律により固く禁じられています。お客様が20歳以上の場合は、このチェックボックスをクリックしてから注文を確定してください。]

というチェックボックスにチェックを入れないと [注文を確定する] ボタンをクリックできないところでしょうか。要素名が name="wineNotice" っていうのが面白いですね。

その仕組みを覗いてみると、上記のチェックボックスtrue または false に応じて [注文を確定する] ボタンの span class="a-button a-button-primary continue-button place-order-button-link a-button-span12" style="display: none;"span class="continue-button-blocker a-button a-button-primary a-button-disabled a-button-span12" style="display: inline-block;" の部分が入れ替わって、ボタンが有効化されたり無効化されたりしている都合上、waitForSelector() でクリックできるようになるまで待ってあげる処理が必要でした。display: none;/inline-block; の部分で判定する方法もありかなとは思います。

ちなみに、この処理というか注文フローは全世界共通かというとおそらく違っていて、例えばアメリカだと州によって法律が違うことから、アルコールを含む商品を注文する場合、注文の初期の段階で州を選択しないとカートにも入れられないという状態でした。つまり、このコードの汎用性は非常に乏しいです(かなしみ)。

ところで、コードとは全然関係ない話ですがこのスクリプトで注文しているノンアルコール ビール「龍馬 1865」は、麦芽とホップだけで作られていてノンアルコール ビールなのに結構ビール味であり、しかも他の大手が作っているノンアルコール ビールのように甘味料が入っていない事もあって、ある種のもったりした後味もないのでおすすめです。サントリーのオールフリーなんかは最近のリニューアル後だいぶおいしくなった印象ですが、この龍馬 1865 と比べるとまだまだですし、すべて個人の感想です。

次にしたいこと

  • サーバーレス

    上述の通り、現状では CasperJS の実行環境を EC2 上に構成しているのですが、たったこれだけのために t2.micro とはいえ EC2 インスタンスを起動しているということと、せっかくなのでスケジュールも組み込みたい、ということで Amazon Lambda に組み込めないかなと考えています。

  • Readable Code

    画面遷移数で言うとたったの4ページほどのことなのですが、なぜか Amazon のログイン フォームが Fill() もしくは FillSelector() で対応できなかったので SendKeys()Click() で押し切ったところとか、もう少しブラッシュアップできるのではないかと思っています。

  • 処理の追加

    現状では、予期しないポップアップ(Amazon Prime を使ってみませんか、的なもの)が発生するとそれだけで何も言わずに処理が終わってしまうとか、数量が変更できないとか住所が既定値とか配送日が選択できないとか、いろいろ実装されていると便利な処理がありますので、追加できるといいなと思っています。

  • クレデンシャル情報の暗号化/外部参照

    ベタ書きになっているので取り扱い注意です。ただし、Lambda に載せるとなるとこの辺りどうなるのかな、という感じです(わかりません)。

Appendix: Resurrectio (ver. 0.5) の使用感

Resurrectio は、Chrome Extension の一つで、ブラウザ上で実行した動作を CasperJS のコードに変換してくれるという、夢の様なツールです。ということで試してみたのですが、結論から言うとあまりスクラッチから書く手間を削減できるかというとそんなことはないかな、という印象でした。例えば上述のスクリプトと同じことを Resurrectio でコード化するとこのようになります(最後の注文のクリックは省略)。

テスト利用を想定したコードになっていることはさておき、メールアドレスの入力ステップが認識されていなかったり、クリックしている場所を XPath で表現していたり(気持ちはわかりますし XPath を使うのが悪いわけではないですが)、ナビゲーション要素内のテキストを利用したりしている感じがコンボになって、あまり好きではありませんでした。