astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

人事としてアスタミューゼに入社しました

はじめに

アスタミューゼ 人事総務部 部長のISHWAと申します。 つい最近まで厳しい暑さが続いていましたが、秋が深まる中で気温も下がってきました。季節の変わり目で風邪などひきやすい時期ですので、皆様も体調にはどうぞお気をつけください。

さて、人事の私にブログ記事のお話がまわってきましたので、この記事で人事として入社した私の視点から、アスタミューゼの魅力や最近のできごとについて、少しやわらかめにご紹介をしたいと思います。「どのような事業をやっているか」といったことよりも、今回は私自身のご紹介や最近の社内の出来事などをご紹介していこうと思います。技術的なお話ではありませんが、この記事を見たエンジニアの皆様が、「アスタミューゼのお話をもう少し詳しくお聞きしてみたいな」と感じていただけましたら幸いです。

自己紹介

エンジニアブログなので、私の過去のエンジニア経験なども含めて自己紹介させていただきます。 私の社会人生活はエンジニアとしてスタートしました。新卒で入社したI●M系列の某会社は、OSI7層の全てのレイヤーを学べるとのことで、システム開発を幅広く学びたいと思い入社を決めました。領域としてはアプリケーションよりの開発を任され、BtoB向けの業務システムを開発・導入するエンジニアを約3年半経験しました。

今から約15年ほど前の昔のお話になりますが、当時のエピソード等を少しご紹介します。 エンジニアだった当時の開発環境は、AIX、AS400、WindowsNT Server(SP6a)等で、Visual Basic 6.0、Lotus Notes Domino、またERPのJDEdwards(OneWorld)などを動かしていました。案件としては民間企業や官公庁向けのシステム開発を主に担当していました。官公庁系の案件では、東北方面にひとりで2週間以上泊まり込み、システムの導入作業を行ったことや、映像・集計関連のシステム運用で地方のテレビ局に泊まり込みながらインフラの運用・監視をしたことなどはとても良い思い出です。

私が主に経験していたBtoB向けの業務システム(見積作成から経理計上までの一連の流れの機能)は非常に地味な部分もあるものの(当時は)大変難しく、社内でも経験や知識の豊富な社員が少ない状況でした。一人で言語やパッケージの動作を学びながら、仕様どおりにうまく動作せずにシステム間の連携テストを深夜・早朝まで続けている時などは、まるで「永遠にひとりでテニスの壁打ちをしている」心境で辛い気持ちになりましたが、当時の開発本部長の言葉がとても励みになったことを今でも思い出します。それは「今任せているのは、システム開発の中でもとても難しい部分です。今は“ひとりでテニスの壁打ち”かもしれない。でもそれを極めれば将来大きな舞台にたったとき、その試合はとても楽に感じるはずですよ」という内容でした。開発部長のアドバイスから得たことは「まず他の人にはない武器を持つ」と「時間を投入してその武器を研き続ける」という2つだと認識していました。その数年後、私はあるきっかけでエンジニアから人事へキャリアチェンジし、某大手ネット事業会社の人事企画として転職をすることになりますが、その開発本部長のことばに励まされてキャリアを積んできたような気がします。

なぜアスタミューゼに人事として入社したのか

某大手ネット事業会社で経験を積み、その後もネット系企業を中心に人事責任者を数社経験する中で、様々な尊敬できる経営者のもとで多くを学ぶことができました。その中で、改めて人事という仕事の難しさを感じました。時に社員の皆様の人生を左右することもあり、また事業拡大に向けて経営の視点からものごとを考え、全体の意識をまとめながら会社という船を目指す方向に強く動かすことが求められます。私の武器は、人事領域を軸に置きながらも、事業拡大や組織運営に関することであれば「どんなことでもやりきる」というスタンスを持ち、過去に在籍した会社で実際にそれを有言実行させてきたことだと思っています。 ただ、言うのは簡単でも行うのは本当に難しいものです。単独でやるのではなく、数千名の企業の全部門を横断して業務を推進するためには、それぞれ部門側としての立場がある各関係者の信頼を得ながら進めなくてはなりません。そのためには、日々社員の皆様とのほんの小さなやりとり・会話・メールや、日々の自分自身を含めた人事チームの立ちふるまいなども全てを大切にしていく配慮・心配りなどが重要だと認識しています。

これまで人事を中心に学んだ経験を生かせる場として、私はアスタミューゼに入社することを選び、入社して約5ヶ月が立ちました。私が入社する会社を選ぶ最も重要だと考える点として、その会社が人事の大切さを理解しているかがあります。これまで在籍していた企業の経営者は人事戦略を経営戦略と非常に近い熱量で考えており、求められる水準は高かったものの、成果として組織のパフォーマンスが大きく発揮されたり、業績に大きな影響を与えたりすることが味わえるのが非常に魅力的でした。人事に求められることが大きいと、会社・組織をつくっていく非常にダイナミックな楽しさを味わえます。

アスタミューゼは、(私が入社しようか考えていたときに)今後 人事戦略を経営戦略に近い熱量で考えたいと思う経営者がいて、かつ事業内容が非常に楽しそうであり、今後大きく事業が伸びていきそうだという点に強く魅力を感じました。よくメディアで紹介されているような今どきのスタートアップ企業とは異なり、あまり外部への露出は少ないものの社会貢献度が極めて高く、技術的にも非常にレベルの高い新規事業創出コンサルティングや、専門領域の人材サービスなど非常に面白い取り組みをしている点も魅力に感じました。少しおこがましいかもしれませんが、この会社に入社して人事として組織を強く、頑丈なものにして社員の皆様と長期的に楽しく仕事ができたらとても幸せだな、とシンプルに感じました。

私が人事として入社後、社員で13名、派遣社員で3名の方が入社してくださっています。 現在60名程度の組織から、採用活動も強力推進しています。エンジニアの皆様の応募もお待ちしております!

f:id:astamuse:20181003113751j:plain

少しかための文章となってしまいましたが、以降は少しやわらかめに最近の社内でのできごとをご紹介したいと思います。

創立記念イベント

アスタミューゼは2005年9月2日に設立し、2018年9月で13周年を迎えました。 これもひとえに支えてくださった、すべての関係者の皆さまに感謝申し上げます。

弊社では、例年9月初旬に創立記念イベントを実施しており、午後から夕方までの「PART1」はイベント、夕方から夜までの「PART2」では社外会場でパーティー、が基本的な流れとなります。このイベントについて本年度は 人事総務部内で私(ISHIWA)と、女性メンバーのKAWASUさんの計2名で準備から当日の運用まで行いました。

ちなみに、当初は創立記念イベントの準備・運用は人事総務部で行う予定ではありませんでした。 しかし、次のような流れからイベントを担当する準備が整いました。

ある会議で代表 永井より「今後 社内でイベントを行う際は、部門ごとにで分かれて行うのではなくISHWAさんの方で全社をとりまとめていただけないでしょうか(丁寧)」というお話がぽつりと出た後、まず7月に行われた社内バーベキューイベントの推進を担当することになりました。更に後日、別の会議で「ISHWAさんの方で創立記念イベントもよろしいのでしょうか(丁寧)」というお話がでました。 「よろしいのでしょうか」と丁寧かつとてもざっくりとしたご相談をいただき、「よろしくはないです・・」という回答は実装することができず、ここは深く考えずに「もちろんです。むしろ大丈夫です。」という強い意志表示をしつつ、前に進むことを選びました。”もちろん・むしろ”という言葉が大事です。

もちろん、自席に戻り人事内でそのことを共有すると、KAWASUさんからの「なぜ軽く引き受けてきたのか?」といった冷たい視線のデプロイが完了していましたが、むしろここも考えずに前に進むしかありません。

現在 人事では採用活動の強力推進に加え、評価制度のリニューアルや組織強化など全方位でさまざまな取組をしていることから、当日の準備に必要な作業時間の確保が厳しい状況でした。前日夕方に、当日のイベント司会で使用するパワーポイント資料を1日で作りあげるという、予定通りの順調な流れとなりましたが、なんとか準備を全て完了させて当日を迎えることになりました。どんなに不思議なことが発生しても、前に進むことへの徹底がよかったのだと思います。

そして創立記念イベント当日。 前半「PART1」では、社内で全社員参加のワークショップを行います。議題は次の内容です。

■下記が実現するための施策を考えてください

  • 社内が活性化する
  • 仕事がもっと楽しくなる
  • プロアクティブに仕事に取り組む

「A・B・C・D・E・F・G・H」の8チームに分かれ、それぞれチームごとに会議室・社内のワークスペースで議論します。考えをまとめ、各チーム代表が全社員に向けて7分間のプレゼンテーションを行います。(役員、人事 ISHWAはチームには参加しません)

プレゼン内容について、全社員が投票・役員審査を経て1位・2位・3位を決定します(入賞チームには実行する予算がつきます)。予算がつくということは、実行できない机上の空論ではなく、「具体的な実行を見据えた提案を行う」覚悟が大事になります。私も覚悟はできています。

結果、下記を提案したEチームの優勝となりました(直近で人事と連携して具体的に推進・実行します)

■Eチームの提案内容: みんなで創る福利厚生:みん福

  • 社員一同から家族に誕生日の贈り物
  • 気軽に社内で頼れる仕組み「困りごとクラウドファンディング」

後半「PART2」のパーティー会場では、次のようなコーナーがあり、改めて全社が一体となって楽しむことができた創立記念イベントとなりました。

  • ワークショップで入賞したチームの表彰式
  • ビンゴ大会(ダイソン機器など、豪華賞品あり)
  • 長期勤務社員への祝福(花束等)
  • 今後に向けた各種発表

人事評価制度のリニューアル

創立記念イベントの翌営業日、社外会場にて全社員に向けて新しい人事評価制度および部門目標設定についての説明・案内を行いました。新しい制度は、今後の事業拡大と人員増加に備え全社一丸となった強い組織をつくるための基盤となるものです。

これまで支えてくれた社員、今後新しく仲間に加わってくれる社員、それぞれの多様な価値観を大切にしながらも、目指すべき同じ景色を見ながら全社が一体となり、会社が新しいステージに進む流れを強力に推進してくれる仕組み、そんな制度を目指しました。制度の目指す目標・特徴を下記に示します。

■目標

  • 組織の風土改革、個人が成果を出すノウハウの蓄積
  • 全社員が共感できるアスタミューゼらしさ(企業文化)を作る

■特徴

  • 成果に対する達成度を評価する指標として、「OKR」を導入
  • 個人の自律とチーム内での信頼関係構築・相乗効果発揮を狙う「業務姿勢(ビヘイビア)」の評価項目導入
  • アスタミューゼらしさを浸透させる「行動指針」の評価項目導入

(業務姿勢・行動指針の評価は、発揮能力を評価)

評価制度は作成して終わりではなく、運用が最も大切な要素となります。人事評価制度が組織をより強く変革し、 業務姿勢や行動指針などが深く浸透されることを目指し、人事からも強く推進していきたいと思います。

最後に

いかがでしたでしょうか。最近のアスタミューゼでは、事業の拡大に備えて組織・人事に関する取り組みを強化しております。アスタミューゼで働く皆様が、ご自身の強みを生かして一人ひとりが輝くことができる、全社一体となり、そこで働くことに強く魅力を感じる組織文化をつくる、そのようなゴールを目指して引き続き取り組んでいきたいと思います。

DBTS (db tech showcase) 2018 TOKYO 参加レポート データエンジニアの外部セミナー参加日記

こんにちは!

DB大好きなPKと申します。データエンジニアをやっております。

f:id:astamuse:20180925170046p:plain

弊社の優秀なエンジニア達は新しい技術に常にアンテナを張るべく、最新の技術情報収集手段として外部セミナーに積極的に参加してしております。

外部セミナーに参加する目的は情報収集手段と気持ちのリフレッシュ、新しい技術を触って見ようと思うきっかけになったり、他社の事例を通して自分達のアーキテクチャ設計時に参考したり、メリットはたくさんあると思います。

主に参加してるイベントはデブサミ、JJUG、GCP NEXT、Java day tokyo、DB tech showcase、cloudera world Tokyo、Scala Matsuri 、DataWorks Summit などがございます。

今回私は先週9/19~9/21まで秋葉原UDXでインサイトテクノロジー社主催のdb tech show case Tokyo 2018 #dbts2018に初日と二日目参加してきましたので、そのレポートを記事にさせていただきます。

9/19,9/20はgcp nextも開催されてましたので、弊社のエンジニアは2部隊と別れての参加となりました。

dbtsですが、私としては今年で4年連続参加となりますが、毎回RDBをはじめ、NoSQL、Hadoop eco system 、グラフデータベース、時系列データベース、ハードウェア、クラウド環境関連などなどさまざまな話を聞けて大変ありがたいイベントだと思っております。

さて、現場へGo!

Day1

秋葉原UDX 6FのConferenceスペース行くと受付で名刺2枚渡して3日間通して使えるパスを取得できます。

そして初日の午前中しか聞けないキーノートのセッションへ

キーノート

セゾン情報システムズCTOの小野さんから大変面白い且つ現実味のある話を聞いて、元SI業界で数年間働いた身として頷ける話ばかりでした。
最初から最後まで面白い話と真剣な話をバランスよく交えながらスピーチされて1時間ちょいという長いセッションにも関わらず、最後まで集中して聞けました。
さすが、キーノート!クォリティーが高いです。

お話の概要としてはセゾン情報システムズで行なわれたエンジニアとしての働き方を革新した内容がメインでした。

途中で入って最初は聞けなかったのですが、エンジニアとして印象に残った部分としては
・ 美しいコードとか、新しい技術とかチャレンジしたいけど、予算とかの兼ね合いで中々難しい ・ でも最終的にはそうしたほうが技術的な負債もすくなくて助かる
・ ソースコード管理はGit導入し、デイリーコミットを実現
(中には作りこみ途中のコードをコミットして他人に見られるのを恥ずかしがるエンジニアもいるがそんな必要はない、女優とプログラマーは見られてキレイになる!?(名言ですね)
・抱え込まないことが大事、何かあればすぐにヘルプを出す
・脆弱性、セキュリティ問題も早い段階で見つけられる
・コミュニケーションはSlack導入、全社的に普及してきてる
・モダン開発推進→ひとりではなくチームワークで作っていこう、ペアプログラミングなど
・現場で大事なHRTの原則
 Humility
 Respect
 Trust

などなど、貴重なお話が盛り沢山でありがたいセッションでしたー!

そして、次はインサイトテクノロジー社の新社長の挨拶、過去の振り返りと抱負と今後の展望についてのお話でした。 Allen Miner社長の日本語がとても上手でビックリしましたー!

そしてキーノート完了したら11時45分からお昼の時間に。
午後のセッションどれにすべきか悩みながらお昼は大好きな中華料理♡

午後1は弊社で色んなサービスで使われてるElasticsearchのセッションへ(SQLモード気になる

ElasticsearchのSQLのお話

聞き取れた概要だけピックアップすると

  • beatsファミリー良さそう

    • Filebeats
      • log 収集、可視化が簡単にできる(Apache, Nginxなどから
    • Metricbeats
      • パフォーマンス情報収集ツール (Postgreのポートとip指定するだけでスロークエリの解析とかできるらしい
  • SQLの話 (ver 6.3以降から使える)

    • ElasticsearchのDSL辛いよね、大体みんなここで挫折してしまう(私も。。
    • だからSQLのtranslate api提供した
    • ただし、Read onlyだけ、desc、select など
    • where句に書ける検索条件は複雑なものはまだサポートしてない
    • やり方は一つは上ののtranslate apiにsqlを投げる方法とCLIから直接書く方法
    • JDBCドライバーを使ってアプリからSQL投げる方法もある
    • kibanaからsampleデータを登録してくれる機能もできたらしく、入門しやすくした感じがする

Impalaパフォーマンスチューニングの話

  • SQLの見直しより、アーキテクチャーの見直し
  • ただし、バージョンは最新がおススメ
  • メトリクス情報をちゃんと取ることが重要
    • cpu,memory,disk ioなど
    • disk ioのチューニングについて
      • ストレージ層の最適化
      • parquetフォーマットが良いけど、ケースバイケースで
      • partition設計もしっかりやるべき
      • 適切な期間で区切って読み込む量を減らす

といった内容でした、結構チューニングにおいて定番の話でもう一度勉強させていただきました。

。。と初日のレポートは以上になりますが、上記以外も面白いセッションが盛り沢山な一日でした。

Day2

二日目のレポートです。

以下、個人的に印象に残ったセッションをピックアップします。

hdfsの新機能のお話

Hadoop 2.9、3.x で実装される予定のhdfsの新しい機能のお話でした。

  • 従来のNameNode federationはNameNodeの負荷分散の為複数NameNodeをViewFSにマウントポイント記載して一つに見えるようにしてた。
  • でもViewFSのマウント情報クライアントが管理するので、複数クライアントだと難あり、そこに登場したのがRouter based federation機能。
  • RouterはWebHDFSも提供してる。

なんとなくキーワード覚えてあとで詳細勉強しておきたいと思いました。

詳細勉強しておかないとhadoop 3.xはついていけなさそうですね

これ以外もNameNodeのHA構成の問題点とそのアプローチ、Heterogeneous Storage policyの話、Erasure Coding(DataNodeのストレージ使用量がレプリケーションと比べて半分になる)などなど面白いお話をたくさん聞きました。

ロコンド社のMySQLのバージョンアップのお話

  • バックエンドのDBはMySQL使ってるがもともと5.6使ってた
  • CM効果でアクセス数が急激に増えてきて安定性と高可用性を保つためInno db cluster使いたい
  • そのために5.7にバージョンアップする必要がある

  • エンジニアが少人数なので、DB障害も自動回復が望ましい、スケールアウトのしやすさなどの理由もある

実務レベルのコマンドとかノウハウとかたくさんあってすごくありがたいセッションでした。

Postgresqlとgpu最新機能を利用してTB級のデータを扱うお話

  • pg-stromというPostgresqlのextensionを使えばSSD → GPU間でNVIDIAのGPU Direct という技術を使って
     CPU介さずデータのやり取りができるお話、大量のデータを統計分析するときに使える。
  • ターゲットとなるデータボリュームはTB級、SQLとRDBそのまま使ってTB級のデータを扱えるのは大きなメリットがある。

詳細はスピーカーの海外さんのブログにも書いてありました。
すごく勉強になるし、面白いセッションでした。

最後に

2日間の参加を終えてた感想としては毎回のことですが、セッションのバリュエーションが豊富なのと
セッションの登録が事前に必要ないので、気になってたセッションに参加できてとても充実した二日間でした。
セッション選びに関しては基本的に実務に関連あるものを優先して、あとは個人的に面白そうだと思ってるセッションを聞いております。
そして、ほかのエンジニアもそうですが、毎回自分が面白いと思った技術とかは触ってみて社内の勉強会で共有したりして
セミナー参加の良いサイクルを作ることに努力しております。

最後にいつものことですが、弊社はエンジニア・デザイナー絶賛募集中ですので、興味ある方は下のリンクよりご応募くださいー!

MongoDB 4.0 探検日記

f:id:astamuse:20180918174726j:plain

MongoDBと過ごした8年を振り返りながら、お気に入りのMongoDBマグカップで濃いめのモカを啜っています。

たのしくテンポの良い開発、フラグメンテーションとの長い夜、主語の大きいロック、星の数ほどのMongoDBステッカー、高嶺の花のMongoDB公式Tシャツなどが走馬燈のように目の裏を駆け巡ります。

今年6月、ついに昨年10月のNasdaq上場後初のメジャーバージョンアップであるMongoDB 4.0がリリースされました。

この成長著しいMongoDBにキャッチアップすべく、私fdkはMongoDB 4.0の探検に出かけました。*1

MongoDBについて

MongoDBは2007年より10gen(現MongoDB Inc.)により開発され、2009年の初版リリース以来、継続的にリリースを重ねているドキュメント指向データベースです。階層構造を表現できるドキュメントと呼ばれるデータ構造を、BSONという表向きはJSONによく似たバイナリ形式で格納します。高速なオペレーション、スキーマレス、透過的圧縮のサポート、レプリカセットによる冗長性とスケーラビリティなどが強みとして挙げられます。

一方で、これまでトランザクション機能がない点がアキレスの踵と囁かれていましたが、MongoDB 4.0の登場により、そのような通説は風と共に消え去ろうとしています。

MongoDB 4.0の主な新機能

1. Multi-document ACID transactions

これまでMongoDBでは、ドキュメント単位のアトミックな更新は実現されており、実用上多くの利用ケースでは十分とされていました。MongoDB 4.0では、複数ドキュメントにまたがるトランザクションが実装され、課金、予約、口座間の資金移動などの、トランザクションが求められる領域にも対応できるようになりました。

MongoDB 4.0ではRDB同様にトランザクションの制御をデータベース側でサポートしてくれるので、アプリケーション側での実装コストが削減できます。

トランザクションは複数ステートメントで記述するようになっており、そのためのAPIが用意されています。*2

以下、MongoDB 4.0のトランザクションについてのメモです。

  • 単一もしくは複数のコレクションやデータベースに含まれるドキュメントに対して適用される
  • Snapshot isolationにより、各トランザクションはデータの一貫性ビューを提供し、データの整合性を維持するall-or-nothing実行を強制する*3
  • 実行中のトランザクション内では、自身の未コミットの書き込みは参照できるが、トランザクション外の操作からは一切見えない
  • 未コミットの書き込みはトランザクションがコミットされるまでセカンダリのノードにレプリケーションされず、トランザクションがコミットされると自動的に全てのセカンダリセカンダリに複製され適用される
  • 長いトランザクションや膨大な操作を伴う単一のトランザクションはストレージエンジンであるWiredTigerのキャッシュを圧迫する(スナップショット以降の全ての書き込みの状態を維持しなければならないため)
  • デフォルトでは60秒を超えるとトランザクションは自動的にabortされる
  • トランザクション内で読むことのできるドキュメント数の上限は無いが、1トランザクション内での更新は1000ドキュメント以内であることが推奨される
  • トランザクションは単一のoplogエントリとして記録されるため、16MBのサイズ制限を受け(更新の場合は差分のみ、新規の場合はドキュメント全体がカウント対象となる)、これを超えた場合トランザクションはabortされ、rollbackされる
  • トランザクションがabortされるとドライバに例外が返され完全にrollbackされるが、ネットワーク障害やプライマリ選出中などの一時的な障害を想定し、アプリケーション側で適宜リトライなどの実装をするべきである
  • コミット操作時にエラーが発生した場合、ドライバは1度だけリトライする
  • トランザクションを使用しない場合のオーバーヘッドは全く無い

トランザクション機能が追加されたことで、将来的にトランザクション制御が必要になるかもしれないというケースにもMongoDBは有効な選択肢となりそうです。

2. Aggregation Pipeline Type Conversions

MongoDBはスキーマフリーのため*4、データ構造について柔軟です。それゆえに、収集したデータをBIや機械学習で活用する際に、同一のエレメントで複数の異なる型のデータが存在しているケースがありえます。

そのようなケースで、集計パイプラインにおける型変換を、別途外部のETLプロセスを介することなくデータベース内で行う機能です。*5

具体的には$convertという演算子を使い、型の変換ルールを指定します。

{
   $convert:
      {
         input: <expression>,
         to: <type expression>,
         onError: <expression>,  // Optional
         onNull: <expression>    // Optional
      }
}

この機能を活用すると、データ分析において別途のETL処理を省くことができるため、複雑性やコストの低減が期待できます。

3. The aggregation pipeline builder

MongoDB CompassというGUIツールにより、MongoDB内のデータの構造の可視化、アドホックのクエリ実行、インデックスの作成、バリデーション規則の作成といったことができます。このツールで集計のパイプラインの構築を試行錯誤しながら行えるようになりました。

f:id:astamuse:20180918174824p:plain

画面は、サンプルデータ*6 で前述の型変換を試しつつパイプラインを構築してみた様子。作成したパイプラインを名前付けして保存できます。

コード吐き出し機能があり、作成したパイプラインのコードを出力できます。現時点でPython3, Node, Java, C#の4言語に対応しています。

直感的で使いやすく、データの観察、データ分析、アプリケーション開発の助けとなるツールではないかと思います。

4. MongoDB Charts (β版)

MongoDB Chartsは、MongoDB専用のBIツールです。Docker Swarm上のコンテナで動作します。 Redashなど他のツールと同様にデータソースに接続し、データの美しい可視化、ダッシュボードの作成、共有ができます。

f:id:astamuse:20180918174906p:plain

画面はローカルで起動したMongoDB Chartsで作成したダッシュボード。MongoDB Atlas上に作成したレプリカセットに接続し、テスト用に作成したサンプルデータでチャートを作成してみました。beta版のためチャート作成の細かい部分はまだこれからという印象です。

5. Non-Blocking Secondary Reads

MongoDB 4.0ではセカンダリからの読み出しとレプリケーションの書き込みが同時に実行できるようになりました。

MongoDBでは、プライマリで発生した書き込みはセカンダリに対してバッチ適用するようになっています。

よく言われるようにMongoDBは結果整合では無く、実際には一連の書き込みは各ノードで同じ順序で見えるように制御されます。

4.0より前のバージョンでは、順序を維持するため、セカンダリに対する読み出し要求はブロックされていました。つまり、oplogが適用されるのを待たされるケースが発生しており、書き込み負荷が大きいほど停止時間は長く、セカンダリからの読み出しレイテンシのメトリクスに悪影響を与えていました。

加えて、書き込み側は全ての読み出しの完了を待つロックを必要とし、セカンダリへの読み出し要求が多い時に、書き込みが遅延する原因となっていました。

MongoDB 4.0では、一貫性のあるスナップショットから読むことにより、セカンダリへの読み出し要求はoplogの適用中にブロックされず、またプライマリへのwrite concernがmajorityの書込みはロックの緩和により速く承認されるため、読み出の遅延とセカンダリの遅延を減らすと同時にレプリカセット全体のスループットが最大化されるとのことです。*7

6. SHA-2 Authentication

MongoDB 4.0では、認証メカニズムの強化として、SCRAM SHA-256が追加され、MONGODB-CRは廃止になりました。 MONGODB-CRスキーマでの認証を行なっている場合は、MongoDB 4.0へのアップグレードに先立ってSCRAM-SHA-1にアップグレードする必要があります。

企業のセキュリティポリシーにより、既に脆弱性の見つかっているSHA-1を使わないようにする必要がある場合、SCRAM SHA-1からSCRAM-SHA256へのアップデートが選択肢となります。 *8

7. The improved shard balancer

MongoDB 4.0では、シャード・バランサーの性能が、同時実行により最大40%向上し、より時機を得たスケールができるようになったとのことです。
*9

アップグレードについて

3.6系にアップグレードしてから4.0にアップグレードする必要があります。

これまで同様に、ローリングアップグレードができます。

SCRAM-SHA-256などいくつかの新機能を有効にするためにはfeatureCompatibilityVersionを4.0に変更する必要があります。 当然ですが、テスト環境での事前の検証が推奨されます。

まとめ

MongoDB 4.0の新機能を駆け足で見てきました。木を見て森を見るようにMongoDBの深淵を垣間見ることができました。

トランザクションの実装により守備範囲を広げ、データ分析や機械学習向けデータ処理パイプラインのサポート、BIツールの提供、そしてクラウド、モバイルを含むあらゆる場所での実行をサポートするというホリスティックでダイナミックな舵切りに期待が高まりました。

これからもMongoDBと歩み続けよう、と気持ちを新たにした一日でした。

Copyright © astamuse company, ltd. all rights reserved.