hekiblo

hekki blog

2023年 振り返り

今更という感じですが、2023年の活動についてまとめておきます。（1年に1エントリーペースでしか書いてない…）

仕事

一応断っておきますが、以下全て個人の感想です。所属組織の意見を代表するものではありません。

全体を通して

引き続き株式会社MIXIに勤務していまして、家族アルバム みてね のSREをやっています。勤続7年目に突入しました。時が過ぎるのはあっという間。

勤続年数が長くなってきたこともあり、サービスのコアとなるような要素技術にもある程度明るくなってきたのでその知識を使って社内勉強会を開いたり、登壇や執筆を積極的に行った1年でした。このあたりはある程度手応えがあって良かったポイントです。

逆に、部屋の中の象といわれるような問題に対しての改善の提案だったり、わりと大きめのアーキテクチャの変更などは上手くコントロールできず成果を出せなかった反省も多い1年でした。いい意味で大きなストレスなく日々の業務に当たれている一方で新卒の頃のような右も左も分からないけどがむしゃらに仕事に打ち込む熱量を失ってしまったなーと思うこともあり、2024年はもっとチャレンジしていきたいです。

登壇 & 執筆

昨年は4回登壇の機会をいただきました。前職ではわりと登壇の機会が多かった一方で、転職後でこんなに登壇したのは初めてでした。加えて2本記事の執筆もしました。

会社やサービスのブランディング、キャリアアップのためのセルフブランディング、技術コミュニティへの貢献など目的は様々だと思いますが、外部露出は目的を持って狙って動かないと割く時間の割には得られるものが少なくなってしまうと感じる事が多く、改めて目的を意識することの大切さが身に沁みました。

また、反響の有無は、内容の質・分かりやすさ、ワードチョイス、ネタの鮮度（リリースしたばかりの注目度の高いなにかを使ってみたとか）など色々と要因がありそうで、個人的には「めちゃくちゃおもしろい！」と思った内容で全く反響がなかったり、逆に意外と反響が大きかったり、自分の思い通りには全くいかず難しいなと感じることが多かったです。

プライベート

家

現在居住中のマンションを売って、郊外に家を建てることにしました。 2023年の春頃から本格的に動き出して、それ以降プライベートの大半は家のことを考えてました。まだまだ全行程完了していないですが、落ち着いたらまとめるぞ。

猫

2023年1月に保護猫を迎え入れました🐈‍⬛（その後に家の話が出てきてしまい、引っ越しは猫にとってストレスなので申し訳い気持ち。） 元野良猫なので正確な年齢は不明ですが、4歳の黒猫です。ばり可愛い。

ねこ

英語

学生時代から英語が苦手でのらりくらりとやってきたものの、英語の壁を感じてチャレンジできない機会が何回かありました。

さすがに悔しかったので、今年は英語をやっていく所存です。「グローバル人材に俺はなる！！」みたいな謎の目標だといつまで経っても達成出来ずにダレるので、まずは分かりやすいTOEICのスコアアップを目指します。

「TOEICでハイスコア取っても英語は喋れるようになれない」的なことを言われがちですが、とにかくハイスコアを目指します。ハイスコアを取れるようになって、それでも全然だめだったらそのときに方針転換するつもり。

おわりに

今年はぼんやりと考えてることを言語化する練習のためにもブログを書くぞ！！！！

電気通信大学（夜間主課程）に入学するぞ

タイトルの通りで、2022年4月に電気通信大学の夜間主課程に入学します。
これまでと変わらずフルタイムで仕事は続けて、社会人大学生として二足のわらじを履きます。

ちなみに受験を考えている方のためのアドバイスは、先輩方の記事がとても参考になるのでここでは書きません。

動機

高校生時代まともに受験勉強をせず、なんとなく受験して受かった地元のFラン大に入学し中退するという目も当てられないような酷い経歴がある僕にとって、学歴というのは大きなコンプレックスの一つです。

とはいえ社会人になると学歴を意識することは無く*1、「大卒でない」「中退している」といった経歴で困ったことは今のところ特にないです。
あえていうと、新卒採用で就職活動をする際に「大卒以上」で足切りがある企業がちらほらあってそもそもエントリーできなかったり、必ず大学の中退理由を聞かれるので受け答えに苦しんだことぐらいです。

ただ今でも、現役時代にまともに勉強をせずにふらふらしていたことの後悔や後ろめたさはずっと引っかかるものがあって、いわゆる高学歴の同僚や友人と自分を比べて卑下したりすることがあります。
こういった気持ちが付きまとうのは本当に嫌で、打ち勝つためには成功体験を掴むしかなかろう、というのが大きな動機のひとつです。

あとは、大学のカリキュラムを通して自分が専門としているような分野の知識 + 今まで全く知らなかった分野の知識も学ぶことができるはずで、今後仕事をしていくうえでの土台のようなものが自分の中に出来上がれば最高だな、という気持ちもあって受験をしました。

社会人大学生になる意味はあるのか？

社会人大学生はそんなに簡単な話でもなく、もちろん生きていくためには仕事はこれまで通りしなくちゃいけないし、講義に出て予習復習をしてレポートを書いてと相当キツイ生活が待ってます（面接時も本気度を伺うような質問がありました） 。

30過ぎたおっさんが、プライベートを削って、仕事にも影響が出てしまうことは目に見えているのに、社会人大学生になる意味はあるんだろうか？
仮に4年ストレートで卒業したとしても、卒業する頃には30代後半。*2

「大学なんぞ行かずに、その時間も仕事に当ててバリバリ働いたほうが今後のキャリアや年収アップのためには良いのでは？」「大学で学んだことが仕事で何も活きなかったら？時間の無駄になってしまうのでは？」あたりは個人的にかなり悩みましたが、少なくとも現役時代にやるべきことをやらずに作った後悔は埋め合わせできるだろうし、その上で仕事に活かせるような何かが身につけば最高、という結論に自分は至りました。

なんにせよ、ここがぼんやりしているとキツイ生活に耐えられずに逃げ出してしまいそうな気がしたので、ここは時間をかけてかなり考えました。

目標

とにかく卒業すること。これが最優先。
自発的に社会人大学生にまでなって、また退学は絶対に嫌なので。。。

もちろん各科目の成績はできるだけ良くしたいし、内容も理解して身につけていきたいけど。

おわりに

前向きな理由で社会人大学生として学び直す方も多いので、同じような境遇の人の後押しになれば幸いです。

*1:少なくとも自分の経験上は

*2:しかも夜間主ということも影響しているのか4年ストレートで卒業する人は約30%

Macのターミナル環境再構築メモ

Macの調子が悪く、クリーンインストールをしました。
せっかくなので、ターミナル環境の構築メモを残しておきます。

基本的に、デフォルトの設定からなるべく変更しないことを良しとしているので、あまり面白くないかも。

iTerm2

iterm2.com

他のターミナルソフトもしらべてみたものの、なんだかんだでiTerm2に落ち着きました。

設定はそれほどいじっていませんが、主な変更点はこちら。

Homebrew

brew.sh

みんな大好きHomebrew。

fish shell

shellはbash -> zsh -> fish shell という感じで渡り歩いて、fish shellで今の所は落ち着いています。

fishshell.com

プラグインマネージャーはfisherを使います。
また、プラグインは下記のプラグインを使っています。

  • jethrokuan/z
  • laughedelic/brew-completions
  • matchai/spacefish

tmux

tmux自体はbrewでインストールしています。
プラグインマネージャーはtpmを使います。

詳細はtmux.confにて。

以上！

AWS Systems Manager Session Manager を使って、手元のマシンから楽してEC2へ接続する

aws

概要

AWS Systems Manager Session Manager（以下Session Manager）を使用している環境でEC2 に接続する場合、色々と面倒なことがわかりました。

面倒事

Session Manager はマネジメントコンソールから利用する場合「マネジメントコンソールにログイン -> 接続先のEC2 インスタンスを探す -> Session Manager を使用して接続」という流れになります。
毎回この手順を踏むのは面倒ですし、SSH のように手元のマシンから接続できないのは不便なので、AWS CLI を使いたくなります。

ただし、AWS CLI + Session Manager の場合でも、接続先のEC2 インスタンスのインスタンスID を調べるためにマネジメントコンソールから確認する必要がありました。
これは非常に面倒なので、この手順をスキップして接続できるように工夫してみます。

本題

前提

手元のマシン はMac を想定しています。ただし、Windows/Linux など他のOS でも適宜読み替えれば同じことができるはずです。 また、予め以下のようなツールがインストールされている必要があります。

また、aws ssm start-session や aws ec2 describe-instances が実行できる権限が付与されたAWS アクセスキーが手元のマシンに登録されている必要があります。
ここでは hoge-profile という名前付きプロファイルとして、アクセスキーが登録されていることとします。

ツールの用意

下記のシェルスクリプトをパスが通っているディレクトリに作成します。ここではスクリプトのファイル名を awssh とします。
gist.github.com

使ってみる

このようにしてAWS のプロファイルを指定しつつコマンドを実行します。

$ awssh --profile hoge-profile

コマンドを実行すると起動中のEC2 インスタンスの一覧が表示されるので、接続したいインスタンスを選択すると、そのインスタンスのコンソールにログインすることができます。

これで接続先のEC2 インスタンスのインスタンスID をマネジメントコンソールから確認しなくてもSession Manager を使ってインスタンスのコンソールにログインすることができるようになりました。やったね！

2020年 振り返り

2020年も終わりが近づいてきたので1年の振り返りをする。

今年も去年と同じく、SREというロールで仕事をしていた。 今年の自分のテーマは「ソフトウェア開発スキルの向上」で、とくにかくこれを念頭に置きながら1年過ごした。

2018年の夏に今の部署に異動して、SREというロールで 家族アルバム みてね というスマートフォンアプリのバックエンドの開発や運用をやるようになった。 それまで物理インフラ畑にずっといたからか、最初の1, 2年は特にコーディングの苦手意識がすごくて（苦手意識というか実際にできなかったんだけど…）、重めの開発タスクがあると嫌だなあーと思って避ける事が多かった。
とはいえそのまま避け続けるわけにはいかないし、せっかくなら自分で開発したものをユーザーに使ってほしいのでなんとかしようといろいろやった1年だった。

具体的には次のようなことをやった。

デザインパターンを身につける

トンチンカンな設計をしたままコーディングに進んでしまって、あとあと大きな手戻りが発生する…みたいな経験を何度かしたので、その問題を克服するためにいくつか本を読んだ。

増補改訂版 Java言語で学ぶデザインパターン入門

増補改訂版 Java言語で学ぶデザインパターン入門

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

どちらもまずはパラパラと一周読み、実際に業務で設計しながら使えそうなところを後で何度もじっくり読むようにして、辞書的に使っている。
はじめからじっくり読んでもイメージが湧きにくいし、読み終えるまでにダレるし、一度だけじっくり読んだってすぐに忘れるので。

フレームワークに馴染む

業務でRails を使っていることもあり、とにかくRails way に乗って素早く・（Rails のお作法的に）正しく・美しく実装ができるようにしたくて、Rails に慣れ親しむのを意識した。

初めの方はRails チュートリアルをじっくりこなしたり、今年の夏にパーフェクト Ruby on Rails の改訂版が出たのでそれを読み進めたりした。
初めてRails を学んだ対象が、それなりに歴史のある大きなRails プロジェクトだったこともあり「よく分からんけどなんか動いてる」といった知識の穴が結構多く、その穴を埋めるのにはとても良かったと思う。とはいえ、未だにRails 知らない機能多いけど。

パーフェクト Ruby on Rails　【増補改訂版】

パーフェクト Ruby on Rails　【増補改訂版】

gem のコードをたくさん読む

これは特になにか意識付けがあったわけではないし、どちらかというとバグ調査などで必要があったから読むことが大半ではあったものの、面倒くさがらずにちゃんと読んで理解するのは結構自分のためにはいい経験だった。

また、danger-rubocop というgem のバグに遭遇し、該当の箇所を読んでみたところ直せそうな雰囲気を感じたのでPR を送ってみたところなんとマージしてもらうこともできた。（OSS 初コントリビュート！） 内容的には些細なバグ修正ではあるものの、自分のスキルの向上を感じれたのでこの経験はかなり嬉しかったし、自信にも繋がった。 github.com

来年は引き続きソフトウェア開発のスキルは伸ばして行きたいなーと思いつつ、kubernetes を本格的に触り始めたのでその辺りの開発・運用もガッチリやっていきたい。 また、サービスの性質上膨大な量の画像・動画を取り扱うので、メディアの基礎的な知識も更に蓄えていかねばという感じ。

来年も引き続き頑張っていきましょう！

宣伝

自分が所属する「家族アルバム みてね」ではエンジニアを大募集中です！ medium.com

WebP を試す

imagemagick

iOS14 でWebP に対応との情報を見かけたのでこれを機にとりあえずエンコードして試してみることにした。

エンコード環境の作成

docker コンテナ内にImageMagick をインストールして、使うことにする。

Dockerfile を作成する。 簡易的なテストのためのものなので、とりあえずapt でインストールしてみた。

FROM ubuntu:20.04

RUN apt-get -y update && \
    apt-get -y install imagemagick && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

続いてdocker image をビルドして、convert コマンドを実行してみる。

# docker image をビルド
$ docker build -t imagemagick .

# 動作確認
$ docker run -it imagemagick convert --version
Version: ImageMagick 6.9.10-23 Q16 x86_64 20190101 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib

ここまでで準備は完了。

エンコード

エンコード対象の画像を /path/to/images/1.jpg とする。

特にパラメータを指定せずエンコードしてみる。

$ docker run -v /path/to/images:/images --rm -it imagemagick convert /images/1.jpg /images/1.webp

これでエンコードできた。 画像を並べて比較してみたところ、色味や粗さなど自分の肉眼では判別できないほど違いが分からなかった。

エンコード結果の確認

ファイルサイズはかなり違いがある。 とはいえ、これはパラメータ次第だと思われるので、大した参考にはならなさそう。

$ docker run -v /path/to/images:/images --rm -it imagemagick ls -l /images
total 6184
-rwx------ 1 root root 4101341 Oct 22  2019 1.jpg
-rw-r--r-- 1 root root 1908796 Sep 24 14:43 1.webp

ImageMagick に同梱されているidentify コマンドで画像の詳細をチェックできる。

$ docker run -v /path/to/images:/images --rm -it imagemagick identify -verbose /images/1.jpg
$ docker run -v /path/to/images:/images --rm -it imagemagick identify -verbose /images/1.webp

パラメータに関してはImageMagick と WebP がよくまとまっていた。 こちらの記事で概要を掴んで、Google の仕様書を読み込んでいくと詳細まで把握することができそう。

Linuxで作るVLAN変換サーバー

network

2015年12月17日に公開した記事を移動してきました。

L2 ネットワーク内で、ある VLAN タグが付いたフレームを、別の VLAN タグに付け替える Linux サーバーを作ってみます。 万人に使い道があるとは思えませんが、誰かの参考になると嬉しいですね。

概要

全体像

まずは VLAN 変換サーバーを含めた今回のお題とするネットワークを紹介します。

ネットワークには通常の Linux サーバーが二台 (Node1, Node2) と、VLAN 変換サーバー (VLAN-brige) を1台用意します。 VLAN 変換サーバーには Ubnutu14.04 を利用していますが、ディストリビューションはお好きなものを利用して構わないです。

f:id:ni_hi:20190927172910j:plain
図1: 検証NWの全体像

しくみ

VLAN 変換サーバーの仕組みについて説明します。

VLAN 変換サーバーは、内部に VLAN インターフェースと、bridge インターフェースを持っています。 変換対象となる VLAN インターフェースのペアを brdige インターフェースを使って論理的に接続します。

まず、VLAN 変換サーバーに到達した VLAN フレームは、VLAN インターフェースによって VLAN タグが外されます。 次にタグが外されたフレームは bridge インターフェースに到達します。 bridge インターフェースから、もう片側の VLAN インターフェースにフレームは転送され、元々付いていた VLAN タグとは異なる VLAN タグが付けられます。 この仕組を利用することによって、任意の VLAN タグが付いたフレームを別の VLAN タグに付け替えることができます。

f:id:ni_hi:20190927173008j:plain
図2: VLAN 変換サーバーの内部 NW

つくってみよう

それでは VLAN 変換サーバーを作ってみましょう。 サーバーは2台でも試験できますが、今回は分かりやすくするために3台用意します。

VLAN <-> VLAN 変換編

まずは終端となる2台のサーバーに異なる VLAN インターフェースを作成します。 Node1 に VLAN 番号 100 のインターフェース、Node2 に VLAN 番号 200 のインターフェースを作成します。 ここでは、eth1 のサブインタフェースとして作成してみます。

Node1

# サブインタフェースの追加をする
$ vconfig add eth1 100

# 作った eth1.100 に IP address を割り振って
$ ip addr add 192.168.0.100/24 dev eth1.100

# eth1 インターフェースを起こして
$ ip link set eth1 up

# eth1.100 インタフェースを起こす
$ ip link set eth1.100 up

Node2

Node2 も同様に 200 番の VLAN インターフェースを作成して、IP address を付けておきます。

$ vconfig add eth1 200

$ ip addr add 192.168.0.200/24 dev eth1.200
$ ip link set eth1 up
$ ip link set eth1.200 up

VLAN 変換サーバー

VLAN 変換サーバーは、前述した通り、VLAN インターフェースの他に brige インターフェースを作成するので、brctl コマンドを利用します。

# eth1.100 インターフェースを作っておいて
$ vconfig add eth1 100
$ ip link set eth1 up
$ ip link set eth1.100 up

# eth1.200 インターフェースも作っておいて
$ vconfig add eth1 200
$ ip link set eth1 up
$ ip link set eth1.200 up

# br1 という名前で bridge インターフェースを作って
$ brctl addbr br1

# br1 に eth1.100 を論理的に接続
$ brctl addif br1 eth1.100

# br1 に eth1.200 も論理的に接続
$ brctl addif br1 eth1.200

# br1 インターフェースを起こす
$ ip link set br1 up

これで準備は整いました。 Node1 と Node2 でお互いの IP address に ping を送信してみましょう！ ping が到達するのが確認できましたか？

到達が確認できたら、VLAN 変換サーバーで各インターフェースを tcpdump で眺めてみると面白いかもしれないですね！

VLAN <-> Nested VLAN 変換編

おまけです。 ほとんど変わらないですが、任意の VLAN フレームと Nested VLAN フレームも同じように変換できます。

Node1

# サブインタフェースの追加をする
$ vconfig add eth1 100

# 作った eth1.100 に IP address を割り振って
$ ip addr add 192.168.0.100/24 dev eth1.100

# eth1 インターフェースを起こして
$ ip link set eth1 up

# eth1.100 インタフェースを起こす
$ ip link set eth1.100 up

Node2

Node2 は Nested VLAN インターフェースを作っておきます。

$ vconfig add eth1 200
$ vconfig add eth1.200 300

$ ip addr add 192.168.0.200/24 dev eth1.200.300
$ ip link set eth1 up
$ ip link set eth1.200 up
$ ip link set eth1.200.300 up

VLAN 変換サーバー

# eth1.100 インターフェースを作っておいて
$ vconfig add eth1 100
$ ip link set eth1 up
$ ip link set eth1.100 up

# eth1.200.300 インターフェースも作っておいて
$ vconfig add eth1 200
$ vconfig add eth1.200 300

$ ip link set eth1 up
$ ip link set eth1.200 up
$ ip link set eth1.200.300 up

# br1 という名前で bridge インターフェースを作って
$ brctl addbr br1

# br1 に eth1.100 を論理的に接続
$ brctl addif br1 eth1.100

# br1 に eth1.200.300 も論理的に接続
$ brctl addif br1 eth1.200.300

# br1 インターフェースを起こす
$ ip link set br1 up

これで準備は整いました。 Node1 と Node2 でお互いの IP address に ping を送信してみましょう！

感想

仕組みさえ分かってしまえば意外と簡単でした。 ただ、変換サーバーの冗長化はめちゃくちゃ苦労したので、興味のある方はぜひ挑戦してみてくださいね！

ネットワークの勉強をするときには、どの地点でパケットやフレームにどういったヘッダーが付いていて、それらが着信したインターフェースによってどう処理されるかをひとつひとつしっかり考えることが一番の近道だと思います。 繋がったときに楽しさ倍増なので、tcpdump をバンバンしましょう！