「DevOps 先駆者 Mitchell Hashimoto との Meetup」の参加ログ

DevOps 先駆者 Mitchell Hashimoto との Meetup」に参加しました。

もともとは単なる「参加枠」で登録していたのですが、抽選に漏れてしまったので「Blogger 枠」で登録しなおして、イベントに参加をしました。そういう経緯で、まさに今、ブログを書いています。

どのようなイベントであったか?

いわゆる「ユーザー向けイベント」であるように感じました。ほとんどの参加者が HashiCorp プロダクトの使用者であったし、Mitchell Hashimoto 氏のプレゼンに関する質疑応答も、「HashiCorp の xx を使っているのですが…」ではじまるものが大多数でした。

hashicorp-1

どのようなプレゼンテーションであったか?

Mitchell Hashimoto 氏がプレゼンテーションの冒頭で “「HashiConf 2017」のサマリ的な内容” である、と言っていました。実際、何か新発表があったわけではなく、ある程度 HashiCorp の動向を追っている人なら聞き覚えのある内容がほとんどであったように思います。

話があったのは次の 6 つのプロダクトについてです。

  • Vagrant
  • Vault
  • Nomad
  • Packer
  • Consul
  • Terraform

hashicorp-2

時間的な制約もあり、それぞれのアップデートについて詳細に説明するというよりは、新機能について簡潔に述べることに終止していたように思います。

僕が個人的に面白いと感じたのは「Terraform Registry」と「Sentinel」です。

Terraform Registry は雑に言うと Terraform Module をシェアする仕組みで、Sentinel はポリシをコードの形で記述する仕組みです。

Terraform Registry を使うことで、「ありがちな」モジュールを再利用することができます。また、モジュールには「Verified Module」とされているものもあります。これは Hashicorp のメンバーによるレビューを経た「安心して使える」モジュールだという扱いです。質疑応答によると、Verified Module は「コードレベルでチェックしている」とのことです。

また Sentinel は “Policy as Code” を標榜しており、例えば次のようなポリシをコードで記述できるものです。

  • 営業時間外には構成変更 (e.g. terraform apply) させない。
  • 2048 ビット未満の鍵長の TLS 証明書は許可しない。
  • タグ付けされていない AWS インスタンスは許可しない。

例えば Terraform などでインフラの構成管理をするとき、コードレビューだけでポリシがきちんと守られていることを担保するのは困難です。Sentinel を使うことで、組織内のポリシの遵守がぐっと簡単になるのは確かだろうと思いました。

まとめ

HashiCorp は相変わらず勢いのある会社だなあと感じました。製品によっては強力な競合がいて (たとえば Nomad に対する Kubernetes) 苦戦することもあるだろうと思う一方で、ベンダー中立なことを活かした AWS や GCP のどちらもサポートする製品の開発であったり、 Consul に代表されるようなスケーラブルなミドルウェアの開発においては、他の追随を許さない魅力的な立ち位置にいるなあと改めて思いました。

Route 53 で Zone Apex を ELB に振り向けるときの設定

僕は mahata.org というドメインを所持している。

mahata.org のウェブサーバは ELB の背後にあり、mahata.org を名前解決した結果はこの ELB を指してほしい。これを実現するため AWS 固有の知識が必要だったので、後々のためにメモを残しておく。

直面した課題

Zone Apex とは「サブドメインを含まないドメイン名」を示す言葉である。例えば “www.mahata.org” は Zone Apex ではなく、 “mahata.org” は Zone Apex だ。

Amazon Route 53 では Zone Apex に対して CNAME の設定が許可されていない。mahata.org を ELB の CNAME にしたかったんだけど…。ELB の IP アドレスは動的に変わるので、mahata.org の A レコードを設定するのは筋が悪い。

さあ、どうしよう。

CNAME レコード以外の選択肢

少しぐぐった結果、Amazon Route 53 では ALIAS レコードという DNS レコードを設定できることがわかった。リンク先のオフィシャルドキュメントでは、CNAME レコードとの比較の中で「エイリアスリソースレコードセットは Zone Apex に作成できます」と明記されている。

これを使えばよさそうだ。

ALIAS レコードの設定

ALIAS レコードは限られた AWS リソースにしか設定できない。例えば ELB や CloudFront ディストリビューションなどが「限られた AWS リソース」である。

対象となる AWS リソースによってレコードの設定方法は少しずつ異なる。ALIAS レコードで ELB を指す場合は DNS 値の先頭に dualstack. を付ける。例えば dualstack.elb-example-0000000000.ap-northeast-1.elb.amazonaws.com. のような感じ。

具体的には Amazon Route 53 のコントロールパネルで次のようにする。

  1. Create Record Set をクリックする
  2. “Type: A” で “Alias” は “Yes” にチェックを入れる
  3. “Alias Target” に dualstack.elb-example-0000000000.ap-northeast-1.elb.amazonaws.com. のような値をセットする

これで Zone Apex が ELB を指せるようになる。

書評 – 勝ち続ける意志力

プロゲーマーの梅原大吾さんによる『勝ち続ける意志力』を読んだ。

「ニッチな層に向けたマニアックな本だろう」と予想しつつ手に取ったが、よい意味で想像が裏切られた。プロゲーマーとして「勝ち続ける」ために彼が考え抜いたことは、僕を含む多くの「一般人」にも糧になる内容であった。

安易でない道の選択

セオリーを追い続けることでは超えられない壁がある。本書には「10 の実力を超えて、11、12、13 という実力を身につけた人は強い。そのレベルの強さは説明がつかない。だから、それは簡単に真似できるものではない」とある。セオリーを追わず、ひとつずつの可能性を自ら検証して、その領域にたどりつけるのだろう。たとえば僕が、ゲームの攻略サイトなどを眺めながら「強い」とされるコンビネーションを覚えればそれなりに勝てるようにはなるだろう。でも、同じコンビネーションを「なぜそれが強いのか」を肌で理解した上で繰り出してくる相手には勝てないだろう。上っ面をなぞるようではいけない。

とはいえ、「10 を超えた実力」は一朝一夕に身につくものではない。彼は「一日に少しでも (よい方向に) 変化できればよい。その積み重ねが実力になる」と書いている。そして、「変化する」ために方法として「苦手な人とつきあってみる」ことを挙げている。自分にはない発想だったが、たしかに自分とは合わない人間と時間をともにすることは、自分を変化させるために効率のよい手段だと思う。楽な道ではないが…。

目標と目的

本書の後半では「努力は持続可能でなければならない」という主張が強くなる。一夜漬けのような努力ではいけない、ということだ。彼自身、ある大会に向けて練習をし過ぎて、体調を悪くしたことがあるらしい。その結果、大会では散々な成績に終わったそうだ。今では休憩も練習の一部だと捉えているらしい。

いくつか、努力を継続するための具体的な tips も書かれている。

たとえば、「勝って天狗にならず、負けてなお卑屈にならない」くらいが勝負にかける意気込みとしてはちょうどいい、と書いている。また、別な言葉では「大会に勝って100の喜びを得ようとは思わない。それよりも、日々の練習において60の喜びを得たいと思う」とも言っている。つまり、日々の練習などで自身の成長を感じ続けることの方が、大一番の勝負に全精力を傾けるよりも健全だという主張だ。彼がいうには、そういう心持ちで臨んだ大会の方が、むしろ勝率は高いとのことだ。

分かるような気がする。

勝負事は常に運の要素が絡んでくる。いくら入念に準備をしても、ダメなときはダメなものだ。ダメなときに消沈しても意味がない。運に振り回されず、たんたんと日々の練習に充実感を求める方が、努力としては持続可能なものになるだろうし、ひいては勝率にも貢献するだろう。この考え方は積極的に取り入れていきたい。

まとめ

人気があるゲームのプレイヤは「ガチ勢」と「エンジョイ勢」に分けられることが多い。前者は競技としてのゲームを楽しむ人たちで、後者は娯楽としてのゲームを楽しむ人たちだ。僕がゲームをするときは、たいていの場合は「エンジョイ勢」としてプレイする。梅原さんとは対局にいる人間だ。

「ガチ勢」の中でも「ガチのガチ勢」である梅原さんの言葉は重い。最近はゲームを「e-スポーツ」と表現することもあるが、まさにアスリートのような態度でゲームに臨んでいる。

この本は、アスリートとしての梅原さんの金言が散りばめられていて、読んでいてかなり心を揺さぶられた。手に取ろうか迷っている人がいたら、ぜひ背中を押してあげたい。そのくらい、気に入った本のひとつだ。

連結リストが回文か調べる方法

世界で闘うプログラミング力を鍛える150問』から、回文に関する問題を解いていこう。

回文チェッカー

連結リストが回文 (先頭から巡回しても末尾から巡回しても、各ノードの要素がまったくおなじになっている) かどうかを調べる関数を実装してください。 (P.195)

この問題は「リストのサイズがあらかじめ分かっているかどうか」で難易度が変わる。サイズが分かっている場合、プログラムは簡潔になる。

(リストのサイズがあらかじめ分かっている場合の) 回文チェッカー

次のような方針で解ける。

  1. リストを先頭から順に半分まで読み込み、値をひとつずつスタックに詰める (リストのサイズが分かるから、「半分まで」が分かる)
  2. リストの半分より後と、「1.」のスタックをひとつずつポップしていった値を比較する

スタックは FILO (First-In, Last-Out) なので、最初に格納した値が最後に取り出される。つまり、「1.」で作ったスタックは、ポップするたびにリストの真ん中からひとつずつ先頭に向かって値を返すようになる。

実装

先の記述を素直に実装しただけのものだ。コメントも多めにつけたので、容易に理解できるだろう。

集中力を高める方法

最近、集中して勉強することが難しくなってきたので、対策を考えたい。

集中が切れる要因をいくつか洗い出してみよう。

  1. 誰かに割り込まれる (声をかけられる)
  2. 注意をそらす娯楽に手が伸びる (ネットニュースやテレビゲームなど)
  3. 生理的な欲求に襲われる (空腹、喉の渇き、眠気、トイレなど)
  4. 集中して取り組む対象が難しすぎる

こんなところかな。

楽に対応できそうなのは 3. だろうか。単に生活習慣が正されていればいいだけな気がする。

他は工夫が必要そうだ。1. は物理的に知人のいない場所に行けばいいと思う。喫茶店とか。ただ、それだけでは不十分で、LINE なんかから通知がピコピコ入ってくるのも十分に集中力を奪う。積極的にオフラインになるのがいい。最近は So-Net の 0 sim カードを使っていて容量制限がきびしいので、通常時はモバイルネットワークを切るようにしている。PC も Kindle や PDF をあらかじめダウンロードしておいて、なるべくオフラインにしている。

オフラインを常態ににすると他にもいいことがあって、ネットニュースからも距離を置くことができる。これで 2. も解決だ。

難しいのは 4. だと思う。勉強する内容は「理解していないことだけど、ぐっとがんばって考え続ければ理解できる」くらいが望ましい。内容が理解できないときに、考え続けるべきなのか、もっと簡単なテキストにスイッチするべきか判断するのは難しい。でも、時間をたっぷりかけても「新しいことを理解できている」実感がないと、やっぱり集中はそこで切れてしまう。

何か勉強したいときは、既にその道を極めている人に意見を求めるのがよさそうだ。「段階を追って理解したいのだが…」と言えば、どういう順で何を勉強をするべきかアドバイスをもらえるだろう。身の丈にあった内容を学習することで、集中力を保とう。

がんばろう。

価値のあるレビュー

近所の図書館に「ソーシャルもうええねん」が置いてあったので読んでみた。

色んな話があったんだけど、口コミサイトのさくらについて言及している項が面白かった。いわく、「お金を払って口コミサイトに好意的なレビューを書いてもらうことは可能である。人為的に口コミを作り出すことに憤りを覚えた時期もあったけど、口コミを作ることに予算をさけるお店というのは、概してクオリティも高いことに気づいた」とのことだ。確かにそういうものかもしれんなー、って思った。

ところで、Amazon なんかの 1~5 個の星で商品をレビューさせるやり方って筋がよくないなーと思う。極端なレビューにひっぱられて平均値が歪んじゃうし、せめて中央値とかにしてくれればいいのに。食べログみたいなレストランを評価する仕組みでも、「その料理を食べた人の何割がリピーターになっているか」だけ分かればよくて、どのくらい星がついているかなんて情報はどうでもいいんじゃないか、って思う。

職場に求めるもの

採用面接をするときに必ず尋ねる質問がいくつかある。その内の一つが「あなたが職場に求めるものは何ですか?」だ。候補者が職場に求めているものと、僕たちが候補者に与えられるものが近ければ近いほど、候補者が僕らの職場にマッチする確率が高いというわけだ。

ふと、自分も職場に何を求めているかまとめておきたい気持ちになった。自分が転職したくなったとき、もしくは職場を自分好みに変えたいときに参考にできるように。

仕事道具に対する要求

  • 仕事に差し障りのないスペックのコンピュータが支給されること
  • ネットワーク回線に十分な帯域があること
  • 腰や肩への負担の少ない椅子が支給されること
  • 十分に広いデスクが支給されること
  • 外部ディスプレイが支給されること
  • よいサービスやソフトウェアのライセンスが支給されること
    • (主観的) よいサービスやソフトウェアの例:
    • GitHub
    • Slack
    • IntelliJ

仕事道具に関する投資を節約したがる雇用主の元では働きにくいだろう。

仕事場に対する要求

  • (少なくとも執務時間中は) 仕事場が静かであること
  • イヤホンやヘッドフォンを着用できること

仕事に対する要求

  • 受託開発ではなく、自社製品の開発を行っていること
  • 受託開発会社を使わず、自社の技術者で開発を行っていること

「自分たちで考えて、自分たちで作っているんだ」と思えるときに高いモチベーションを持って仕事に望める。

ミーティングに対する要求

  • ミーティングへの出欠を自己の裁量で決められること
  • ミーティングの参加人数が制限されていること
  • (できれば全ての) ミーティングの議事録が社内全体に公開されること

無駄なミーティングへの参加はなるべく控えたい。特に参加人数が多いミーティングでは議論をすることは難しく、単に伝達事項を話すだけになりがちだ。それなら単にメールなどで伝達事項を送ってしまえばいい。

参加していないミーティングでも、議事録を後で確認できるのであればなおよい。

評価に対する要求

  • 仕事に対する評価プロセスが年次スケジュールに組み込まれていること
  • 上司の上司に簡単にアプローチできること
    • 上司が合わない場合に、上司の上司を通して変更できること

リモートワークに対する要求

  • 「妥当な理由のある」リモートワークが認められること
  • 「妥当な理由のない」リモートワークが認められないこと

数年前までリモートワークに憧れを持っていた。ただ、実際に今の職場でリモートワークを経験して、少し考え方が変わった。

リモートワークを導入すると、常時リモートで働こうとする人が出てくる。こういう人と連携して仕事をするのは楽ではない。ちょっと声をかけられればすぐに分かりそうなことであっても、いつ解決できるか分からない問題に変わってしまう。

一方で、例えば台風のときなどに出社が強制されるようでもつらい。

バランス感覚を持って能率的に仕事を進められる環境が理想的だ。

その他

  • 社内転職が可能であること

新しいチャレンジをしてみたいときや、上司と馬が合わないときに、社内で異動できる仕組みがあると望ましい。企業にとっても個人にとってもメリットがあるはずだ。

  • CI (Continuous Integration) ないし CD (Continuous Deployment) を実践していること

CI や CD を導入することの効果は大きい。一方、実際に導入するまでメリットを体感することは難しい。CI や CD を「当然のこと」として導入している企業は魅力的だ。

  • 開発環境の構築が容易

理想的にはコマンド一発で開発環境を構築できるのが望ましい。使用する技術は Vagrant でも Docker でもよい。開発環境の構築が自動化されていないということは、システム構築に関して属人性を許しているということになる。よくないサインだ。

まとめ

意外と色々なことが思いつくものだと思った。

正直なところ、今の職場でこれら全てを満足できているかというとそうでもないので、少しずつ改善していかなければならない。