水深1024m

技術的なメモとか日記的なもの

2020年の振り返りと2021年

振り返りというのを2017年以来書いてなかったようなのだけど、イギリスに移住するというビッグイベントもあったのでざっくりと書いてみます。

イギリス移住

今年最も、そして人生の中でも結構大きいイベントでした。仕事で機会がありイギリスに移住しました。イギリス移住といえば…のロンドンではなく、ロンドンから遥か西にあるブリストルという街にいます。日本人には同僚以外ほとんど会ったことがないです。

2019年の夏くらいに行くことは決めていて、本来であれば2020年4月には移住する予定でした。が、突如襲った COVID-19 への対応を全力でしていたこともあり、4月の段階では日本にいるべきという判断をして、延期していました。 その後も一向に改善しない状況を眺めつつ過ごしていたのですが、2020年も半年が過ぎようとするくらいの頃、人生における時間の使い方を改めて考えてみて、31歳の自分は今この瞬間にしかいないんだよな…みたいなことを思い、困難は承知の上でこのタイミングで渡航することにしました。妻の理解も得られ (というより大賛成だった) 、10月にターゲットを決めて移住することに。

移住そのものが正解だったかはまだわからない、というより自ら正解にしていく必要があるわけですが、今のところは心から来てよかったと思っているし、そんなに不自由なく生活しています。来た当初は周辺のスーパーの違いもわからない、ゴミの捨て方も知らない、備え付けの家電の使い方がわからない、手続き類はわからないうえに COVID-19 の影響でオペレーションが変わっていたりと本当にわからないことだらけで、自活できる大人としてのプライドをまあまあ傷つけられましたが、それまでできなかったことが実体験をもって理解できるようになるとちょっとレベルアップした気になれるように。

大きなトラブルもそこまでありませんでした。

  • 引っ越した初日にシャワーを使ったら盛大に水漏れして 「住人変わるたびに言ってるんだ、お前は悪くない」というコメントを階下からもらう
  • 仕方なくもう一つのシャワーを使ったら深夜に謎のサイレンが鳴ってブレーカーごと落とした (結局これはなんだったのか今でもわかってない)
  • 住んでるアパートが古すぎて防音の概念が一切なく、朝は下の階のテレビの音で目覚め、夜は上の階でドコドコ鳴ってる重低音を聴いて過ごしてる
  • 車で橋を渡るのに Contactless なカードがないといけないのを知らず、さらに手持ちのカードが通らずに橋を詰まらせる
  • 宅配が来てもインターホンの調子が悪いせいで誰も応答できず、結局同じアパートに住む全部屋の呼び鈴が押されるので誰かの荷物が来るたびに住人が全員集合する

くらい。

家の面積が日本と比べてかなり広くなったので、ついに念願の仕事部屋を得ることができその点でも満足しています。ほかには、人生で初めて食洗器や乾燥機 (一体型でないやつ) を使えるようになるなど、日本より環境がよくなったところも色々とありました。もう洗濯機の上で仕事しなくていいんや…

食事についてもよく聞かれますが、今のところ特にまっずー、みたいな体験はしておらず、外食 (COVID-19 の制限でほぼできてないけど) やデリバリーでも基本的に美味しい食事が出てきます。ほぼ自炊メインなので影響がないというのもありそうですが… 食材はとても良いと思いました。肉が安くて美味しいし、ラムが一般的に売られているのもうれしい。出張でアメリカやイギリスに行っていた頃は、外食せざるを得ないこともあって一週間も滞在すると正直胃がかなり疲れてしまい、「はよ帰りたい~」という気持ちになることも多々あったのですが、どんな材料でも自炊によって「自分に合う」食べ方をしているとそのへんはよくコントロールできるのかなと思います。 日本の食材も、調味料は近隣のスーパーにあるものもあるし、アジア系スーパーに行けば大抵のものは手に入ります。アジア系スーパーは思ったより周囲にあって、日本の食材以外に中国や韓国、ベトナムなどの食材も手に入るので、日本より本格的な料理が作りやすいように思いました。

逆に手に入りにくいものと言うと魚ですかね… サバやサーモン、タラ、シーバスあたりがよく売られているもので、ほかにマグロも売ってますが刺身では食べられないものが多い (たまーに Sashimi (Sushi) Grade と名付けられたものが売られていて、それは生食できる) 。あとはエビやムール貝、牡蠣あたりでしょうか。日本では刺身をよく食べていたけど、それは難しい。アジとかサンマもまだ見かけてないです。

秋に渡英したので、冬に向けて日が短くなる一方で、朝は8時まで暗く、16時には真っ暗…みたいな生活が続いており、こちらはさすがに調子に影響してきたなと感じています。ビタミンDのサプリ (この時期はみんなそうらしく、薬局で山積みされていた) やいわゆる SAD ランプを試しはじめました。きっとそのうち慣れるでしょう。 まあそんなこんなで元気です。

仕事

ずっとやってきた SRE の仕事を初めて完全に離れ、コーポレートエンジニアリングという、社内向けの情報システム部門のマネージャーをしています。 2017年までマネージャーをしていたチームの一つでもあります。コーポレートエンジニアリングという名前が気づけばそれなりに一般的になっている昨今は面白いですね。 情報システムの領域をソフトウェアエンジニアリングや SRE などのスキルや技法、経験などをもって再定義してみたい、きっと面白いんじゃないかという気持ちを当時から持っていて、改めて自分の主領域となった2020年もその気持ちのままやっていくぞ!と思っていたのですが、 COVID-19 によって良くも悪くも脚光が当たった年だったなあと思っています。コード書く時間も少し増えた。 感染者数が増え始め、会社が在宅勤務を決定した2月から半年近くは、とにかく人と組織の事を考え続けた半年でした。具体的にどんなことやってたかは会社のブログ記事にもしているのでよければどうぞ。日経ビジネスに自宅を取材されたりもして新鮮な経験だった。

techlife.cookpad.com

techlife.cookpad.com

個人的には、環境 "だけ" で考えれば、ある程度遜色なく働ける状況が作れたのではないかなと思っています。が、1年近くをリモート勤務で過ごしてみると、どうにも物足りなさを感じているのが最近です。視覚と聴覚以外に刺激がない、というのは結構大きいのかもしれないなと思っています。感染者数が増える一方で、ワクチン承認などの明るいニュースもイギリスでは出てきている (すでに数十万人以上が接種を完了しており、Oxford と AstraZeneca のワクチンも先日承認された) という状況ではありますが、まだしばらくは誰もが在宅勤務を選ばざるを得ない状況が続くのは確実で、その中で、そしてその先で何を選ぶのかというのを引き続き考えていくことになりそうです。

それに加えて、とあるプロダクトの責任者を務めることになり、特に夏くらいからはかなりの時間をそちらについて考えることに使っていたりしました。これまでの仕事で使っていなかった筋肉を使う仕事というのは何度やってもよいものだなと思います。

タイムゾーン

イギリスに来たこともあり、時間の使い方がより大事だなと思うことが増えました。日本と話せる時間は朝7時くらい~10時くらいに限られている (もしくは深夜0時以降…) ので、必然的に日本のチームに関する仕事は朝に詰めることになります。どうしても朝に体力を使い切ってしまって昼にはベッドで沈んでしまい、イギリスのことは午後にスロースタート…みたいな日もよくあり。同僚に迷惑かけてしまうこともありました。 もともとかなり夜型だったところを朝型に矯正せざるを得ない状況で、自分としても朝型に変えられるのは歓迎ではあったのですが、まだ体が追い付いてないなあと思ってます。この辺はより良い塩梅を見つけていきたい。

買ってよかったもの

移住を決めていたこともあったので、選び方が必然的に「日本でもイギリスでも使えるもの」に集中するのですが、いくつか挙げてみます。

Yeti Nano

在宅勤務がトレンドになった当初はテンション上がってたこともあって YAMAHA の AG03 と ShureSM58 を買ってワイワイしていたのだけど、どうにも自分の環境では使い勝手が悪いというか、単にオーバースペックだったこともあって結局 Yeti Nano に変えました。ショックマウントとアームも買って使ってますが、少なくともヘッドセットのマイクよりは良い音になっていると思います。

ヨーグルティア

イギリスで手に入りにくいものの一つとして納豆があります。アジア系スーパーに行くと、日本のパック納豆が冷凍で売られてるのですが、そこまで美味しいとは言えなかったです。我が家は夫婦そろって納豆が大好きで、これが手に入らないのはかなりつらい。それもあって日本からこれを持っていきました。これはガラス容器がセットになっていて、プラスチックのように納豆のニオイがついてしまったりということもなく安心して使えます。(ついでに、食洗器が熱湯でガシガシ洗ってくれる) 大豆は周辺のお店で安く手に入るので、だいたい1.5kgくらいまとめ買いして、300g くらいずつ作ってます。種として冷凍納豆を 1/4 ずつくらい使い、30時間くらい保温しておけば1週間分の納豆が手に入る。おいしい。

Nespresso Vertuo

コーヒーが好きで毎日飲むのだけど、渡英当初周辺に豆を買いに行くような余裕もなかったこともあり、ちょうど Prime Day で安くなっていたので購入。イギリスではスーパーでも Nespresso 互換のカプセルが売られているし良いんじゃないかなと思っていました。が、なんと自分が思っていた Nespresso とは違い、最近出ているレギュラーサイズが淹れられるタイプで、カプセルも全く違う。カプセルのバーコードを読んで最適な量や淹れ方を変えているようで、互換カプセルなんてものはない、とかなり誤算でした…

が、実際使ってみると、自分としてはちょうどよいサイズ (250ml など) のコーヒーが簡単に淹れられて、フレーバーも気軽に変えることができ、また (自分が思うに) 味も美味しいので十分満足。どのコーヒーを淹れても、クレマ (泡) がかなりたっぷりできるので、そこは好き嫌いが分かれるかもしれない。色々な豆を試したい、であったり、コーヒーを淹れる時間が好きであったり、そうしたことに強いこだわりがなければおすすめできます。自分は少なくとも日本に帰るまではこれで十分良いなと思いました。

MEATER

MEATER Original 10m True Wireless Smart Meat Thermometer for The Oven Grill Kitchen BBQ Rotisserie with Bluetooth and WiFi Digital Connectivity: Amazon.co.uk: Kitchen & Home

日本の Amazon ではまだ売られてないようなので UK のものを。塊肉に刺すための温度計で、 Bluetoothスマートフォンと接続して使います。肉の芯温と外気温が計測でき、一度刺したらそのままオーブンに放り込んで使えます。 ローストビーフはもちろんですがステーキなどにも便利。これの何が良いかと言うと、計測を絶えず続けながら調理できるので、これまで正直雰囲気で決めるしかなかった「オーブンに入れる時間」を簡単に「ターゲットの温度」という計測できるものに変えられるというところ。通常の調理用温度計だと都度刺して確認する必要があったので…

塊肉大好きなのだけど、調理のたびにちょっとドキドキさせられていたので、これはとても良い買い物でした。安くはないけど!

2021年

COVID-19 の影響はまだまだ続きますが、この地でしかできない、あるいは感じられないことをできるだけ多く経験しつつ、グローバルなプロダクトや組織をそれぞれどう創っていくのか、人にとって技術はどうあるべきなのか、といった大きな話を考え実践する一年にしていこうと思っています。振り返りに対してシンプルすぎる気はしますが、まああまり書きすぎても仕方ないので。 あとは最近ジョギングを始めたのでそれを続けられるようにしたい。。。

そんなわけで今年も楽しくやっていこうと思います。どうぞよろしくおねがいします。

AWS re:Invent 参加7回目のエンジニアがおくる re:Invent 2019 おすすめの過ごし方

夏が終わって、今年も AWS re:Invent の時期が近づいてきました。 AWS 最大のグローバルカンファレンスである re:Invent の動き出しはかなり早く、5,6月にはもうチケットが売り出され、人気のあるホテルはそのくらいの時期に抑えないと部屋がなくなってしまう… というくらいのカンファレンスになっています。

今の会社に新卒入社してから、幸運にも毎年 re:Invent には参加できていて、登壇などもありつつ、今年で7回目になります (初回である2012年はまだ学生だったので行けなかった)。もはや re:Invent に行かない自分が想像できないレベル。

さすがに7回も行くと、いろいろわかってくることもあり、最近では自社でまだ参加していない人を積極的に連れ出すということをやったりしています。 その中で、「re:Invent にせっかく参加したならこんな感じで動くと良いよ」みたいなドキュメントを書いており、また去年はセミナーなんかでもお話する機会があったのですが、クローズドな環境で眠らせておくのももったいないなーと思ったので、「現地に行ける人」がどう行動するとより楽しめるのか、を文章として改めて書いてみようと思いました。今年のセッション予約は 10/15 (PDT なので日本では 10/16 超早朝かな) ですので、その前に気持ちを作っておく助けになればと思います。

基本原則

re:Invent の過ごし方としてもっともおすすめなのは、「現地でしかできないことに全力を使うこと」です。日本でできることは日本でやれば良いのです。

やりがちなこと

やりがち、というより、過去の自分がやって微妙な気持ちになった行動です。

セッションにずっと張り付く

会期中ずっとセッション (通常の発表) ばかりに張り付く、というもの。 re:Invent のセッションはそのほとんどが YouTube で資料ごと公開されます。聞くだけで全部理解できる方ならまだ良いですが、英語力に自信のない方はなおさら、通訳もないセッションを時差ボケの頭で頑張って聞くよりも、手と頭を動かしながら何かできるところへ行ったほうが面白いです。

ただし、Keynote や発表された新サービスのセッション、どうしても気になるセッションはやはり別。現地で周囲の雰囲気も含めて見ることはとても楽しいし、ためになると思います。

日本人とずっと行動する

会期中ずっと日本人と行動してて日本語しか話さず「モチベ上がった!来年は英語頑張るぞ!」になっちゃうパターン。まあいいとは思うんですが、 AWS Summit Tokyo で良いのでは、と個人的には思ってしまいます。 セッションやワークショップで隣で座った人と軽く話してみたり、日本人がどこに行くかは気にせず自由に行動するほうが刺激にはなるんじゃないかなと思います。

ちなみに某社では3人以上固まって行動するのはご飯のとき以外はやめようね、ということにしたりしています。

無限に名刺交換してる

自分がそういう役割なのだったら良いとは思うのですが、日本人が集まる店やパーティばかりに行っていても正直あまりグローバルカンファレンスに来た!という感じはしないんじゃないかと思います。re:Invent が提供しているスポンサーパーティである Pub Crawl とか、各社がそれぞれ開催してるレセプションとかに適当に遊びに行ったりするとかをやると、他社のエンジニアやスポンサー企業の (普段使ってるあの SaaS みたいな) 開発エンジニアとかと直接話す機会も得られて結構面白いです。

もちろん、普段会えない日本人と会うチャンス、というのもありはするのですが。二次会くらいから行く、でも十分話せるんじゃないかなと思います。

現地でしかできないことをやる

というわけで、上記のようなありがちな失敗は避けて、巨大な re:Invent を全力で楽しむためにはやはり現地でしかできないことをやるのが一番です。

Keynote を現地で見る

re:Invent の Keynote はめちゃ巨大です。どのくらかっていうとうまい表現が見つからないのでぜひ会場で見てほしい。会場の雰囲気、熱気、何かが発表されたときの会場の反応なんかも含めて、現地で楽しむといろいろ思うところが出てくると思います。

手を動かすイベントに参加する

セッションと同じ枠ではあるものの、ワークショップは実際にサービスを使って何かを作ってみるという内容になっています。ほとんどのワークショップではきちんとドキュメントが用意されているしサポートも手厚いので、実は英語が苦手でもぜんぜん楽しめます。 僕もいろいろなワークショップに参加しましたが、 DynamoDB の中級者向けデータモデリングを手を動かしながら学ぶものや、 Raspberry pi で Alexa Skill を作ってみるものなど、楽しいものがたくさんありました。

他に、GameDay や Security Jam, Hackathon といったイベントもあります。これらのイベントはかなりまとまった時間を使いますが、色々な国、色々なバックグラウンドのエンジニアとチームを組んで問題を説いていったりアーキテクチャの議論をするのはとても楽しいものがあります。僕は毎年 GameDay に参加しています。時折日本に持ってきて開催されるものもありますが、やはり本場の規模感と空気でやるのはすごく楽しいです。

Expo を回って喋って触る

いわゆるスポンサーブースも非常に巨大です。各社結構力を入れていて、営業だけでなく開発エンジニアがいたりするケースもあります。大きなブースだけでなく、小さなブースにも、数年後に日本にやってきてブレイクするようなサービスもありますので、普段聞いたことのないようなブースに行ってみるのが良いでしょう。 他にも、巨大レゴだったり卓球台だったり IoT おもちゃだったりといった体験できるものが色々と置いてあるので、そういうものに触れるのも楽しいです。

なんかこう、話を聞くつもりはないがTシャツだけくれ!みたいなのは、やらないほうが良いと思います…

本当に出たいセッションに出る

冒頭で YouTube で見れるとか書いたのですが、それでも生で見たいセッションはありますよね。 個人的なおすすめはやはりある程度ハイレベルなセッション。ハイレベルといいつつ、その分野の基本知識があれば十分ついていけるものが多いと思います。 かつ、グローバルでやっていっている会社の話を聞くのが良いのではないでしょうか。(今年も出てくれるのかわかりませんが) Netflix とか Airbnb とか。

とりあえず今から何をしたらいいか

どのようなセッションが開催されるのかという Session Catalog は実はもうすでに公開されています。で、予約開始が米国時間の 10/15 (火) です。日本では直前セミナーが10月末〜11月くらいに開催されたりしていますが、その頃には埋まっているセッションやワークショップも多いです。 というか、人気のあるセッション、ワークショップや GameDay, Security Jam などは瞬殺に近いくらいの勢いで予約枠がなくなります。一昨年あたりは予約開始と同時にアクセス殺到でサイトが落ちたりしていたくらい。

というわけで、いますぐ Session Catalog を眺めて、気になるセッションをチェックしておきましょう。その際、開催時間が重複しないか、と、ホテル移動の時間が考慮されているかをよく確認しましょう。

というのも、マップを見るとわかるのですが、re:Inventの会場はいくつかのホテルに分かれています。隣のホテルじゃん楽勝!みたいに思うこともあるかもしれませんが、ラスベガスのホテルは日本やアメリカ他地域のホテルと比べても異常に巨大で、カンファレンスが行われているエリアから表通りに出てくるまで徒歩15分、そこから隣のホテルの入り口まで徒歩10分、そこから… みたいなこともザラにあります。専用シャトルバスもありますが、バスを使ったとしても Keynote などが行われる Venetian から、いちばん端の MGM Grand まで移動するのに3,40分はみたほうが良いです。

説明を読む限り、今年はホテルごとのセッションテーマ (Security とか ML とか) は設定されず、あらゆるジャンルのイベントが全てのホテルで分散して行われるようなので、どのような動き方をするかがより重要になります。

参加するイベントを決めたら、あとは予約開始と同時に素早く予約するだけです!万一予約が溢れてしまったら、当日早めに並べば入れることもあります。

AWS 認定は持っておくと便利

re:Invent に行くにあたって、流石にまったく AWS わからん!という人はいないと思うのですが、もし不安があるなら AWS 認定試験を受けておくのがおすすめです。 AWS 認定 SA なら Associate レベルでも割と広い範囲のサービスをカバーしているので、たとえ自分の専門範囲外だったとしてもそれぞれのサービスにとっつきやすくなります。

それに加えて、認定を持っていると各ホテルに用意された Certificate Lounge が使えるという利点があります。re:Invent の会場を見渡すと、もちろんある程度の飲み物や電源などは確保されているもののやはり数は(人数に対して)少ないです。

その中で、Certificate Lounge では水やジュースなどの飲み物に加えてお菓子なども置いてあり、さらに電源がある席もちらほらあります。入れる人が絞られている分、電源を得られる可能性も高いです。

というわけで、色々な意味でお得なので、ぜひ出発前に取得しておくことをおすすめします。

おわりに

以上、re:Invent にはじめて、あるいは1,2回参加したけどあまり…な方に向けた、個人的なおすすめの動き方ガイドでした。 この他にも re:Invent には体を動かすアクティビティとか、チキン大食いとか、re:Play などのイベントがたくさんあります。ぜひ re:Invent のサイトをくまなくチェックしながら、自分にとって1000%楽しめる楽しみ方を見つけてみてください。

ご質問などありましたらお気軽に @kani_b まで!

MSPJ マイグレーションコンペティション2018winter で優勝してきた

ちょっと時間が経ってしまいましたが、2018/01/27 (土) に開催された MSPJ マイグレーションコンペティション2018winter に参加してきました。

日本MSP協会さんが主催しているイベントで、「古いシステムをいい感じに新しいものにマイグレーションする」コンペティションです。 2年ちょっと前に参加して負けて以来、また出たいなーと思っていたのですが、運良く日程が合い参加することができました。 今回は無事優勝することができました。引き続き開催していただきたいなあと思っておりますので、どういう感じだったかまとめたいと思います。

ルールとチーム

お題は変わらず「いま動いているシステムを新しい環境に移行して欲しい」です。 その他の条件を connpass から引用してみましょう。

- 要望的な何か
    - 今の環境を新しい環境に完全移行して欲しいです。
    - 実施した内容と結果については報告が欲しいです。
    - システムを止めるときは利用者に告知が必要なので連絡が欲しいです。
    - 昔から使っている古い環境なので、バージョンアップして欲しいです。
    - できれば利用者に影響を出さないように切り替えたいです。
    - できればサーバに関する資料があるとありがたいです。
    - できれば今はまったくバックアップを取っていないのでバックアップを取れるようにしたいです
    - できれば今後は利用者が増えるのでシステムを冗長化したいです。
    - できれば新しいインフラエンジニアに引継ぎするために必要な情報がまとまっていると嬉しいです。
- 担当者のコメント
    - 体制変更とかいろいろありまして、システムが分かる人がいなくなってしまいました。
    - 結構前から使っているので、いいタイミングなのでリフレッシュしたいなと思っています。
    - サイト上での商売は続いているので、できるだけ利用者さんに影響が少ないと嬉しいです。
    - そうそう、近々新しいインフラエンジニアが入社予定だから、その方に引き継げるようになっていると嬉しいですね。
    - 本当はいろいろとナウっぽいこともしていい感じにしていきたいんですよ。

これに沿うような問題が出題されます。

チームは当日ランダムなので、同僚と組んで出場!といったことはできないようになっています。 業界経験年数などをもとにチーム分けをしていくのですが、出場条件が30歳以下というところからもわかるようにかなり若く、28歳業界5年目の自分がチームでは最年長という形になりちょっと焦っていました。

Slack に運営との連絡用 channel ができており、そこを主に使うことになります。 短い時間で行うため、課題としていたことなどを忘れやすいため GitHub に private repo を作ってそこに課題を蓄積していくことなどもやっておきました。 基本的に ISUCON などと同様のコミュニケーションスタイルをやっておけばうまくいくと思います。 時間も前回と同じ 10:30 - 17:00 の6時間半。

お題

今回は EC-CUBE を中心とした EC サイトでした。 CentOS6 な Linux マシンの上に DB (MySQL 5.1) が同居しており、 Postfix, Dovecot といったメール環境が乗っていた点が厄介でした。

今回はこの環境がなんと AWS に乗っており、これを Azure に移行するという内容でした。Azure はほぼ使ったこともなかったので、適宜ドキュメントを参照しながらの戦いになりました。

開始して1時間くらいで内容を把握した上で設計を始めました。ここに時間をかけすぎた。。

設計

移行元も移行先もクラウドだし使えるサービスに特に制限はなさそう、かつ要求事項に色々夢のある話が書いてあれば、おれのかんがえたさいきょうのこうせい を作りたくなるものですが、 時間が限られておりあまり盛りすぎると時間が足りなくなることは目に見えていたのでぐっとこらえて最低限の要件を決め、その中で自然にできることを改善の対象として選びました。

  • CentOS6 を CentOS 7 に
    • epel, remi などの外部レポジトリには極力頼らない構成にする
  • ミドルウェア類のバージョンアップ
    • Apache 2.2 -> 2.4
    • MySQL 5.1 -> 5.7
      • MariaDB と悩んだけどソフトウェアのサポート状況を踏まえて MySQL にした
    • PHP 5.3 -> 5.4
      • できれば最新まで上げたかったけどちょっと厳しかった
    • Postfix, Dovecot など
  • 自動バックアップ

このあたりは達成したい事項として含めていました。

移行

メンバー間で担当を割り振り移行を進めました。それぞれ練度が高かったこともありお互い特定の作業を任せあえる状態になっていたのは良かったと思います。 自分は DB の移行などをやっていました。調べていくと root パスワードが運用の中で消失していたため (他のスクリプトに書いてあったらしいが。。) 、最初のメンテナンスは MySQL を skip-grants で再起動して root パスワードを回復するところから始まりました。

切り替えも当初はオンライン切り替えでいけるかな、と思っていましたが、作業時間や構成などを考えるとコストが高く、オンラインに拘って事故るよりはきっちりメンテウインドウを決めてその間で確実に移行しよう、ということで作業を進めました。 幸いにしてデータ量は多くなかったので mysqldump にかかる時間の見積もりをした上でまるごと移行することに。 このへんはざくざくやっていく。

システムの持ち主はあくまでお客さんですのでそれに留意して作業を進める必要があります。例えば以下のようなこと。

  • 予算
    • AWS で1サーバで動いてたシステムが Azure になった瞬間料金倍額になったらびっくりするよね
    • 実際聞いてみると予算状況は割と厳しく、サーバ自体を冗長化したり分割することはこの時点でいったん見送った
  • 使うサービス
    • RDS for MySQL 的なサービスは Azure だとまだ Preview だった
    • Preview でも使えるから選びたくなるけど、お客さんの環境に Preview 版のサービス突っ込むの厳しすぎる
      • 結構使ったチームは多かったらしい
  • お客さんの作業
    • 商品画像アップロードなどもあるサーバであることを考えると、移行漏れが発生するような要素は極力避けるべき
    • なので、変更が発生する業務 (商品作成, 設定やデザインの変更) を時間を決めて止めてもらった
  • 切り替え作業
    • なんのために、どのくらいの時間システムを止めるのか
    • どこにどんな影響があるのか
    • を明確に伝え、その中でやりきる

こんなことを考えつつ作業を進め、最終的に移行可能となったのは終了1時間前くらい。結構ギリギリでした。再起動耐性のチェックもここでやっておきました。 メンテ時間も無事狙い通りにおさまり、こちらでの確認とお客さんへの確認をしつつ問題なかったので旧環境を撤収 (料金がかかり続けるので地味に大事だと思った)。 あくまで環境は "後任に引き継がなければならない" のでドキュメントを早めに書き始めました。文書は Google Docs でそれぞれがーっと書き、最後に1人が体裁を整えるスタイル。

自動バックアップは間に合わないかな…と思っていたものの、Azure Backup が予想以上に素早く環境を作れるようになっていたため、こちらを使いました。

17時に Slack で最終的な資料を提出して終了。 懇親会で寿司などをいただきつつ結果発表があり、なんとか優勝をいただきました。

感想

第一回から運営の方も狙っているところではあると思いますが、「普段の業務でやっていること」を忠実に考えてやっていけば良い結果になるコンペティションなのだと思います。 ぱっと考えれば自明なことなんだけど、限られた時間やメンバー、予算でそれをちゃんとやっていくのは結構難しい。 さいきょうのアーキテクチャを競う会ではないというところは前回の敗戦から学んだ部分で、それを踏まえた方針がちゃんと機能して優勝まで持ってこれたという点はよかったなと思いました。

マネージャになって1年半が経ち、なかなか全力で手を動かし続けるというのも難しかったりするお年頃ということもあり、全力で1つのことに集中し続けられたのもこういう大会の良いところだと思います。良いトレーニングになりました。

環境の準備から参加チームからの問い合わせ対応まで、この大会の運営はたぶんめちゃくちゃ大変なんだろうなあと毎回思っているのですが、今回も非常にスムーズな運営で、余計なことに気を使わず楽しめました。運営いただいた日本 MSP 協会のみなさま、ありがとうございました。そろそろ出場条件的にも厳しくなるので、次回またぜひ出場して勝ち逃げとしたいなあと思う所存です。

いただいた賞金でとりあえず Anova を買いました。何も考えず温玉のせローストビーフ丼が作れておいしいです。

運営、参加者のみなさま、チームメイトの id:renjikari さんと okazaki さん、ありがとうございました。次回以降もぜひよろしくおねがいします。

2017年ふりかえりと2018年

気づけば社会人5年目になっていて、もうすぐ6年目に突入します。 これまで振り返り的なことはあまり書いていなかったのだけど、 なんとなく書くことにしました。

2017年ふりかえり

仕事

1年半前にマネージャーになり、2017年ははじめて自分がマネージャーの状態で1年を過ごすことになりました。 マネージャーとして自分がどうなのか、という自己評価をすることは色々な意味で難しいと思うのですが、部のメンバーが楽しく胸を張れる仕事に取り組めるようにやるべきことを全部やる、という部分については少しだけできるようになってきたのかなと思います。

部署がけっこうなサイズで、SRE やセキュリティだけではなく社内システムやデータ基盤も扱っています。コンテキストを切り替えながら仕事をするのは結構たいへんということもありますが、それ以上に社内システムやデータ基盤のレイヤには、SRE やセキュリティの分野だけで仕事をしていたら出会わなかったであろう話がたくさん転がっていました。オフィス設備や社内ネットワークにはじまり、ERP の話とか、CRM, SFA とか、そのデータ連携とか。もちろんそれぞれの知識が必要になることもそうなのですが、意外といわゆる Web 系では普通となりつつあるようなことを適用できる部分もあったり、難しく、また面白くとても勉強にもなりました。

エンジニアとして特に大きい仕事はサービスの完全 HTTPS 化でしょうか。仕込みは2016年以前から、変更自体は2017年が明けてすぐに完了したのですが、SRE Tech Talks#2Chrome Tech Talk Night#9 , 大規模HTTPS導入Night などに呼んでいただきました。 会社の技術ブログ記事 を書いたところで技術評論社さまからお声がけをいただき、WEB+DB PRESS Vol.100に完全 HTTPS 化に記事を書いた こともとても良い経験でした。 記事を書いて以降、多くのサービスの完全 HTTPS 化に関する記事を見ることになり、また自分が紹介していた手法が使われていたりするのを見るのはかなり嬉しかったです。 2017年初頭から2017年末にかけて、日本の (Chrome を使った) HTTPS トラフィックは約30%から約60%まで増加したようです。Chrome の仕様変更などが一番大きな材料であったとは思いますし、各社数年単位で時間をかけて実行してきたような話ですが、もしこの30%の中のわずかにでも貢献できていたならすごく嬉しいことだなあと思います。実際のところはわかりませんが…

対外発表という点では、去年に引き続き AWS Summit Tokyo 2017 に登壇したことからオファーをいただき、なんと AWS re:Invent 2017で登壇することになりました。re:Invent に参加するのは5回目ですが、人生初の英語 + 海外での発表をまさかこの場ですることになるとは思いませんでした。英語の訓練をかなり高密度でする必要にも迫られて、本番もそうですが準備段階から大変良い経験になりました。

他にも SREcon17 Americas に参加したり、 Hardening 1010 Cash Flowに出場 (スポンサー賞をいただきました) するなど社外に出るようにしたおかげか、自分の中で数年前とまったく考え方が変わったようなこと、あるいは参考事例がなくて不安だったことに自信がつく経験などが多くありました。

総じて、2017年もとても楽しくお仕事できたなあと思います。

趣味

ブログのタイトルにもするくらいスキューバダイビングが趣味だったのですが、今まで沖縄の海に潜ったことがなくて、 Hardening で沖縄出張するついでに初めて潜ってきました。 学生時代からよく潜っていた八丈島ともよく比較されるのですが、ベクトルが違うきれいさだなーと思います。 学生時代から水中では10年前くらいのふるーいコンデジを使っていたのですが、沖縄に潜ってからすぐに GoPro Hero5 を買いました。水中で何度か使いましたが、動画だけでなくちゃんと写真も撮れます。色々やってついに JMB サファイアに到達したこともあり、あまり行ってなかったエリアに潜りに行こうと思います。

f:id:kani_b:20170912113432j:plain

f:id:kani_b:20180104233135p:plain

会社にサバゲー部が誕生し、前から興味があったので行ってみたところ非常に面白くてこれも相当な趣味になりました。1年前は装備も何もなかったのですが、今では Amazonサバゲー用品ばかりおすすめされるようになりました。朝から車で千葉まで行って一日遊び、帰りに温泉に寄って焼肉食べて帰ってくるとパーフェクト休日完成という感じです。

ゲームは PS4 Pro と PSVR を手に入れてエースコンバット7がいつ出ても大丈夫になりました。ニーアオートマタとスパロボV、Farpoint、海賊無双3 あたりが特によかったなと思います。ミニスーファミが出てから深夜にちょっとずつスーパーマリオ RPG をやれたのもよかったし、 Switch も年末ついに買えた。満足な2017年でした。

2018年

去年はマネージャー業をきちんとこなすのに精一杯だった感が否めないのだけど、少し塩梅もわかってきた部分もあり、現状の動き方をよりよくしながら技術的な取り組みを増やしたいと思っています。 自分が考える理想の SRE やセキュリティに携わるエンジニアを体現できるくらいになりたいなあと思いつつ、できないことややりたくても手がついていないこともたくさんあり、まあ修行していくしかないなという気持ちです。

趣味のほうは引き続きという感じですが、30台も見えてきたのでそろそろ体をいい感じにする努力をします。。。サバゲーのためにも体力と筋力のためのトレーニングをどうにかしてちゃんと続けたい。

そんなわけで今年も楽しく過ごせればと思います。どうぞよろしくおねがいします。

AWS NLB についてあれこれ

AWS ELB (ALB, CLB) には日頃からだいぶお世話になっているわけですが、新しい Network Load Balancer (NLB) がリリースされましたね。

新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング | Amazon Web Services ブログ

雑に言えば CLB TCP モードの次世代版というとこですかね。 ざっくりドキュメントを読みつつ、いくつか気になる点があったのでまとめます。 ドキュメントに記載されていない内容は私が検証した内容です。何か間違いがあればお気軽にご指摘ください。

パケットはどのように流れるのか

一応図にしておきます。なんというか懐かしい (とか言ったら怒られそうな) 流れですね。 ALB や CLB (HTTP, TCP 両方) ではロードバランサがそれぞれの通信を終端していわゆるプロキシのような役割を果たしているのと比較すると、NLB はパケットの送信元/宛先アドレスを書き換えるのみに見えます。LVS の NAT モードと同様の挙動というところでしょうか。あくまで戻りのパケットは NLB に送出されておりいわゆる DSR ではないように見えます。

f:id:kani_b:20170920130201p:plain

internet-facing と internal の違い

基本的に ALB と変わりありません。

internet-facing

  • 起動する AZ および subnet を選ぶ
    • subnet には IGW が attach されている必要がある (いわゆる public)
  • DNS name が割り振られる
    • 返すのは各 AZ ごとに起動時に払い出された public IP もしくは起動時に追加した EIP
  • バックエンドインスタンスは private subnet に所属していても問題ないが、VPC Route Table においてデフォルトルート (0.0.0.0/0) が設定されている必要がある

internal

  • 起動する AZ および subnet を選ぶ
    • subnet に IGW, NAT Gateway などが attach されている必要はない
  • DNS name が割り振られる
    • 返すのは各 AZ ごとにランダム (DHCP?) に割り振られたプライベート IP アドレス

NLB が返す IP アドレスについて

NLB は1つの AZ につき1つのIPアドレスを持ち、それぞれの IP アドレスへのトラフィックは必ずその AZ にルーティングされます。 例えば AZ-A に 10.0.0.0/24, AZ-B に 10.0.1.0/24 の subnet を作成して設定し、A,B それぞれの AZ にまたがる NLB を作成したとすると、DNS が返す IP アドレスは以下それぞれ2つになります。

  • internet-facing
    • xxx.xxx.xxx.xxx (AZ-A 用 public IP / EIP)
    • yyy.yyy.yyy.yyy (AZ-B 用 public IP / EIP)
    • バックエンドへのヘルスチェックにはプライベート IP アドレスが適当に切り出されて使われる
  • internal
    • 10.0.0.x (AZ-A の subnet から切り出した IP)
    • 10.0.1.y (AZ-B の subnet から切り出した IP)
    • ヘルスチェック元 IP アドレスは同じ

クライアントはどちらかを選択して通信を行うことになりますが、その際選択した IP アドレスが所属している subnet と必ず通信を行うことになるわけです。例えば xxx.xxx.xxx.xxx にパケットを送出した際、それが AZ-B のバックエンドインスタンスにルーティングされることはありません。 これが NLB のリリース紹介記事にも書いてある Zonality ってことですね。

Zonality って結局どういうことなのか

先述の通り NLB から見える IP アドレスは必ず1 AZ に紐付きます。 2AZ に NLB をアタッチした状態で DNS を引いてみると必ず2つの IP アドレスが返ってきます。よって、例えば以下のように Web - App - DB のような構成にした際の接続にすべて NLB を使っている構成であれば、先頭の NLB が Zonal であっても後半の NLB で他の AZ にバランスされてしまうように見えます。

f:id:kani_b:20170920130236p:plain

これはあくまでクライアントの実装による話です。 例えば glibc の getaddrinfo(3) は RFC 3484 Rule 9 によって定義されているように、複数の IP アドレスが返された際は longest match によって IP アドレスをソートして返します。上記の図のように、それぞれのインスタンスが同じ Subnet に存在する (= NLB が同じ Subnet にある) 場合、 getaddrinfo(3) を使っているクライアントでは、同じ Subnet, 同じ AZ の NLB エンドポイントが使われるようになります。 *1

Redis や memcached をはじめとした低遅延なデータストアを利用する際には AZ またぎのレイテンシが地味に効いてくるケースがあるため、NLB と Subnet が1対1になっていることは役に立ちそうです。 NLB を利用することで、普段は同じ AZ のインスタンスに接続しつつ、AZ が全滅した際には別の AZ に接続することができます。 ただし、この挙動はあくまでクライアントに依存するものであるため、上記のような挙動をしない場合にはクライアント側での対応が必要ですし、Subnet をまたぐようなケースでもクライアント側での対応が必要です。 また、AZ 間のバランスは接続元/接続先インスタンス共に適切に保たなければ、均衡が崩れて負荷が偏ってしまうことには注意が必要ですね。

障害時に使われる IP アドレス

IP アドレスと AZ が紐付いているので、例えば AZ-B のバックエンドインスタンスが全滅したしまった際に yyy.yyy.yyy.yyy あるいは 10.0.1.y をクライアントが選択すると、どのバックエンドインスタンスにもルーティングされないことになってしまいます。 ざっと実験した感じ、NLB では以下のような挙動をするようでした。(internet-facing, internal 共通)

  • 全ての AZ に healthy なバックエンドインスタンスが存在する場合、全 AZ の IP アドレスを返す
  • healthy なバックエンドインスタンスがいない AZ が1つ以上存在する場合、その AZ を抜いた IP アドレス (上記の例だと xxx.xxx.xxx.xxx) のみを返す
  • 全ての AZ でバックエンドインスタンスが全滅した場合、全 AZ の IP アドレスを返す

よって、片方の AZ が全滅するような障害においても、DNS name をベースとして (IP アドレスを直接べた書きなどせず) クライアントが接続しようとする場合、全滅した AZ に接続しようとしてタイムアウト…といったことにはならないようです。Route53 の Alias Record にも対応しており、こちらを設定した場合でも同様の挙動をします。 NLB 自体の IP アドレスは固定ですが、複数 AZ を利用する際に複数ある IP アドレスをそのままドメインの A レコードとして設定してしまうと、AZ が全滅した際でもクライアントが接続できない AZ の IP アドレスを使ってしまうリスクが残ることになります。 そのような設定をする場合は Route53 の Healthcheck および Failover 機能 (もしくは他社 DNS における同様の機能) を一緒に使うことになるでしょう。 Active/Active な状態にしておくことで、 NLB の DNS レコードと同じような挙動を実現できそうです。

セキュリティグループについて

NLB そのものにはセキュリティグループを設定できません。バックエンドインスタンスにおいてセキュリティグループを設定する必要があります。 バックエンドインスタンスには送信元 IP アドレスがクライアントのままになっているパケットが届きますので、これをベースにして設定をする必要があります。 インターネットに公開する場合、ターゲットとなるポートは 0.0.0.0/0 からのアクセスを許可、ヘルスチェック用ポートは NLB が起動している subnet の CIDR からのアクセスを許可すれば良いでしょう。

internet-facing な NLB を使う場合、クライアントからバックエンドインスタンスへの直接アクセスを許可する必要がある?

という書き込みをちらほら見かけましたが、答えはNOです。 バックエンドインスタンスがクライアント (インターネット) からの直接アクセスを受けるためには以下の3条件が揃っている必要があります。

  • バックエンドインスタンスが所属する subnet に IGW が attach されている
  • バックエンドインスタンスに public IP もしくは EIP が割り振られている
  • バックエンドインスタンスが所属するセキュリティグループに適切な許可設定 (e.g. 80/tcp に 0.0.0.0/0 からのアクセスを許可) がされている

NLB のバックエンドインスタンスとなるためには、このうち最後の条件のみを満たしていれば良いです。 (上述の通り、 VPC Route Table においてデフォルトルート (0.0.0.0/0) が設定されている必要はあります)
よって、例えば以下のように NLB は public subnet に起動し、private subnet のインスタンストラフィックを流す (インターネットからのトラフィックは NLB のみで受ける) といった構成も問題なく行えることになります。

f:id:kani_b:20170920130251p:plain

ただし、internal においてもセキュリティグループが利用できないという制約は変わりません。つまり、バックエンドインスタンスのセキュリティグループにクライアントインスタンスのセキュリティグループを許可設定してもアクセスができません。 細かい制御を求められるところではちょっと不便ですね。

まとめ

NLB の挙動や存在する制約などについてまとめました。 アクセス制御の点で少し面倒な部分はあるものの、ALB や CLB と比較してもより普通に (X-F-F や Proxy Protocol などを考慮せず) 使え、かつ IP 固定なのは便利だなと思います。あと起動がめっちゃ早いです。 Zonality もクライアント依存な部分はありますが個人的には便利 (欲を言えばクロス AZ と選びたい) だなと思いました。 ALB で受けられない, もしくは不便なユースケースは NLB を積極的に使うと便利そう。

Simple Icons の更新もお待ちしてます!!!

*1:気になる方は glibc の getaddrinfo.c あたりを読んでみると雰囲気がわかると思います

WEB+DB PRESS Vol.100 特集「対応必須!完全HTTPS化」を執筆しました

2017年8月24日発売の WEB+DB PRESS Vol.100 に「対応必須!完全HTTPS化 - 移行手順からつまずくポイントまで」という特集記事を執筆しました。 この特集は、2017年4月に会社の技術ブログに執筆した Web サービスの完全 HTTPS 化 - クックパッド開発者ブログ という記事をベースに、中身をほぼ新規に執筆したものです。

2017年1月にクックパッドという Web サービスを完全 HTTPS 化したので、その経験を4月にブログ記事という形で公開したのですが、これをご覧になった編集部の方からご連絡をいただき今回の話に繋がりました。

WEB+DB PRESS は8年くらい前、本格的に Web 技術者を目指そうかなと思い始めた学生の頃から時折読んでおり、私にとってもかなり身近な雑誌です。しかし執筆はというとVol.92 でちょこーーっとだけ Fluentd によるログ収集話執筆のお手伝いをしたくらいで、ほぼ初執筆に近いです。

特集について

章構成はこんな感じです。全25ページ。

  • 第1章: なぜ完全 HTTPS 化が必要なのか
    • Web サービスを安心して利用してもらうために
  • 第2章: 完全 HTTPS 化はじめの一歩
    • 証明書の選び方、構成の検討、テスト環境の構築
  • 第3章: HTTP リソースの HTTPS
    • mixed content を効率的に修正するには
  • 第4章: リリース時に注意すべきこと
    • 確認すべき事項と、ミスを防ぐリリースの順序
  • 第5章: クックパッド完全 HTTPS 化の影響
    • 収益、ユーザー、パフォーマンスはどう変わったか

クックパッドにおける完全 HTTPS 化をの経験をベースに、Web サービスを完全 HTTPS 化する方法について、その前提知識などから解説しました。 主に AWS を使った環境の話をメインに書いていますが、今回pixivさんに許可をいただき、コラムという形でオンプレミス環境における完全 HTTPS 化についても執筆させていただきました。 コラムなど含め記事全体を私一人で執筆しています。

HTTPS に対して思うこと

「今の時代、新しいサービスは HTTPS であることが多いし、これから解説する必要もないのでは?」と思う方もいらっしゃる方もいるかもしれません。僕も執筆のお話をいただいた時に正直少し思いました。 が、やはりインターネット全体を見渡してみると、まだ十分とは言えない状態にあると思います。 Google が公開しているレポート でも、日本は最下位 (もちろん取り上げられている範囲でですが) です。

記事でも書いていますが、HTTPS への移行はもはや Web サービスにとって避けられないでしょう。利用者の安心や安全を守るということに加えて、これから使われるであろう新しくて面白い技術の多くは HTTPS をその前提としています。 HTTPS への移行メリットがセキュリティだけであった時代はとうに終わりました。みんながもっと楽しくて、安全な次の Web に行くためにも、HTTPS への移行は必要です。

また同時に、それはトラフィックの大小で決まるものではないと思います。「うちのサービスはトラフィックも少ないし、別に良いかな」と感じる方もいらっしゃるとは思いますが、そのサービスのユーザーも"インターネットユーザー"の一人です。 利用者が安全であることを確認しながら使うリテラシーも必要なのかもしれませんが、最低限"利用するどのサービスも HTTPS になっている"状態を作ることで、インターネットを使うために知らなければならないことをわずかでも減らせるんじゃないかなと思います。

執筆について

執筆は、編集の方と GitHub の上で行いました。既に markdown を使った快適な執筆環境ができており、執筆の上で不自由は全くありませんでした。これは本当にすごいなと思います。
進捗が悪い時期も適切にフォローいただき、その後の校正や本当に最後の最後まで修正を一緒に進めていただいた編集部の池田さんには本当に感謝しております。

また、執筆にあたり職場のみなさんや Jxck さん, catatsuy さん にもレビューをいただきました。貴重なレビューをいただき (また catatsuy さんにはブログ記事2本 前編 後編 のコラム化についても快諾いただき) 本当に助かりました。

おわりに

HTTPS というプロトコルの説明や証明書についての解説に加え、 CSP や HTTP/2, TLS1.3 など次世代の技術にも触れています。あまり下手なこと書くと槍が飛んできそうだな 😇 などと思いつつ、気をつけて書いてはいるつもりですが、なにぶん奥深い世界ですので、お気づきの点があれば温かい目でご指摘いただければなと思います。

完全 HTTPS 化について、何がボトルネックになっているかは各サービスによって当然違います。そもそも必要性が認識されていないかもしれないし、担当者は完全 HTTPS 化したいと思っていてもリソースの問題で動けないかもしれない。あるいは技術的な問題や心配で先に進めていないかもしれない。 1 しかし、かつて考慮すべきだったことの多くは現代では心配する必要がなくなっています。もちろんケースによりますが、多くの場合そんなに難しくはない、のだと思います。

本特集は、実際の構成や設定にとどまらず、同僚や上司への説明などにも利用できるよう、できる限り使いやすく書いてみたつもりです。 特集をご覧いただいて完全 HTTPS 化に進めた、なんていう声をもし聞けたなら嬉しい限りです。

記念号となる Vol.100 には、私の特集のほかにもとても面白い特集やエッセイがたくさん掲載されています。本日献本いただいた書籍を読みましたが、とてもおすすめです。 完全 HTTPS 化に興味があってもなくても、ぜひお買い求めください!


  1. このブログが HTTPS ではないのでは、というお声もあるでしょう。しかしはてなブログHTTPS 化も進んでいると伺っており、またユーザーが記事などを自由に書けるようなサービスにおける完全 HTTPS 化は難易度がかなり高いと思っていますので、気長に待つことにしています :)

MacBook (12-inch) で給電しながら 4K 60Hz 出力したい

タイトル通りの話。 仕事では持ち歩き用に MacBook (12-inch) を使っています。軽くて薄いので持ち運びには最高。

最近自宅に PS4 Pro を買ったので、思い切ってモニタを4Kに統一しました。フィリップスの31.5インチのやつ です。 で、この 4K モニタに MacBook を繋ごうとするわけです。Apple のサポートページを見てみましょう。
Mac で 4K ディスプレイ、5K ディスプレイ、Ultra HD TV を使う - Apple サポート

一見問題なく対応していそうなのですが、重要なのはリフレッシュレート。 HDMI 接続の場合ほぼ 30Hz にしか対応していない。個人的には 30Hz でモニタ使うのは無理。目が痛くなります。 というわけで、快適に 4K モニタを使うためには 60Hz で使う必要があります。 4K モニタを 60Hz で使うためには、以下の方法で出力する必要があります。

  • Displayport 1.2 (以下 DP)
  • HDMI 2.0

PC 向けでこれ以外の規格で使えるものは無いと思います。 しかし、世の中の 4K 対応製品は実際には HDMI1.4b までしか対応していないものがほとんどのため、期待して使うと 30Hz までしか出力されないことになります。 やっかいなのは、Mac 内蔵ポートはもちろんのこと、Apple から出てるいかなるアダプタでさえもまだ HDMI1.4b しか出力できないということです。

mini DP から DP への変換アダプタはサードパーティから数多くリリースされていますので、mini DP があった頃の MacBook をお使いのみなさんは 迷わずこれを使えば良いです。 問題はこのポートが全て USB-C という (現状) 地獄のポートに置き換えられてしまった新 MacBook たちです。 Apple は現状 USB-C から HDMI 出力できるアダプタをリリースしてはいますが、残念ながら前述のようにこの HDMI は HDMI1.4b なのです。よって 30Hz 止まりです。 Apple 純正, あるいは公式アナウンスしているアクセサリのみで 4K 60Hz を使いたいなら LG UltraFine 系の USB-C 対応モニタを買うしかないのです。マジか〜

さて、USB-C から DP あるいは HDMI2.0 を出力する方法について。 DP で出力するなら、USB-C から DP への変換ケーブルがありますので、これを使うと一発です。 HDMI2.0 はいくつかアダプタが出ています (必ず HDMI2.0 と明記されたアダプタを買いましょう) が、アダプタに加えて HDMI ケーブルも Premium HDMI ケーブルという 認証を通ったケーブルでないといけません。これが結構高くて、1mでも4000円くらいします。 USB-C to DP ケーブルを買うのが一番だと思います。

これでめでたしかと思いきや、 MacBook (12-inch) は最高に薄くてクールなので USB-C ポートが1つしかありません。 給電もこのポートから行うわけですので、前述のケーブルやアダプタを使うと給電できなくなってしまいます。

これを知ってから必死に探して、ついに使えるものを見つけました。それがこちら。

HyperDrive USB Type-C Hub with Mini DisplayPort (for 2016 MacBook Pro & 12" MacBook)www.hypershop.com

HyperJuice (バッテリ) とかも出してる Sanho のプロダクト。 USB-C 一つから給電可能な USB-C, miniDP, microSD, USB2.0 な USB-A を2つ出すことができます。 利用中の画像は以下です (画面きたないのは許して) 。

書いている通り、コネクタが少し浮いてたりそもそも USB-C コネクタ一つで支えるという構造がかなり不安ではありますが デスク上で固定して使う分には全く問題ないです。 使い始めてから1ヶ月くらい経ちますがまったく問題なし。 価格は送料込みで$60~70くらいだったと思います。(売り切れ中のため確認できず)

これで今のところ快適に 4K モニタを利用できています。執筆現在で売り切れ中ですが、興味のある方は登録して入荷を待ちましょう。 ただ、MacBook 自体のスペックが低い & 2015年モデルのためか、4K 出力しているとそもそも CPU を 20~30% 持っていかれてしまっているのが 結構つらいです。WWDC 2017 で新しいモデルが出たりして良い感じになるといいな。