progrhyme's tech blog

主にIT関連の技術メモ

プロフィールサイトをGitHub Page + CloudFlareによる独自ドメイン×SSL配信に移行しました

personal インターネット

はじめに

このブログからもリンクしている私のプロフィールサイトは、これまでは手抜きをしてGoogleサイトで作ったものでした。

大したコンテンツがあるわけでもないので、特に問題は無いのですが、いまのアカウント(id:progrhyme)を作ったときに自分用のドメインも取得していたので、せっかくならばそれを活用したい、という気持ちはありました。

調べたところ、Googleサイトで独自ドメインを利用するにはG Suiteが必要そうです。*1
G SuiteはBasicプランが月額600円と、個人で使うとしても決して高いものではありませんが、今のところ本件以外にG Suiteを使うモチベーションはありません。
また、せっかくWeb業界にいるエンジニアなので、もう少しテクニカルにやってみようと思いました。

GitHub Pages + CloudFlareの設定

GitHub PagesはGitHubが提供している静的なWebサイトのホスティングサービスで、GitHubユーザであれば無料で利用できます。
また、CNAMEレコードを設定することで、独自ドメインも使うことができます。

数年前なら、ここでSSL証明書をどうするか頭を悩ませることになったかもしれませんが、ここ最近は無料で証明書を提供してくれるサービスが増えてきました。
そもそも、今年の5月にはGitHub PagesそのものがカスタムドメインによるHTTPS配信を無料でサポートするようになりました。*2

初め、私もこの機能を使ってSSL化を試みましたが、一般的にZone Apex(サブドメインのドメイン名そのもの)にはCNAMEを設定できないというDNSの仕様があるため*3、 https://www.progrhy.me のようなURLになりそうでした。
それでも特に実害はないのですが、なんとなく嫌だなということで更に調べていたところ、Cloud FlareのDNSの場合、 CNAME Flattening という仕様が有効になっており、Zone Apexに対してもCNAMEを利用することができるとのことでした。*4

というわけで、ドメインを購入したレジストラでCloudFlareにネームサーバを転送する設定をして、 https://progrhy.me でGitHub Pagesで作ったサイトが見られるようになるところまでは一晩で設定できました。

Bootstrap Themeによるデザイン調整

最初はデザインは適当に済ませて、とにかく旧サイトから移行をしてしまおうと考えていたのですが、中々いい感じのテンプレートやツールを見つけることができず、意外に悪戦苦闘してしまいました。

最終的にGrayscaleという比較的シンプルなBootstrapのテーマを選びました。

おかげで期せずしてgulpやSassという新しめのフロントエンドのツールに触れることになりました。
あと、CSSのメディアクエリの書き方などを覚えました。

移行の現状

上述の通り、 https://progrhy.me/ で新サイトを閲覧できます。
このブログも含めて各種サイトやSNS等のリンクは一通り更新したつもりなので、移行としては完了です🎉

今後の予定

色々やり得ることはあるのですが、まずfaviconがまだ無いので、早めに作って設置したいと思います。

他方、npmの依存モジュールで脆弱性があるようで、GitHub上でセキュリティの警告が出ています。
大したことはしてないはずなのに package-lock.json が6218行もあって、npmの世界は怖いなと思ったものですが、ともあれ整理が必要そうです。

本サイトの更新頻度は高くはならないと思いますが、CloudFlareのキャッシュクリアなど含めてCI設定もできるといいなと思っています。

終わりに

この記事を書いている間にMicrosoftの「Sketch 2 Code」という新サービスのニュースが飛び込んできました。*5
AIによって、手書きのワイヤーフレームをHTMLに変換してくれるもののようです。

やってみて実感したのですが、素人がHTMLをいい感じに組むのは難しいので、AIで簡単になるといいなと思いました。

脚注

*1:参考: G Suite のドメイン所有権の確認 - G Suite 管理者 ヘルプ

*2:Custom domains on GitHub Pages gain support for HTTPS | The GitHub Blog

*3:参考: CNAMEレコードにZone Apexをマッピングできない件について – サーバーワークスエンジニアブログ

*4:CNAME Flattening: RFC-compliant support for CNAME at the root – Cloudflare Support

*5:Turn your whiteboard sketches to working code in seconds with Sketch2Code | Blog | Microsoft Azure

『SQLアンチパターン』を読んだ

RDB 読書

3〜4年前に買って積ん読していた『SQLアンチパターン』を、最近やっと読了しました。*1

本書について

本書は、技術書の良書として有名で、「ITエンジニアが読むべき本」のようなまとめに挙がることも多いので、知っている方や既に読んだという方も多いでしょう。

本書では、著者が長年SQLに関する仕事に携わるなかで遭遇した25個のアンチパターンが紹介されています。
アンチパターンとは即ち、「SQLを使用するプログラマーが最も頻繁に犯しがちなミス」とのことです。*2

特徴

本書では25個のアンチパターンが紹介されていますが、それぞれにキャッチーな名前が付けられています。
これは、本書の冒頭部で書かれている、以下のような業界の慣例に従ったものでしょう。*3

世の中のアンチパターンの多くには、「黄金のハンマー（Golden Hammer）」「車輪の再発明（Reinventing the Wheel）」「委員会による設計（Design by Committee）」などの、ユーモラスで刺激的なタイトルがついています。優れたデザインパターンとアンチパターンには、比喩的で内容を連想しやすい名前を与えることが慣例となっています。

また、各章が統一された1つのフォーマットに従って構成されている、という点も特徴に挙げられるでしょう。 即ち、下の構成です:

  1. 導入
  2. 目的
  3. アンチパターン
  4. アンチパターンの見つけ方
  5. アンチパターンを用いてもよい場合
  6. 解決策

このようにフォーマットが揃っているので、次に来る内容が予測しやすく、とても読みやすいです。

更に、導入部分はちょっとしたエピソード仕立てになっており、あわれな登場人物（=「あなた」）がいかにアンチパターンにハマったかが綴られています。
その点で、読み物としてもセンスの良さが感じられました。

どんなアンチパターンが紹介されているのか

本書で紹介されているアンチパターンは全て、以下のいずれかに該当するそうです。*4

  • 著者がソフトウェア開発やRDBMS製品のテクニカルサポート、研修、インターネットフォーラムでのやりとりを通じて実際に見てきたもの
  • 著者自らが陥ってしまったもの

私の（著者よりは乏しい）Webエンジニアとしての経験からは、以下のようなパターンがあると見受けられました:

少しだけ例を紹介します。

①については、例えばRuby on RailsなどのWAFではすべてのテーブルに id という名前のPrimary Keyを作るのがデフォルトの挙動となっていますが、その挙動は 「ID Required（とりあえずID）」 アンチパターンを生みかねません。

②に関して、 「Keyless Entry（外部キー嫌い）」「Multi-Column Attribute（複数列属性）」 あたりの章を読むと、胸がむかむかとしてきました。
名前から想像がつくかと思いますが、前者は外部キー制約を極端に避けるアンチパターン、後者は本来従属テーブルに切り出すべき属性を親テーブルに attr1, attr2, ... のように複数のカラムで持たせてしまうものです。
「Index Shotgun（闇雲インデックス）」「Spaghetti Query（スパゲッティクエリ）」「Poor Man's Search Engine（貧者のサーチエンジン）」 などのアンチパターンの名前を聞くと、Web開発に馴染みのある方であれば、頭が痛くなってくる方もいるのではないでしょうか。

③については、 「Readable Passwords（読み取り可能パスワード）」 や 「SQL Injection（SQLインジェクション）」 はポピュラーな問題だと思います。

これらに当てはまらないものでは、私にとって馴染みが薄いものも多く、学びがありました。

本書を読むべき人は誰か

本書の冒頭部には、「初心者から経験豊富なエキスパートまで、あらゆる段階の方に役立つ内容をお届けします。」とあります。

私自身は、Webシステムの開発や運用に携わるようになってもう10年近く経ちますが、上に書いたように十分に学びがありました。
ただ、もっと早く読んでいればよかったな、という感は否めません。

RDBやSQLの入門書ではないので、全くの初心者向けとは言えないと思います。
RDBやSQLについてある程度学んで、かつ、実際に多少のシステム開発や運用を経験した上で読むと良いのではないでしょうか。

どちらかというと、開発時――中でも、DB設計時に考慮すべき事柄が多いと思います。
その意味で、DBAよりはむしろアプリケーション開発者が読むべき本かな、と思いました。

まとめ

掛け値なしの良書でした。
オススメです。

参考

『SQLアンチパターン』を含むIT技術書籍まとめ:

*1:オライリーのサイトで電書版を買いました。

*2:本書「はじめに」の「対象範囲」より

*3:本書「はじめに」の「本書の構成」より

*4:本書「はじめに」の「対象範囲」より

「サービスメッシュとは何か」について調べた

システムアーキテクチャー 分散システム

はじめに

最近、「サービスメッシュ」という語を見聞きする機会が増えた。
概念を正しく理解しておきたいと思って、このところ調べていたので、ここにまとめを記しておく。

サービスメッシュとは何か

TL;DR

Microservicesとして構成される分散システムにおいて、サービス間通信を担う専用のレイヤ。
サービスディスカバリ、負荷分散、トラフィック制御、通信のセキュア化などの機能を実現し、個々のサービスから利用可能にする。
代表的なプロダクトとして、 IstioやLinkerdが挙げられる。

出典

上のようにまとめるにあたって参照した記事、文書、書籍を紹介する。
若干、相互に食い違う内容があったので、適当に自分が穏当と思うように取捨選択した。

私の解釈

もはや、当該レイヤで動作する(ソフトウェア)システムと定義してしまった方がしっくり来る。
なぜなら、上で述べたような機能を提供するもの(として認知されてきている)なので。

「service mesh」という語が登場するようになった当初は、単にMicroservices上のネットワークを指していたような表現が見られるが、いつの間にか「そのレイヤで動作するソフトウェア」という意味で述べられることが普通になってきたような気がする。

プロダクト

2018/8/11現在、自分が把握しているもの:

  • Istio
  • Envoy ... CNCF Incubation Project. Istio内ではプロキシ機能を担うコアコンポーネント
  • Buoyant社製品(※OSS)
  • Consul ... いつの間にか「distributed service mesh」となっている。また、Connectという新機能でsidecar proxyや通信の暗号化が実現される。

アーキテクチャー

サービスメッシュは上で述べたような概念のシステムなので、その実装は色々あり得るはずだが、IstioやLinkerdが事実上の標準実装となっているような向きがある。
正直、まだそんなに踏み込んで見てないのだけど、それらの構成要素は一致しており、よく似たアーキテクチャーとなっているようだ。

Istioのドキュメントから図を引用しておこう。

図: Istio Architecture

サービスメッシュ・システムの標準的な構成要素:

  • Data Plane ... サービス間の通信レイヤ
    • Sidecar Proxy ... 個々のサービス・プロセスとともに配置され、in/out双方向の通信を中継する。
  • Control Plane ... クラスタ内に配置される独立したサービスで、様々な中央集権的機能を担う。例えば、プロキシの管理を含むData Planeの制御や、設定変更のためのAPIが挙げられる。

その他参考:

サービスメッシュが必要とされた背景

既に上に挙げたWilliam Morganの記事から、内容をかいつまんで訳す。

大規模なMicroservicesシステムはGoogleやNetflix, Twitterといった巨大企業で発展していった。
アプリケーションが多数のサービスに分割され、複雑化する内に、汎用的な通信レイヤが必要とされた。 しかし、それらは「重厚なクライアントライブラリ」の形を取った。
TwitterのFinagle, NetflixのHystrix, GoogleのStubbyが具体例だ。
それらこそが最初の「サービスメッシュ」だと言える。

この「重厚なクライアントライブラリ」の問題点は、以下だ。

  • ライブラリによって、アプリケーションの開発言語やフレームワークが強制されてしまう
  • 一方で、コンテナの普及により様々な言語で作られたサービスが動作することが普通になった

従って、「ライブラリ形のアプローチはもはや現実的ではない」と述べられている。

サービスメッシュが登場した歴史

LinkerdとEnvoyのどっちが先だったかわからないが、どっちかが最初だと思う。

2016年:

2017年:

他にもっとこんなのあったよ、という情報をお持ちの方がいたら、教えていただけたらここに追記するかもしれません。

終わりに

以下、雑感。

それなりの規模のMicroservicesを運用しているところだったら、なんらかの形でサービスメッシュ的なものを使っているのではないか。
一歩引いて、自分たちの環境におけるサービスメッシュに相当するものは何か、と考えると面白いかもしれない。

大規模で、コンテナを使ったサービスでMicroservices化された環境だったら、Istioなどの製品は相性が良さそう。

参考

*1:https://conduit.io/ Kubernetes向けの軽量Service Mesh

『インフラ/ネットワークエンジニアのためのネットワーク技術＆設計入門』を読んだ

読書 ネットワーク

ネットワーク系の知識を補強したくて、『インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門』という本のKindle版を買って読みました。

読了して、なかなか良い本だなと思ったので紹介しておきます。
特に、駆け出しのインフラエンジニアやネットワーク経験の浅いエンジニアにオススメです。

2013年の本ですが、ほとんどの内容は現在でも通用すると思います。

良かったところ

  • L1〜L7まで概観して基礎知識が押さえられる
  • 運用を踏まえており、実践的
  • 図表が多くてわかりやすい
  • 冗長化含む構成例があるのが良い
  • 各種プロトコルの復習になった

悪かった / イマイチかもしれないところ

  • Kindle版が固定レイアウトのため、不便
  • 1つひとつのトピックについてそんなに深くはない

過去に読んだネットワーク系の本について

今回以前にネットワーク系の本をちゃんと読んだのは、もう随分前だったように思います。
社会人になる前後ぐらいの時期に、『マスタリングTCP/IP』の入門編・応用編と『図解・標準最新ルーティング&スイッチング』という本を読んだことを覚えています。

当時とは変わってしまった常識もちらほらあるように思います。

まとめ

『インフラ/ネットワークエンジニアのためのネットワーク技術＆設計入門』という本を紹介しました。

インフラやネットワークに携わるエンジニアの方々の参考になれば幸いです。
インフラ専業でないエンジニアが、予備知識のために読む本としても良いように思います。

よろしければ、どうぞ。

おまけ：疑問に思ったこと

ほとんど余談ですが、この本の中では「サーバサイト」という言葉が注釈なく出てきます。
文脈からすると、「サーバ機器が設置される場所」という意味っぽい。

Healthtech Meetup #1 でLTしてきた

IT勉強会

昨夜、縁あってこちらのイベントでLTをさせて頂きました。

今回は記念すべき第1回のイベントだったわけですが、私の属する会社含め、都内でヘルスケア関連の事業を営む複数のテック企業による合同イベントという形で開催されました。

そんなわけで、各々事業内容やサービスの内容を紹介しつつ、その裏側の技術要素に触れ、掘り下げていくという形の発表が多かったように思います。

私のLTについて

発表資料は下になります。

他はストレートなタイトルの発表が多かった中で、少し異色な題名だったかもしれません。

m3.comは医療従事者向けのサービスであって、一般の人がそのアーキテクチャー等を意識することはほぼないでしょうが、見えないところでこういうものが動いているのだという話もそれはそれで面白いかな(？)、と思いました。

スライドをよく見ると、私がこの資料で示されている2015年のリニューアルに全く関わってないことがわかると思います^^;
…なので、識者に話を聞いたり、社内資料を漁りながら発表の準備をすることで、私自身がm3.comのシステムを学ぶ良い機会になりました。

他の方々の発表について

各社特色がありつつも、技術的な理想と現実の折り合いを上手くつけているな、と感じました。
どなたかの発表で「ロックインされたくないけど、なるべくマネージドサービスに寄せる」という話があって、頷けるものがありました。

発表ラインナップの中で唯一アカデミック色の強いものがあって、それはDeNA望月さんによる『AI x 創薬の最近の研究動向』という題のものでした。
AIとは、創薬とは何かに始まり、創薬における機械学習や深層学習の応用例などを紹介して頂きました。
ふだん参加するテックイベントでこういう話を聞くことは珍しく、とても興味深い内容でした。

これらの発表資料は、まだWebに上がっていないものもあるようです。
手元で雑なメモを取っていたものをGistに上げましたので、リンクを載せておきます。*1

もしご興味があれば、ご覧ください。

公開スライド

5/24 0:15時点で、Connpassにはまだ資料が上がっていないようです。
私が把握できているものを以下に載せておきます。

終わりに

今回は歓談の時間は少なめでしたが、近い業界の色々な話を聞けて良い刺激になりました！
第2回以降もぜひ参加したいと思いました。

ありがとうございました！

*1:自分の発表の前後の部分などはがっつり欠けていたりします。悪しからず。

Ruby Hack Challengeもくもく会 #5 に参加した

IT勉強会 プログラミング

一昨日、Ruby Hack Challengeもくもく会に参加してきました。

初回のCookpad Ruby Hack Challengeは昨年の8月末でしたね。
当時から興味のあるイベントだったのですが、記憶によれば、予定が合わなかったり抽選で漏れたり諦めたりしたようです。

そんなわけで、初RHCでした。

事前準備

空手で行っても資料を元にもくもく作業はできそうでしたが、一応前日に少しだけ準備して臨みました。

GitHubに公開されているRHCの資料を読みながら、手順をなぞってRubyをMac上でビルドしたり、C言語の開発環境を整えたり、といった作業をしました。

当日の流れ

会場はCookpadさんの12Fオフィスでした。
キッチンのある広いフリースペース的な場所で、少し大きめの勉強会などでも使われていると思いますが、今回は人数が少なめだったこともあって、1つのテーブルを囲んでみんなでもくもく作業しました。

自分は開始時刻の18:30ごろに到着したのですが、既に@ko1さん含む4名前後の方がいらっしゃってました。

PCを取り出すと、もくもくとRHC資料の続きを読みながら、途中の演習問題を解いていきました。
発展演習問題などは一旦すっ飛ばしつつも、一応最後の 5_performance.md まで読み切ったところで時間切れとなりました。

その間にばらばらと参加者が集まり、終了間際の21:00過ぎになってようやく全員で軽い自己紹介を行いました。

MacにおけるC言語の開発環境について

とても久しぶりにC言語のコードを書くことになったので、開発環境を整える必要がありました。

自分の短いRuby歴(2年弱)では、ずっとVimで開発していましたが、型のある言語だとIDEの支援を受けた方が効率が良いだろうと思っています。

そんなわけでIDEを検討したところ、まあMacだとXcodeがスタンダードなのかなと思いつつ、最近流行りのVS Codeを試したい気持ちになったので、今回はこちらを使ってみました。
私の観測範囲では、VS CodeはJavaScript界隈などで人気が高まっている気がしますが、Rubyもextensionがありますし、上手くすればなんでもVS Codeで書けるような気もします。

もくもく会までにバッチリ使い込むには至りませんですが、コードの読み書きでそれなりに支援を得られるぐらいにはなりました。

もう少しVS Codeを継続してみようかなと思っていますが、Mac上でのC言語開発について、良い情報をお持ちの方はお知らせ下さい。

gdbの代わりにlldbを使った

VS Code上でデバッグするまでは行かなかったのですが、rubyをビルドするためのmakeタスクで make gdb や make lldb が用意されています。 実行するとソースコードディレクトリに置いた test.rb を、その場でビルドしたruby(miniruby)を使ってgdb or lldbで実行してくれます。

初め、Macでgdbを動かそうと少し試していたのですが、結局上手く行きませんでした。*1

lldbはLLVMのライブラリを利用したより高機能なデバッガで、どうもMacではこちらを使った方が筋が良さそうです。

今後について

@ko1さんによれば、6月もRHCのイベント(おそらくまたもくもく会でしょうか)が開催されるそうです。

今回、私は下準備的なことしかできなかったので、できればまずは何か1つコントリビュートしてみたいなと思っています。
というわけで、来月以降も機会が合えば是非参加したいと思っています。

終わりに

イベントの開催、ありがとうございました！

*1:ログ: https://sites.google.com/site/progrhymetechwiki/home/memo/20180506#TOC-Mac-gdb-

GitLab Meetup Tokyo #7 に行ってきた

IT勉強会 SCM 開発プロセス

4/10にこちらのイベントに行ってきました。

気づいたときには一般参加枠が埋まっていたので、ブログ枠で参加しました。
…ということもあって、こうして記事を書いております。

最近GitLabを使うことが多いのですが、今回はコアな方々の話を聞けたり、今まで知らなかった機能やGitLabの思想にも触れることができて有意義でした。

  • はじめに
  • 発表スライド
  • 感想
  • 終わりに
  • 聴講メモ
    • Keynote「GitLabによるComplete DevOps」
    • LT①「How does GitLab manage git repositories?」
    • LT②「GitLabのイシュートラッカー活用術」
    • LT③「GitLab CI & Docker in Docker」
    • LT④「カップラボ」
    • LT⑤「State of Community Contributions to GitLab & GitLab 11.0」
    • スポンサーLT クリエーションラインさん

はじめに

会場はサイボウズさんでした。

f:id:progrhyme:20180411000200j:plain

全体で90名ほどの参加予定でしたが、席はほぼ満席で、活気のある雰囲気でスタートしました。

始めに、GitLab Tokyo / GitLab JPの案内がありました。

Slackはどうやって入るのだろうと思ったのですが、HerokuでSlackinが動いているようですね。 検索すると見つかると思います。

発表スライド

Connpassに上がっているものもありますが、捕捉したものはここにも上げておきます。
(※随時更新します。)

Keynote「GitLabによるComplete DevOps」@shkitayama

LT①「How does GitLab manage git repositories?」@sotayamashita

LT②「GitLabのイシュートラッカー活用術」@jumpyoshi

LT③「GitLab CI & Docker in Docker」@toricls

LT④「カップラボ」@t_nakayama0714

LT⑤「State of Community Contributions to GitLab & GitLab 11.0」@tnir

感想

詳細な聴講メモは記事末尾に載せておきますが、ここでは印象深かった点を中心に簡単に感想を述べます。

続きを読む