reizist's blog

ウェブ

#prestodb のクエリ履歴を保持する

TL;DR

  • prestoのクエリログを全て保持したい
  • 簡易に行うならAPI経由で取得できる
  • きちんと環境を準備するなら event-listenerを使う方法がよく、自分のケースでは presto-fluentdを使用してfluentdを経由しデータストアに送信している

背景

prestoはFacebookが開発した、Hadoop上で動作する分散SQLエンジンである。 Hiveと比較すると、オンメモリで動作するのでCPU効率が良く高速に処理されるので、アドホックな環境に向いている。 このprestoを運用する上で欠かせないであろう実行クエリの履歴管理に関して、きちんとまとまっているエントリは少ないと感じたので書く。

クエリログの取得

方法1: 簡易(API経由)

手っ取り早く情報を取得するには、 http://<master node ip>/v1/query APIが使用できる。

[
    {
        "memoryPool": "general",
        "query": "SELECT ...",
        "queryId": "20171117_163751_00480_7vfi8",
        "queryStats": {
            "blockedReasons": [],
            "completedDrivers": 83,
            "createTime": "2017-11-17T16:37:51.152Z",
            "cumulativeMemory": 355882963.0,
            "elapsedTime": "1.79s",
            "endTime": "2017-11-17T16:37:52.943Z",
            "executionTime": "1.79s",
            "fullyBlocked": true,
            "peakMemoryReservation": "0B",
            "progressPercentage": 100.0,
            "queuedDrivers": 0,
            "runningDrivers": 0,
            "totalCpuTime": "86.63ms",
            "totalDrivers": 83,
            "totalMemoryReservation": "0B"
        },
        "scheduled": true,
        "self": "http://172.xx.xx.xx:8889/v1/query/20171117_163751_00480_7vfi8",
        "session": {
            "catalogProperties": {},
            "clientTransactionSupport": false,
            "locale": "en_US",
            "preparedStatements": {},
            "queryId": "20171117_163751_00480_7vfi8",
            "remoteUserAddress": "172.xx.xx.xx",
            "startTime": 1510936671152,
            "systemProperties": {},
            "timeZoneKey": 0,
            "transactionId": "26a22b5a-0c8d-4413-9b07-13ab4412e822",
            "user": "hadoop",
            "userAgent": "presto-ruby/0.5.2"
        },
        "state": "FINISHED"
    },
    {
       //   
    }
]

上記のようなフォーマットで実行されたクエリ最新N件の情報が取得できる。 このAPIを定期的に叩いてパースしてデータストアに突っ込むだけでよいので、容易に実装ができる。 ただし 最新N件取得する という点が問題で、例えば1分起きにAPIを叩くスクリプトを実行したとして、深夜帯など一切クエリが更新されない環境の場合APIを叩くたびに同じクエリIDの情報を格納することになってしまうので、大量の重複データがデータストアに溜まることになる。 このため、重複を許容するか、何らかの方法で重複させない実装を挟む必要がある。 即解決可能な策としてはデータストアにRDBを用いてクエリIDをuniqueにする方法が考えられるが、ここではfluentdを使った方法を紹介する。

拙作ではあるが fluentd-plugin-comparison-filterというfluentd filter gemがある。 このgemは、 column_key で指定したカラムの値で、次に処理するレコードが最新のものか判断し、最新のレコードだけ出力する プラグインだ。

細かい値や制御を無視して要点だけ実装すると、このようになる。

require 'json'
require 'yaml'
require 'erb'
require 'presto/metrics'
stage = ENV["STAGE"] || "development"
config = YAML.load(ERB.new(File.read(File.expand_path("../init_config.yml", __FILE__))).result(binding))[stage]
client = Presto::Metrics::Client.new(host: config["host"], port: config["port"])

metrics = JSON.parse(client.get('/v1/query'))
metrics.select{|m| m["state"] == "FINISHED" || m["state"] == "FAILED"}.sort_by{|m| m["queryStats"]["endTime"] }.select do |m|
  query_id     = m["queryId"]
  start_at     = DateTime.parse(m["queryStats"]['createTime']).to_s
  end_at       = DateTime.parse(m["queryStats"]['endTime']).to_s
  query        = m["query"].gsub(/(\r\n|\r|\n)/, '\\\\n')
  status       = m["state"]
  puts JSON.dump({query_id: query_id, query: query, start_at: start_at, end_at: end_at, status: status))
end
  • in_execを用いてデータを受け取るfluentdの設定の例
<source>
  @type exec
  tag presto.query_stats
  command ruby /opt/presto/fluentd_put_query_stats.rb
  run_interval 1m
  <parse>
    @type json
  </parse>
</source>

<filter presto.query_stats>
  @type comparison
  <comparison>
    column_key end_at
    column_key_type time
    time_type string
    time_format %Y-%m-%dT%H:%M:%S %z
  </comparison>
</filter>

<match presto.query_stats>
  @type copy

  <store>
    @type relabel
    @label @bigquery-out
  </store>
</match>

# 後続の処理

APIを1度叩いて得たreponseに関して実行された順にfluentdで処理を行い、fluentdではクエリの実行完了時間を用いて「レコードが最新かどうか」判断することで、再びAPIを叩いて全く同じレスポンスだったとしても前回のレスポンスにより最新のレコードまで取り込んであるので、取り込み済のレコードはフィルタリングされるという挙動になる。 これでクエリの重複は回避することができた。

しかし、実はこれでもまだ問題がある。 APIを叩く頻度を1分毎であるとする。また、1回のAPIで得られるクエリ件数は40件とする。 この状況で、例えば高負荷により分間40回を超えるクエリが実行された場合、今度はクエリの取り逃しが発生する。

取り逃しを発生させないために頻度を上げて例えば10秒に1回実行するなどの選択肢はあるが、そもそも不要な処理を行い負荷をかけるのは良い判断とはいえない。

方法2: event-listener経由

方法1では、クエリ情報取得の重複・漏れの可能性があったが、実はprestoには event-listenerと呼ばれる機構があり、クエリ完了時に任意のプログラムを走らせることが可能である。 これを用いてクエリ完了時に各メトリクスをデータストアに保持するようにすれば、無駄なく漏れなくクエリログの取得が可能である。

観測範囲では2つのプラグインがあり、 一つはクエリ結果をファイルに書き出すpluginpresto-audit、もう一つはfluentdに送信するpresto-fluentdだ。 個人的にはfluentdはretry処理や複数のデータストアへの送信を柔軟に行える点で便利だと考え後者を採用した。

fluentdが非常に容易に各メトリクスを処理できるので、

  • メトリクスはdatadogに
  • クエリログはbigqueryに

それぞれ送信し、日々の監視/運用に役立てている。

  • event-listener.properties
event-listener.name=presto-fluentd
event-listener.fluentd-port=24224
event-listener.fluentd-tag=presto.query
event-listener.fluentd-host=<送信対象のfluentd host>"
  • fluentd.conf
<match presto.query>
  @type copy

  <store>
    @type relabel
    @label @presto-query-stats
  </store>

  <store>
    @type relabel
    @label @presto-query-storage
  </store>
</match>

<label @presto-query-stats>
  <match **>
    @type copy

    # elapsed_time
    <store>
      @label @presto-datadog-out
      @type record_reformer
      enable_ruby true
      renew_record true
      tag presto.query_stats.elapsed_time

      <record>
        type gauge
        metric presto-observer-<%= ENV["STAGE"] %>.query_stats.elapsed_time
        value ${(record["endTime"] - record["createTime"]) / 1000.0}
        tag ${record["user"]}
      </record>
    </store>
    # 略: その他各メトリクス
  </match>
</label>

<label @presto-query-storage>
  <match **>
    @label @presto-bigquery-out
    @type record_reformer
    renew_record true
    tag presto.query_storage.big_query
    <record>
      query_id ${record["queryId"]}
      user_name ${record["user"]}
      elapsed_time ${(record["endTime"] - record["createTime"]) / 1000.0}
      start_at ${Time.at(record["executionStartTime"]/1000).utc.strftime("%Y-%m-%d %H:%M:%S.%3N")}
      end_at ${Time.at(record["endTime"]/1000).utc.strftime("%Y-%m-%d %H:%M:%S")}
      query ${record["query"]}
      status ${record["state"]}
    </record>
  </match>
</label>

<label @presto-datadog-out>
  <match **>
    @type dd
    dd_api_key <%= ENV['DATADOG_API_KEY'] %>
    <buffer>
      # 略
    </buffer>
  </match>
</label>

<label @presto-bigquery-out>
  <match presto.query_storage.**>
    @id bigquery-partitioned
    @type bigquery
    method load
    auth_method json_key
    json_key /fluentd/env/googleauth_key.json

    <buffer>
      # 略
    </buffer>
  </match>
</label>

結論

event-listenerを用いて、重複・漏れなく効率的にクエリの履歴を残すことができる。 fluentdを使うことで複数のデータストアに結果を送信することができるので、柔軟に監視環境を構築することができる。

datadogの設定をterraform formatで出力するgem dd2tfをリリースした

datadogの設定をterraform formatで出力するgem dd2tfを作った。

github.com

kurochan/datadog_monitor2terraformにインスパイアされて勢いで作った。 (尚動機としては、コード管理していない設定、例えばmonitorを管理者が(レビューの範囲外で)手動操作を行い想定外の挙動をしてしまった出来事があり、アラートは特にしっかりと管理したいモチベーションがあった。)

現在terraform側で扱えるdatadogのリソースとしてはdowntime, monitor, timeboard, userがあって、 このうち現在はmonitor, timeboard, userをサポートしている。

downtimeをそもそも使っていないのでサボってしまったが手間じゃないのではやいうちに追加しなくては。

datadogの設定がコードで記述できるという点はやはりメリットが大きいんだけど、

q = "avg:presto_staging.cluster_memory_manager_metrics.cluster_memory_usage_bytes{*}"

みたいなクエリを毎回書くのか、というと微妙なところで、グラフの様子を見ながらいじって決めるということが多く

今の自分の使い方としては

まず画面でポチポチいじって、dd2tf使ってコードをexportしコードをリポジトリ管理下に置いている。

terraform apply するタイミングで注意することがあって、既存のリソースを terraform import しておかないと、 重複してリソース登録されてしまう。

なので、実際に行う手順としては

  • web consoleから各リソース設定
  • terraform import
    • この際、 dd2tf print <resource> が便利で、 terraform importコマンドを出力してくれる
dd2tf print monitor --dd_api_key=xxx --dd-app_key=xxx
terraform import datadog_monitor.auto_clock_in_sync_with_ntp 29xxxxx
terraform import datadog_monitor.presto_long_time_query_occured 29xxxxxx
  • dd2tf import
dd2tf import monitor --dd_api_key=xxx --dd-app_key=xxx

のようになる。

datadogの使用頻度が増してきているので、且つコミュニケーションの齟齬なく運用できそうなので便利。

ある程度実装してから、 terraform import して得た <resource>.tfstate をparseする方針の方が筋が良いのでは、と思った気がしたけど忘れた。

自作PCやるぞと思ったら時期が悪かった

MacbookProの不安定さにエンジニアのmac離れが進む昨今、PCの組み立ての1つや2つやっておくべきだろJK(死語)という安直な考えからPCを組み立てるためにパーツ選びをした。

パーツ選びの最中って、楽しいなーーーーーーーーー?

よーしパーツ固まった、今週末買いに行くぞ!っていうテンションの絶頂時に「近いうち新世代CPU出るぞ」という情報をもらい、 改めて調べなおして時期が悪いということがわかりテンションがだだ下がっている。

尚新たにリリースされる(た)新世代CPUについては概ね

www.itmedia.co.jp

を参照すると良さそう。この世代から対応チップセットが変わるので、現時点で他のパーツを購入するのはだめっぽい。

少し前にryzenがハイスペ・コスパ良CPUをリリースし、 いい感じにintelと価格競争する体制に入ったのか次世代から10年ぶりらしいラインナップの刷新が行われた。

尚海外では既に発売されているのでベンチマーク等をぐぐるとよい。

尚組もうと思っていたパーツを列挙するが、噂によると新世代CPUはめちゃめちゃコスパの良いモデルもあるようなので、 CPUを新世代に/それに伴いマザボを300シリーズに/電源もちょっとアップデート あたりを予定していて、まぁ乗って+2万くらいじゃね?と予想している。 11月後半には出るんじゃないかと思ってるので楽しみに生きる。

グラボ

まぁ1070くらいでいいのではという気持ち。10万超えのGPU買うくらいなら差分の5万使ってipad proとか360℃カメラとかに投資する。 リリースされているほぼすべてのゲームで高画質プレイできるという話を聞いている。

CPU

intel製で現時点で日本発売済の一般的なレンジの最上位あたり。 別にOCに特別興味はないが多少1コアあたりのスペック高いので。 尚新世代発売したら8700Kか値段によってはi5-8400あたりを買う予定。

ケース

よく知らないので無難 of 無難。水冷にするつもりは最初はないが、最低限冷やし性能を持ちつつ拡張性もあるミドルタワー。

電源

gtx1070使ってて550wの電源使ってて不安定みたいなレビューを見た気がするので600w以上、まあ700あれば長く活きてくれるでしょう5000円程度ケチらないくらいの雑な選択。

マザボ

7700Kに対応してればなんでもいいやくらいの雑な選択。

メモリ

とりあえず16GBあれば人権ある。linux OSにすればmacほど要らんしそんなめちゃくちゃ高画質なゲームやるつもりはないし。あっても4本メモリ挿せる構成なので32GBいける

HDD

んーOSロード用ディスクはSSDにする予定なんだけど今のところHDDでコスト削減をもくろんでいる・・・・が買うタイミングでSSDにしてしまう未来が見える

SSD

一応500GBは確保。

雑に見積もった感じ17万くらいなんだけど新世代のCPUにするにあたりアプデするもの(マザボ等)、SSDの件を考慮するとなんだかんだ20万いきそうだなー15万想定で組んでいるのになー不思議

prestoの挙動で困っているメモ

よく The node may have crashed or be under too much load. などで PrestoQueryError が発生するのでログを辿ったところ、

  • GCが頻発している
  • S3 readが時間がかかっている
  • 謎のWARNが発生している

ことを発見したのでメモ

GCが頻発している

2017-08-18T07:04:13.189Z        INFO    Code-Cache-GC-Trigger   com.facebook.presto.server.CodeCacheGcTrigger   Triggering GC to avoid Code Cache eviction bugs
2017-08-18T07:05:08.208Z        INFO    Code-Cache-GC-Trigger   com.facebook.presto.server.CodeCacheGcTrigger   Triggering GC to avoid Code Cache eviction bugs
2017-08-18T07:05:32.265Z        INFO    Code-Cache-GC-Trigger   com.facebook.presto.server.CodeCacheGcTrigger   Triggering GC to avoid Code Cache eviction bugs
2017-08-18T07:05:56.210Z        INFO    Code-Cache-GC-Trigger   com.facebook.presto.server.CodeCacheGcTrigger   Triggering GC to avoid Code Cache eviction bugs

GCしすぎちゃうか

解決策はいくつかあり、

CodeCacheSizeをいじる

jvmの各パラメータをいじればよさそう

  • InitialCodeCacheSize (byte)
  • ReservedCodeCacheSize (byte)

CodeCacheThresholdをいじる 

classification: presto-configcode-cache-collection-threshold をいじればよさそう(config.properties)

GC1を使えば良さそう

ここは一切チューニング・検証してないのでjust idea JVMとGCについてちゃんと調べなきゃいけないんだけど、Full GCが高い頻度で発生していると問題 Full GCが遅いのは全ての領域対象だから。 New領域のみ対象のScavenge GCなら頻度高くても処理時間はそこまでぽい。

参考: G1GCのつかいどころメモ - nekop's blog

S3 read時間がかかっている

ちょうどquery metricsを取得実装始めていたんだけど、 status: FINISHED のみ取得しており、結果的にFAILEDな本件では情報無く無事死。

com.amazonaws.latency    ServiceName=[Amazon S3], StatusCode=[206], ServiceEndpoint=[https://xxxx.s3-ap-northeast-1.amazonaws.com], RequestType=[GetObjectRequest], AWSRequestID=[xxxx], HttpClientPoolPendingCount=0, RetryCapacityConsumed=0, HttpClientPoolAvailableCount=0, RequestCount=1, HttpClientPoolLeasedCount=4, ResponseProcessingTime=[0.046], ClientExecuteTime=[101.892], HttpClientSendRequestTime=[0.044], HttpRequestTime=[101.613], RequestSigningTime=[0.086], CredentialsRequestTime=[0.0], HttpClientReceiveResponseTime=[73.346],

みたいなログが20-30行程続いており不穏。なんだ101って。異常では

謎のWARNが発生している

Aug 18, 2017 6:44:53 AM WARNING: parquet.hadoop.ParquetRecordReader: Can not initialize counter due to context is not a instance of TaskInputOutputContext, but is org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl

これはバグ?

https://issues.apache.org/jira/browse/SPARK-18660

ふー地道に調べるか

株式会社Reproで働き始めてから3ヶ月経った

Reproで働き始めてから3ヶ月経った。経ってしまった。

入社してから、ではないのは、始めの2週間はフリーランスとしての契約だったため。正社員としての入社は4/1からなので、社員として2ヶ月半を過ごしたことになる。時間が経つのが早すぎる。

なんで3ヶ月経った時点でブログを書いているかというと、一瞬で会社を辞めることも無くはなかったしそもそもアウトプットするほど大した仕事をしていなかったから。

まだまだだけど最近はできそうなことを少しずつやっている感じで一旦「僕はReproの社員です」と名乗ってもいいか、という自分なりの解を得たので、

そろそろちゃんとパフォーマンス出していかないとという戒めも込めて自分のためにも振り返りと、あわよくばこれをもってReproという会社に興味を持ってくれる人がいてくれたらと思い思考を垂れ流しつつ記事に落とす。

何をしているか

今自分はSREチームとして働いている。SREチームの定義でいうとまぁやっぱりメルカリのそれに近くて、

可用性の向上、パフォーマンスの担保、開発環境の効率化を軸に機能開発以外の開発を全て見る、という方針で動いている。

とはいえ扱うミドルウェアからサービスまでとても幅広く、多くのOSSを採用していることから身につけるべき知識は大量にあり、 高パフォーマンスを維持するためのシステムの複雑度もあり最初の1ヶ月はただただ翻弄されていたように思う。

少しずつ深いところに手を出しつつあるが、入社当時は「docker is 何」状態だったこともあり苦労が絶えない。

流石になんでもやりますと言って全て中途半端な状態は良くないので最近は専門性を持つことになっていて、自分に関してはデータストアを中心にインフラに近いところでコードを書く仕事をしている。

主に触っているものを挙げると以下の通り。

AWS

  • cloudfront/s3/ec2/elb/rds(aurora)/elasticache/route53/sqs/などの一般的なウェブアプリケーションに使用するもの
  • ecs
  • lambda
  • cloudwatch
  • emr
  • その他これらに付随するacm/kms/iam等を使った権限やパラメータ管理

OSS/PaaS

大体terraformとにらめっこしていたり、ミドルウェアのバージョンを上げたり、他チームから挙がってきた機能追加に合わせてパフォーマンス監視したり、コードレビューをしたりされたりしている。

いまいまでいうとドメイン分離(静的サイトとアプリケーションの分離)、ridgepoleを運用に乗せるにあたって発生した諸々(fk貼り直しとか)の作業と、emr cluster周りの設定の確認と見直しをやっていて、少しずつデータストアに作業がよってきている。わからないことだらけで辛いがわかるようになるのは楽しい。

なぜReproに入ったか

そもそもなんでReproを選んだかというとスピード感のある組織の中で働くイケてる開発メンバーに惚れ、イケてる開発に携わりたいと思ったからだった。 どの辺がスピード感があるかというと、「とりあえず会社に遊びに来てください」ということになり会社に遊びに行ったところ、会議室に入って15分でその日からお試しで働くことになったことがまず筆頭に挙がる。

エンジニアの採用は採用する側もされる側も大切な意思決定であるにも関わらず、入社するまでの間に100%お互いの意思をすり合わせることは難しい。 個人的には「とりあえず一緒に働いてみる」が一番手っ取り早い手段だと思っている。趣向や技量を把握するのにこれ以上効率的なことは無く、表面上の経歴や上辺だけの会話より遥かに確度は高いと思う。

そんなわけで働き始めると、当初聞いていた以上に高い技術力で作業をこなすメンバーばかりで控えめに言ってビビった。 登壇を良しとする社風があるのでCTOのjoker氏を筆頭に勉強会やカンファレンスで登壇するメンバーもおり、かっこよい。

実際に入ってどうか

日々多くの知識を持っていないと進められない業務があり辛い。1つわからないことを調べると10個くらいわからないことが増える気がする。 スタートアップなのでそれなりのアウトプットは求められており、期待に達しているかどうかでいうと censored。 GRITを読み自分を鼓舞しながらなんとかやっているというのが実際のところ。

関係ないけどGRITはいいぞ。人生という荒波に立ち向かう勇気を無くした際は是非読んでください。

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

やり抜く力 GRIT(グリット)――人生のあらゆる成功を決める「究極の能力」を身につける

GRITの紹介終わり。

とはいえ技術力の高いメンバーに囲まれているので刺激になるし、相談すれば答えてくれるし、エンジニアとして幸せな環境だと思う。

本音を言えば不満も少なからずあり、小さいものでいうと会社をハードウェアとして見ると前職にはどうしても見劣りする(狭いとか)点や、入った当初考えていたこと(具体的にはグロースハックにもともと興味がありそういった知見を得たい)が今このままだと達成できない(それどころじゃない)というようなこともあるが、どこにいったって100%やりたいことをやるにはそれなりに"“力”“が必要でその能力を今持ち得ていないという背景がありやるべきことを粛々とやるフェーズということで納得することにしている。

これから何をするか

直近1ヶ月は分散データストアというものにフォーカスして安定性/パフォーマンスの向上に寄与したいと思っている。 ちょうど今日は、デフォルトの max open files count4096 であるpresto processが稀に上限に引っかかって例外を起こすので custom bootstrap actionでulimitで調整するPRを出した。そんな感じのことを引き続きやっていきたい。

Reproに興味のある方がいたら

多分ですけどギークっぽいエンジニアの方が趣向は合うと思います。僕は非ギークです。 AWSOSSにたくさん触れたい、技術力を持ったメンバーと一緒に仕事をしたい、大量のアクセスを捌く経験がしたい、そんなエンジニアは面白そうだと思ったら一回遊びに来たらいいんじゃないでしょうか。wantedlyで募集してますよ。

www.wantedly.com

www.wantedly.com

www.wantedly.com

www.wantedly.com

よろしくお願いいたします。

転職活動してた

昨年12月に2年8ヶ月ほど働いた株式会社イグニスを辞めてからスタートアップの立ち上げ的なことに関わり、様々なことをしましたが、

本当に様々なことがあり(本当に)、様々な事情により、転職活動を終えました。スタートアップは大変ですね。楽しいですよ。

転職活動にはwantedlyを主に使用した。 決して自慢とか満足感とかそういうのではなく、ネームバリューのない一エンジニアとしてのwantedlyでの活動報告は以下のようになります。

  • 「話を聞きたい」ボタンを押した数: 9
  • 「企業からの返信待ち」: 3 (そもそもコミュニケーションがとれなかった)
  • 「スカウト」: 7
  • 何かしらコミュニケーションをとった企業数: 13
  • 「話を聞きたい」ボタンから実際に話を聞きに行けた企業数: 4
  • 「話を聞きたい」ボタン押下後、履歴書/経歴書を求められた企業数: 3
  • 「話を聞きたい」ボタン押下後、履歴書/経歴書を求められた後話が進んだ企業数: 0
  • 会社に一度でも足を運んだ企業数: 6
  • 転職の意思を伝え、実際に採用フローに乗っかった企業数: 5
  • お祈り数: 2
  • 内定数: 3

以前はエージェント経由だったりGreenなどの転職サイトを使用したが、今回はwantedlyのみで他のスカウトメール等は一切未使用だったので、 wantedlyでチャットやってるだけで採用進んだみたいな感覚があり、転職活動のハードルも下がったなぁと思った。

pull型転職というか、めちゃくちゃ能動的に仕事探すというよりは降ってくる情報に乗っかる感覚というか。まぁこれでいいのかみたいなのもあるけど。 とはいえ、wantedlyの「話を聞きたい」ボタン、ユーザー・企業間に温度感の隔たりがあって、企業側としては当然効率よく採用活動したいのわかるし、多分正しいんだけど、 ただ話を聞きたいと思ったユーザーに書類求めた挙句速攻お祈りor無視というパターンが何度かあり、告白してもいない女の子に振られる感じでアレだった。

本当に優秀なネームバリューのあるエンジニア陣は退職ブログ書くだけで内定を無限にGETしていたりするので、そうなりたいなーとも思うけれど 二回目の転職活動はこんな感じだった。

あと、フリーランスとしてなら無限に人づてに仕事があり、最悪死なないということがわかった。 (フリーランスの世界に入ると、フリーランスの人にのみ?情報が出回るというか、大体金があるところに仕事の話があり、地球は回っている)

しばらくはエンジニアとしてもう一回りやっていき、視野を広げたい所存。

HyperDrive: Thunderbolt 3 USB-C Hub for 2016 MacBook Proレビュー

www.kickstarter.com

kickstarter経由で購入したMacBook Pro 2016用のusb-cハブ、 HyperDrive: Thunderbolt 3 USB-C Hub for 2016 MacBook Pro のレビューです。

仕様

f:id:reizist:20170320234525j:plain

外観

イカしてます。macbookとマッチする高級感があり、値段相応です。

レザー生地の入れ物もついているので持ち運びも問題なさそう。

f:id:reizist:20170321000328j:plain

実用性

推奨どおりの装着だと接触が悪く、しっかりハマっていない感じがする。自分のmacが悪いのかHyperDriveが悪いのかは謎。しかし推奨方法で使えないのでがっかりした。

とはいえ逆だと「カチッ」という音と共にしっかりハマっており通常通り動作している印象がある。 接触が問題ない状態だとすればかなり便利で、各種アダプタがない状態であたふたしないで済みそうなのでmust buy感がある。appleが作って欲しい。

個人的にはmicro-SDをmacbookに挿したいことが多く、この場合2つのアダプタを介すなどしており全く2017年にもなってなんて不便な生活なんだと思わなくもなかった。

所感

minimumで$69, shipping含めて $79したので高い。高いゆえに品質を期待していたので、残念に思う部分もある。

とかでもいいのかもしれない。