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

それで出世が遅れ(ry

WFH 用に Shure MV7 を導入したら自分にはとてもいい買い物になった

要するに

オンラインミーティングのマイクとしていくつかの候補の中から Shure MV7 を買ってみた。そうすると普段は響きにくい、やや聞き取りにくいタイプの自分の声でも小さな声でミーティングの参加者にいい声が届けられるようになって、ミーティングで話し続けるのがオフラインの時よりも楽になったので買って良かった、という話です。

経緯

コロナ以前からオンラインミーティングは仕事の都合でしばしば利用していたのですが、その時は Audeze の Mobius を有線で、もしくはほとんど聞いているだけのときに Bluetooth 接続の片耳ヘッドセットを使っていました。当時は在宅勤務はしていなかったので事務所の机にマイクアームとかマイクを設置するのもなー…という感じで基本的にはヘッドセットタイプのものを使うのが前提でした(自分の中で)。

ところが昨年春以降、基本的に在宅勤務になって労働環境を自由に整備できるようになったのと、以前から音声入力に特化したデバイスであるマイクをオンラインミーティングに使ったら何が変わるのか、もしくは何も変わらないのかというのが気になっていたので試してみたくなったというわけです。

主な候補

  • Blue Yeti X: この手のマイクを探していたらだいたい勝手に候補になっている
  • HyperX QuadCast S: 虹色に光る笑、比較的安価
  • Shure SM7B: 渡辺直美さんが配信機材として Shure SM7B を選んでいた
  • Shure MV7: 渡辺直美さんが配信機材として Shure SM7B を選んでいた(ので SM7B の弟分の方)

ところが一旦試したくはなったものの、緊急性が低く、こういう感じに設置して使いたいなというイメージに乏しかったせいでしばらく積極的にマイクを探していませんでした。ところがある日リンク先の渡辺直美さんの動画をきっかけになんとなくこういう感じがいいなというイメージが出来上がり、候補を絞る段階に移りました。

Shure MV7 を選んだ理由

Just because you see so many people using this [Blue Yeti X] does not mean that this is the best option for you. Just do a little bit more research, find what microphone will work best for you. -- Podcastage, Blue Yeti X Review / Test (with Blue Yeti Comparison

  • 自分の用途ではカーディオイド以外の指向性のタイプを選択できる機能が不要だった
  • ミキサーはとりあえず無しで使えるマイクが良かった
  • Shure MV88 のユーザーだった(ついでに大昔に買った Shure SE215 も断線してはリケーブルしてずっと使っている)
  • USB-C ケーブルで手持ちのモバイルデバイスに直接挿して使える
  • リンク先(下)の Podcastage のレビュー動画を色々見て Shure MV7 が良さそうだった

順序から言うと正確には候補を絞り込んで、その中から改めて選択したわけではなくて候補を絞り込んでいく過程で上記の4つのどれかかな、と思うようになったわけですが Podcastage の膨大なマイクレビュー動画はとても参考になりました。さすがに全部は見ていませんがユーモアもあって観ていて楽しいのでマイクを買った今でも時々新着動画を観ています。

ちなみにマイクアームは Blue の compuss、ショックマウントも同じく Blue の radius III を使っています。こっちの方は特に深く考えず見た目と、マイクと同じ日に届く、とかそんな理由で購入しています。


www.youtube.com

使った感想

選んだのが主にボーカル向けのマイクだったということもあって、オンラインミーティングの時に他の参加者から声がいい(よくなった)と言われるようになったのは想定していたことなのですが、わりと普段聞き取りにくいと言われている自分の声で普通に話してもしっかり相手に届くようになったので、ちょっと大きめの会議室で集まって話すときのような、相手に聞こえるように声を出すぞ!という気持ちがなくてもよくなってとても話すのが楽になりました。

加えて、マイクからモニター出力している自分の声を聞くのも心地よいというか、そんなに悪くないなと思えるようになったのも思わぬ収穫でした。それにいいマイクを使っているとオンラインミーティングでちょっと音質の悪い人にメテオフォール型開発が押し進められそうになっても、そんなノイズだらけの声でゴリ押しができると思うのか?こちらの主張はいい声で説得力があるんだぞ、となるのでメンタルの安定にも一定の効果が見込めます(?)。

Power Automate で SharePoint の News が投稿されたら通知すると言うけれども…

はじめに

SharePoint News の機能をうまく使えないかと以前試した時にエディターが好みではなかったのでそれっきり投げ出していたのですが、Modern News になってからなのかその前なのかちょっとわかりませんが、最近使ってみるとエディターが以前より少し使いやすくなっていました。

それならばと、例えば Teams にこまごまと情報をばらまくよりは News のような形で情報をまとめて、あるいはキュレーションしてコンテンツにしておく手段の一つとして考えてもいいのかもしれません。となるとやはり、新着があったら通知したい、と思っても何ら不思議ではありません。今回はその実装を Power Automte で行ってみました。

ちなみに Teams のチームに関連づけされた SharePoint のサイトの News の通知をチームに対して行いたい場合は Teams の SharePoint News アプリを使うともっと簡単でいいと思います。

なお、以降 Power Automate の話が出てきますが、私が言語設定を英語にして利用している都合上、Power Automate のトリガーやアクションの名前が英語になっていますので、日本語で利用されている方は適宜脳内で変換してください。

結論から

SharePoint Online の News ページを作成するとページファイルが追加されるドキュメントライブラリ Site Pages のライブラリ ID を(手動で)取得し、その ID を Flow の SharePoint のトリガーアクションである Wnen a file is created (properties only)Library Name として指定した上でページファイルがあるフォルダ(/SitePages)を選択すると、トリガーアクションとして機能するので、PromoteState=2 の場合のみ通知を行うように条件分岐をすれば、Modern News が投稿された場合に自動的に通知を行うことが可能です。これだけなら非常に簡単な Flow です。

どのような経緯でこの結論に達したか

検索する

ごく一般的な方法としてインターネットを検索したところ、例えば Get notified by email when a news post is created on a SharePoint site とか、Using Power Automate for SharePoint News Notifications というような感じで答えっぽいものがすぐ出てきました。ほかにもいくつかあった気がしますが、数としてはそれほど多くはなさそうです。

写経をしてみる

せっかくなのでまずは写経してみます。トリガーアクションとして SharePointWhen a file is created or modified (properties only) を選択し、Site Address から任意のサイトを選択すると、Library Name にサイト内のライブラリの候補が現れますが、News のページがある Site Pages は候補に出てきません。それでも参考にした記事ではカスタム値として Site Pages を入力すればその先のアクションを構成できるとのことだったのですが、実際にやってみると Flow を保存する際に以下のようなエラーが発生し、Flow を保存できません。

Flow save failed with code 'DynamicOperationRequestClientFailure' and message 'The dynamic operation request to API 'sharepointonline' operation 'GetTable' failed with status code 'NotFound'. This may indicate invalid input parameters. Error response: { "status": 404, "message": "List not found\r\nclientRequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nserviceRequestId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }'.

別の方法を考える

上のエラーの内容を調べたり Library Name に入力する値をいくつか試してみましたが状況は改善しませんでした。 そこで、参考にした記事の考え方だけは拝借してなんとかライブラリだけ正しく参照できる値がないか調べてみたところ、Site Pages ライブラリに Power Automate のショートカットを発見しました。開いてみたところ、Send a customized email when a new file is added というあまりにも都合がよさそうな Flow が初めから用意されていたので、そのままテンプレートを使って Flow を作成してみました。

すると、トリガーアクションとして SharePointWhen a file is created (properties only) が選択されていたのですが、Library Namexxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx の形式の ID のような文字列が入力されていました。なるほど、そういう入力値は許容されるのかと初めて知ったのですが、この文字列の出所がわからないのでライブラリ ID なのかどうかを以下の方法で確認しました。

  1. ID を確認したいライブラリを開く
  2. 歯車アイコンをクリックして Library Settings を開く
  3. URL に含まれている ID を確認する

これで取得した文字列が Library Name に入力されている文字列と同じだったことから、少し面倒ですがこの ID を取得しておけばトリガーアクション以外でも Site Pages のファイルにアクセスできるようになると思います。

ちなみに、最初に参考にした記事のように When a file is created or modified (properties only) をトリガーアクションにすると公開後に編集して再公開してもトリガーが実行されてしまうので、最初に発行されたときだけ Flow が動けばいいという場合はトリガーアクションの Trigger Conditions で新規作成された場合のみ動くように条件を追加するか、今回のように When a file is created (properties only) をトリガーアクションにすればいいと思います。

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 などがありますし、包括的に現状を理解するのであればこれらに関しても同じように学習しておく必要がありますね。