Google Compute Engine のディスク(SSD)ベンチマークを取ってみた

こんにちは。並河(@namikawa)です。

すっかり春の陽気ですね。花見の春。スギ花粉の春。ラーメンの春。ちょっと複雑な気分です。

さて、以前に以下のブログエントリでも紹介したのですが、弊社のサービスは、今をときめく Google Cloud Platform 上で動かしているものが多くなってきました (移行中)。

lab.astamuse.co.jp

で、その中でも Google Compute Engine (以下、GCE) がメインといった使い方にはなっているのですが、以下の点が気になったので、ディスク(SSD)ベンチマークを取得してみました。

• 容量によってランダムIOPSやスループットの上限が決まっているが、シーケンシャルアクセスはどうか
• ディスクを複数本束ねていくと、実際のとことろ上限は変化するのか
  
  

ということで、実際にやってみましたよ、と。

前提

使用した環境は以下の通りです。

• インスタンス構成
  • n1-highcpu-32 (32core, 28.8GB)
  • SSD (persistent disks, 1000GB) x2
  • Local SSD (NVMe, 375GB) x2
• OS
  • Ubuntu 16.04.2 LTS
  • Linux version 4.8.0-46-generic (buildd@lcy01-15) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) )
• I/Oスケジューラ
  • noop
• ファイルシステム
  • XFS
• ベンチマークツール
  • fio (2.2.10)

尚、ベンチマークは下記のようなスクリプトを組んで実行しました。

fioで実行する内容としては、上記のスクリプト通りではありますが、要約すると以下のような感じで指定しました。

• シーケンシャルアクセス(R/W)とランダムアクセス(R/W)の4パターン
• ブロックサイズは4k
• 同時実行ジョブ数は、1～256
• スループット(帯域)を測る際は、ブロックサイズ32mでシーケンシャルアクセスのみ

また、デバイスを2本束ねる際は、ソフトウェアRAIDを利用しているのでそのパラメータとか、XFSまわりのパラメータは以下のような感じです。

# mdadm --create /dev/md0 --chunk=256 --level=0 --raid-devices=2 /dev/sdb1 /dev/sdc1
# mkfs.xfs -f -b size=4096 -i size=512 -l size=64m /dev/md0
# mount -t xfs -o noatime,logbufs=8 /dev/md0 /data

GCE SSD関連の性能仕様

ベンチマーク結果の前に、GCEのドキュメントではスペックが公開されていますので、確認しておきましょう。

最新情報・詳細はこちらをご覧ください。

現時点(2017/04)の数字で要点だけまとめておくと

• SSD(persistent disks)では、1GBあたり30IOPS(ランダムアクセス)の性能が出る
  • 例えば、100GBのSSDボリュームでは3000IOPS、500GBのSSDボリュームだと15000IOPSという具合
• ただしSSDのIOPSは、以下の条件で上限が設けられている
  • 15コア以下のインスタンスでは Read/Write で 15000IOPS / 15000IOPS まで
  • 16コアから31コアまでのインスタンスでは Read/Write で 25000IOPS / 25000IOPS まで
  • 32コア以上のインスタンスでは Read/Write で 40000IOPS / 30000IOPS まで
• Local SSD(NVMe)は1本あたり、 Read/Write で 170000IOPS / 90000IOPS の性能
  • ただし1インスタンスあたりでは、 Read/Write で 680000IOPS / 360000IOPS まで

そんなところで実際の数値を確認するべくベンチマークを取得してみました。

SSD (1000GB) x1

このベンチマークでは、1000GBのSSD(persistent disks)を割り当てたものを使っているので、このグラフ通り、公称値通りの結果となりました。

シーケンシャル・ランダムアクセスのRead/Writeともに、30000IOPS超で綺麗にキャップされています。

スループットに関しても、Readが480MB/s超、Writeが400MB/s超と、こちらも公称値通りの結果です。

SSD (1000GB) x2

次に、1000GBのSSD(persistent disks)を2本、RAID0(ソフトウェア)で束ねて計測してみました。

こちらは、シーケンシャル・ランダムアクセスのReadが40000IOPS超、Writeが30000IOPS超のところでキャップされました。

上記のGCEの仕様で記載した「32コア以上のインスタンスでは(Read/Write)で 40000IOPS / 30000IOPS まで」というインスタンス単位での上限ですね。

尚、32コアインスタンスのスループット上限に関しては Read/Write が 800MB/s / 400MB/s になっているのですが、Readが約490MB/s程度の結果でした。

これは、60秒間通信を続けて平均をとっているのですが、最初の30秒程度は800MB/s近く出ているのですが、そのあと不安定な波形となっていて、時間的に不調だったのかもしれません。余裕があれば、後日追試してみたいと思います。

Local SSD (NVMe, 375GB) x1

ついでに Local SSD (NVMe) も計測してみました。

ランダムリードは公称値の170000IOPS超、ランダムライトは83000IOPS超でした。

シーケンシャルアクセスも、ランダムアクセスとほぼ同じ伸びをしていますが、同時実行ジョブ数が増えてくると若干ながら伸び悩む傾向です。ただし32コアのインスタンスで計測したものなので、大きなジョブ数での数値は参考値程度、です。

Local SSD (NVMe, 375GB) x2

次に、Local SSD (NVMe) を2本、RAID0(ソフトウェア)で束ねて計測してみました。

ランダムリードは、2本束ねた通りの綺麗な伸びをしています。シーケンシャルリードはそれに及ばないもののきっちり伸びていますね。

ライトに関しては、シーケンシャル・ランダムアクセスの双方とも82000IOPS超あたりから伸びていませんでした。

先ほどの Local SSD 1本の時も同じ話が言えるのかもしれませんが、今回のベンチマークのようなマルチスレッドではなく非同期I/Oを使用したベンチマークでは、きちんとした数字がのってくるのかもしれません。

おわりに

今回は、GCEのインスタンスに、SSD (persistent disks) と Local SSD (NVMe) それぞれで、ベンチマークを取得してみました。

結果としては、概ね公式ドキュメントに記載してある公称値通りの結果となっています。その他は各々のケースで考察として記載した通りです。

仕様的には、SSDボリューム単位での性能上限とインスタンス単位での性能上限が別々であるので、そこだけ注意しておけば問題ないかと思います。

尚、前述の通りですが、Local SSDのような高速なIOPSが実現できるケースでは、(その上で動かすミドルウェアのI/O方式を確認の上で)マルチスレッドな実行だけではなく、非同期I/Oでの計測も確認した方が良いとは思います。

このベンチマーク結果が何かの参考になれば幸いです。

最後にお約束ですが、そんなGCPを使って自社サービス開発・運用であったり、大量のデータ基盤をなんとかしてくれるエンジニアを絶賛募集しておりますので、是非下部のバナーから（ry

今日はここまで。それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

初めての転職で感じたアスタミューゼのいいところ

「こんにちは、僕の名前はネコタンク！毎週、みんなのデスクを転々としてブログを書くよう耳元で囁くよ！」

こんにちは、１月に入社したnishikawaです。私のところに 　死神　 もといブログの番人であるネコタンクさんがデスクにやってまいりました。先週の水曜から本日まで耳元で「ブログ書け〜、ブログ書け〜」と精神に囁きかけてきております。

そのおかげで毎晩ネコタンクさんが下の画像のような感じで私の夢に出てくる始末。シュールな顔をして侮れないネコ？です。

さて、今回初めてブログを書くにあたり何を書こうか色々と悩みましたが、どんなに悩んでも天から文章は降りて来ず。結局、部長からいただいた「アスタミューゼに入社して働き方がどう変わったのか」というアイディアを基に身を絞ってブログを執筆することにしました。「職場で何かに行き詰まっている」「転職を考えている」という方の参考にしていただければ光栄です。

まずは忙しい人のためにアスタミューゼで３ヶ月働いてみてよかったところ、新鮮だったところをまとめてみます。

・ 会社の人と技術の話題で盛り上がれる（前の会社では絶対になかった）
・ 提案次第で技術的に新しいものを積極的に取り入れてくれる
・ 週１回勉強会がある
・ 勤務時間がフレックス制で働きやすい
・ 設計から運用までシステムを一貫して見ることができる
・ 営業、マーケティングの方と打ち合わせをする機会があり、自分の仕事が売り上げに繋がっていることを実感できる
・ 誕生日休暇という休みがある（とっても新鮮）
・ 職場全体や上司が家庭や子育てに関して理解を示してくれる
・ 出社して周りに人がいる（１人じゃないって素晴らしい）

こんなところではないでしょうか。こう見ると前の職場大丈夫か？と思われるかも知れないですが、私にとっては大丈夫じゃないので転職した訳で、これらのインプットを元にどんな環境だったのかというのを推測してみるものいい時間つぶしになるのではないでしょうか。（精神を蝕まれないよう注意が必要です責任は取りません）

では、私がアスタミューゼに入ることになった経緯などを以下に記載します。お時間のある方だけどうぞ。

１人で仕事をしていた前職時代

私は大学を卒業し５年間グループ企業の中の小さい会社で働いておりましたが、年次を重ねていくうちに以下のことが辛くなってきました。

・ 設計から運用までシステムを一貫して見ることができない。
・ やったことのない技術をいきなりやらされる。
・ 客先に１人で常駐させられているため、誰にも相談できず１人でなんでも解決しなければならない。
・ 仕事のコントロールが全くできない

そのため、帰りも遅い上に帰宅後は技術的な課題克服のため調べ物を朝までやり翌日の業務に備えるという状況が入社してから続きました。

転職を考え始めたきっかけは体調不良！

そんな環境で働き続けていたある日、職場での打ち合わせ中に急激に胸の痛みに襲われその場で倒れました。あの時のことはまだはっきり覚えていますが、多分あれは心臓が軽く止まっていたのだと思います。すぐに動いてくれたようですが心拍数が上昇したまま治らず、全身が痺れて動けなくなったため救急車で病院に運んでもらいました。

会社は辞めようと思ったのはその時です。

転職を考えるも、いきなり躓く！

まず、最初にやったことは転職サイトへの登録と自分の分析でした。私は学生時代の就職活動中に有名な某就活サイトに登録しておりましたので、とりあえずそこの転職サイトに登録を行いました。ここまでは順調だったのですが、自分の分析を行ったら一気に手詰まりになりました。

そうです！私には目立った経歴もスキルも無かったのです。

当時は勤続３年目で経験がなさ過ぎたためアピールポイントが無かったのです。社会人なので「部活やってました！」「会社で真面目に仕事してました！」なんて言いながら就職活動をする訳にはいきません。具体的にどんなことをやってきて、どんなことができるのかを言えないといけないのです！（ネットの情報曰く）

なので会社を辞めたい気持ちを一時的に抑えてアピールできるポイントを作ることに専念しました。具体的には

・ 獲得したいスキルセットを明確にする
・ スキルセットで足りない部分の洗い出しを行う
・ 足りない部分は独学で勉強し、できるだけ業務で使用する

そして月日が流れついにその時がやってきました。

ついに転職をすることに！

それは去年の夏のこと。休みの朝に妻がパソコンを私の前にドンッ！と置きました。

私：「ん？どうかした？」

妻：「今日は仕事の調べ物をしないでずっとリビングにいてもらいます。」

私：「今日って何かあったっけ？」

妻：「いい加減今の会社を辞めて欲しいから今ここで転職サイトに登録してエージェントに連絡してください！終わるまではご飯抜きです！」

私：「えっ！ご飯抜きは流石に勘弁してください！すぐに登録します！」

と、こんなやり取りの後エージェントに後日会う約束をして 　ご飯抜きを免れました　 転職活動をすることになりました。

面接を受けてみると色んな企業から想像もしなかったことを聞かれる

転職活動をし始めて一番最初に驚いたのがどの会社に面接に行っても「なぜ今転職を考えたのですか？」という質問をされることでした。私は当時３０歳になるかどうかのタイミングだったのですが、初めて転職をする年齢としては少し遅いんじゃないかと色々な企業で言われたのです。

正直これには驚きましたが、確かに私の経験にはマネージャ経験等がないのでそう言われるのも仕方なかったのかも知れません。倒れたあの時に即行動を起こしておけばと面接を受けながら後悔もしました。

転職の文字が少しでも頭をよぎった方、古人は遥か昔から言っておりました「思い立ったが吉日」と。

内定を２社いただき、迷った末アスタミューゼへ

面接を受けて凄く落ち込むことも多かったですが、妻から飯抜きの脅迫を受けているので逃げ出す訳にはいきません。頑張って色んな会社を２〜３ヶ月回った結果、ありがたくも内定を２社いただきました。そのうちの一つがアスタミューゼでした。

しかし、すごく興味があり仕事をしてみたいという気持ちこそあれど、当時の私はアスタミューゼへの入社をかなり悩んでいました。

私はもともとScalaがやりたくてアスタミューゼに応募したのですが、Scalaの実務経験はなくほぼ独学でやっている状況だったため、入社しても会社の役に立てない可能性が高いと思っていたのです。また、面接時に浴びた「私たちスペシャリスト集団です！」的なすごいオーラに極度に怯えていたということもありました。こんな状態で入っても３日でクビになって路頭に迷う そう思ったからこそ激しく葛藤しました。

そんな私に、手を差し伸べてくれたのは先週ブログの当番だった私の今の上司で、メールで励ましのお言葉をいただのでとても勇気が出たのを覚えてます。そして最後の後押しはやっぱり妻で、「路頭に迷ったらその時考えよう！」と言ってくれたのでアスタミューゼへの入社を決めました。

と、ここまでがアスタミューゼに転職するまでの経緯です。転職理由や行動に移すまでの動機は人それぞれですが、私の場合はこう見ると妻にほとんど突き動かされていました。しかし、自分のやりたいことなどについては妥協せずに転職ができたので今はとても満足しております。

アスタミューゼは前職と比べてどうか

これは冒頭にまとめましたので そちらをご覧ください。

強いて言えば、もう最初に書いてありますが職場や上司が家庭や子育てについてとても理解があるので、相談しやすいですし建設的な話し合いができるところが大きいと思います。私はアスタミューゼ以外だと前職しか組織を知らないのですが、そこや友人の所属している企業の話を総じても、ここまでプライベートの相談がしやすい会社はないと思っております。

また、開発部にいる技術者はみんな凄い人ばかりですが、分からないことは質問するとみんな優しく教えてくれます。これも前職ではなかった経験で場所が変わればこんなに働く環境や仕事のやりやすさというのは変わるものなのかと常に驚きに満ちています。

最後に

今回はアスタミューゼへ入社して３ヶ月間で私が感じたところを書かせていただきました。

技術者にとってはとても働きやすい場所だと思っております。もし、弊社にご興味がありましたら採用ページをご覧いただければ幸いです。

recruit.astamuse.co.jp

また、現状の労働環境に不満があるという方！組合や労基署に走るのもいいですが、まずは転職サービスへ登録すると一気に悩みが解決するかもしれません。弊社では多数の業界に特化した転職サイトをご提供しております。

働き方を変えたい方、年収を上げたいと考えている方、もっとワクワクするような技術をやってみたい方は弊社の転職ナビシリーズをよろしくお願いします。

今回はシステムエンジニア転職ナビというサイトを貼っておきます。他の転職ナビについては、Googleで「＜業界名＞ 転職ナビ」で検索してください！ということで続きはWebで！

※以下は弊社のシステムエンジニア転職ナビのリンクです。

systemengineer-job.com

デザイナーが「言葉」についてちょっと真面目に考えてみた

こんにちは。白木と申します。デザイナーです。

前回はデザイナー採用担当者の目線でポートフォリオについてお話をしました（下記）。多くの方にご覧いただけき、「参考になった」というフィードバックもいただきました。ありがとうございました。

lab.astamuse.co.jp

さて、今日はもう少し抽象的なデザインの話をしようと思います（時間ない方はブックマークしてお時間あるときにお読みください）。お題は「デザイナーが「言葉」について真面目に考えてみた」です。

デザイナーに求められる能力は多様？

本題ではありませんが、デザイナーに求められることは実に多様です。デザインがそもそも統合的・領域横断的な性格であるため、周辺領域からの知識要請がとかく多いと日々感じています。

例えば椅子一つ作る場合、デザイナーはただ美しい形状を追い求めるではなく、構造力学、材料工学、人間工学の側面も考慮せねばなりません。また、製造現場とのすり合わせや（「それ型で抜けるの？」的な）、コンセプト落とし込みの調整役もこなしますし、場合によっては何が売れるのかをマーケティング側とすり合わせるところにも関与します。簡単なマーケティングリサーチの知識も必要とすることもあります。

Webデザインも同様です。このご時世、企画、マーケティング、エンジニアリングと無関係でサイトやサービスを完成させることはあり得ません。いずれの隣接領域に対しても越境的にディスカッションできる程度には専門知識を備える必要があります。

しかし、実際には私たちの仕事はこれらの専門的知識・知見だけでなく、その土台をなす非専門的な能力によって支えられているように見えます。むしろ非専門的な部分の方が実は支配的なのではと思わせるほどです（仮説）。

デザインの専門領域外で重要な要素とは？

では、専門領域以外の重要な要素とは何なのでしょうか？先ほどの仮説から言えば、それはデザイナーの仕事を考えればおのずと出てくる答えですが、先に私なりの結論を示すと以下の3点です。

1. 言葉・概念
2. 思考・洞察力
3. 多様な経験

1は私たちが作ったものに文脈やフィロソフィー、説明を与えるために必要な要素です。2の思考・洞察力は特段デザイナーに限定される話ではないですが、デザイナーらしい思考・洞察力はあると私は思っています。3についてはデザインを生み出す原体験の多様さです。

紙面と時間の関係上、本日は1のみ整理しますが、2,3についても日を改めて整理できればと考えています。ということで以下「言葉・概念」についての考えを整理します。

デザイナーの仕事の特徴と言葉・概念

デザイナーは「抽象的なもの・ことを形にすること」を仕事にします。クライアントや企画の想い・意図を解きほぐし整理し秩序を与えながら形に変えていく生業です。ほかの職種と比べて対象テーマが感覚的・感性的なことが多く、ここがデザイナーの難しさの一つでもあります。

さて、この感覚的・感性的なテーマに向かっていく中で、言葉・概念という武器が少ないとクリアが難しくなるというわけです。

言葉・概念が対象テーマの的確に把握できない

まず言葉・概念の扱いがうまくないと、対象テーマを正確・的確に把握しにくくなります。

例えば「信頼感を醸成したい」というテーマがあったと仮定します。この場合、普通は「信頼感とは何か」を考え「誠実」「落ち着いた」などの言葉に至るのですが、本当に表現すべきことが「内省的な印象を備える信頼感」であった場合はどうでしょう。デザイナーが「内省的」という言葉・概念を知らなかった場合、どうなるのでしょうか。的確にテーマを捕捉しえるでしょうか。

サピア・ウォーフの仮説*1ではありませんが、適切な言葉を持ち合わせていない中で曖昧・複雑なことを的確にとらえることはおそらくは困難です。先ほどは「内省的」という発見されやすい例を出しましたが、実際の現場ではもっと面倒でわかりにくいケースがゴロゴロしています。これらを形にするのに、それを表現できる言葉が少なくては、落とし込みにに膨大な時間とコストがかかるか、結構な量の情報が落ちてデザインの精度が下がるかです。

言葉・概念によるデザインの背景・哲学を形成が困難になる

次にデザイン説明時にも問題に遭遇します。

何かしらのデザインができた時に、デザイナーはそのデザインに至った背景や理由の説明責任を負います。デザインの対象は感性的であることが多いため、そもそも説明コストは高いのは当然です。が、仮にデザインしたものが企業ロゴなどであったら、感性的な要素だけでなく企業のフィロソフィーすらもデザインに乗せることになりますから、それをどう言葉に落とし込むかは能力の求められることろです。

ただ、この点においては反論もあって、そもそも言葉を必要とするデザイン自体が問題なのではないかという指摘です。これは一理あります。言葉を必要としないように直感的なものを指向することも選択肢としてはあります。しかし、説明が不要かどうかを決めるのは提案するデザイナーではなく、それを受け取る側に依存しますから、依然説明ないし言葉は必要であると考えるのが自然です。

また直感的に理解し得るものであってもデザインに込められたフィロソフィーをどう伝播させるかという観点から言えば、伝達媒介としての言葉はやはり重要でおざなりにはできません。

言葉をなくして観察ができるか

物事を観察するときにどこまで精緻に記憶・記録できるかは、観察の分解粒度と的確な言葉の利用が求められます。

昨今では「かっこいい」で表現できる幅が随分と広がりましたが、あらゆるものを「かっこいい」と評してしまうと、一体何が恰好よく足らしめているのかは解らないままです。色なのか構図なのかプロポーションなのか時代とのギャップなのか。観点は多様で、その観点を説明する言葉もまた様々です。日常の軽い会話であれば「すごい」「かっこいい」でもいいのかもしれませんがデザインを説明する時、またデザインを学習するときは、細かい部分にまで言及し的確に表現することが重要なのは自明のように思えます。

高尚な言葉・概念を使えばいいわけではない

さて、ここまで言うと「かっこいい言葉使わないといけないのかな」と思われるかもしれませんが、そんなことは全くありません。あくまで的確な言葉を探すこと・身につけるです。それもきちんと共感を得られる言葉、もしくは少しの学習で理解可能な言葉の中で、です。

かっこいい言葉を使うことは、排他的な面があります。専門家が専門用語で話している中に素人が入り込めないのと同じように。もしそういった高尚な言葉を使いたいのであればそれが通じる人との中でだけ使ってください。わからない人に対してひけらかし的に使わないよう心掛けてください。ひけらかしとして使うのは却って底の浅さを映すことになります。

説明くさくあれと言っているわけではない

また、ここまで言うと「随分と説明くさくしなければならないんだな」と思うかもしれませんが、それも意図しないところです。飽くまで問題の本質をとらえるために言葉が大事だとご理解いただければと思います。必要な時に必要な量の的確な言葉を出せるようになることと、物事をより正しく理解するために言葉が重要なのであって、説明的であることは重要ではありません。

最後に

デザインを的確に行い、その意図を理解してもらうことは、とりもなおさずデザインという世界そのものの理解を広げることと同義だと思っています。そのために私たちは言葉を身に付け伝え続けなければならないと改めて認識します。そこを怠り、デザイナーらが自身ら身内の言語に満足して外に向けての説明を放棄してしまうことは不信感を助長し、象牙の塔の印象をもたらすだけでしょう。そのような業界に未来はありません。

デザインとは相手とのインタラクティビティによって生まれてきます。そこでのコミュニケーションを語る前段として、まず良いコミュニケーションを行うための道具磨きが必要であり、それが豊かな言葉の獲得なのです。 日々の作業に追われているとWeb上のノウハウの収集ばかりに終始してしまいがちですが、たまには立ち止まって自分の言葉磨きなどもしてみるのはいかがでしょうか*2。

*1:サピア＝ウォーフの仮説

*2:ちなみに私は言葉磨きのために自分の考えていることを実際に紙に書いてます。それだけでも言葉がだいぶ使えるようになります。