新卒からITエンジニアとしてやってきた男が、10年で4社目を経験して辿り着いた「境地」

エンジニア

私は社会人10年目、つまりITエンジニア歴も10年。転職3回を経て4社目の現在は、ドクターメイトという医療介護系のベンチャー企業で働いています。

今すごく充実している。そりゃ職場には気が合わない人だっているし、ムカつく瞬間だってある。でもそういうことではなくて、なんというか「迷いがなくなった」みたいな。これが僕の辿り着いた境地だと思います。

「持ってる」側の人間だと思ってた20代

私は新卒でワークスアプリケーションズという会社に入社した。新卒研修等で有名な会社だった。研修で結構良い結果を出したことで、給与が100万上がり、同期の上位10%ほどしかいないグレードからのスタートとなった。体力も精神力も根性もあった。毎日9時から終電まで働き、部長や先輩のパワハラなどにもめげなかった。社長賞をとるような上長に気に入られ、右腕と勝手に自負して働き、上長が転職する際に、自分も「引き抜かれた」形でついて行った。

続きを読む

【イベント感想】インフラ技術基礎勉強会 #3 に参加してきました

イベント感想 エンジニア

イベント情報

イベント構成

  • LT-1 Kubernetes超基礎と認定資格について
  • LT-2 Knativeを使うと何が嬉しいの？
  • LT-3 なぜTerraformでインフラを管理するのか？
  • LT-4 AWSのインフラ構築ツールを比較してみよう
  • LT-5 AWS Aliasを使った開発生産性向上施策について

感想（気になった事）

Kubernetes超基礎と認定資格について

Kubernetes超基礎と認定資格について

AWSに変換して考えちゃうんだけど、下記てきな感じであってるのかな・・・

AWS EKS を触ってみないと、想像できない内容かもしれない。

Knativeを使うと何が嬉しいの？

Knativeを使うと何が嬉しいの？

Kubernetes（AWS EKS）って使ったことないんだよな〜、使う時がきたら、Knativeの利用を考えよ。

AWS Aliasを使った開発生産性向上施策について

AWS Aliasを使った開発生産性向上施策について

Alias機能知らなかった・・・割といいかも。 AWS CLIって、毎回必ずと言っていいほどコマンド調べるから、再現性がなくてつらいな（使わないな）ってなってたので、 使ってみようかなと思いました。複数人が利用する踏み台サーバーの中に仕込むとかは、開発組織ならGoodなアプローチだと感じた。

最後に

AWS Alias は知らなかった。これはエンジニア組織での利用とか考えた場合に、いい取り組みになるだろうなと感じた。

Kubernetes使ったことないんだけど、connpassのウェビナーとかみてると結構この話題多いんですよね・・・世間では割とみんな使い始めてるのかな・・・？

【テックブログ】認証方式についてまとめてみた

テックブログ エンジニア

いろんな認証方法があるのでまとめてみた。

※ たくさんあるので随時追加していきます。

Basic認証

Basic認証

HTTPで定義される認証方式。

ユーザ名とパスワードの組みをコロン ":" でつなぎ、Base64でエンコードしたものを、リクエストヘッダのAuthorizationフィールドに記載して、サーバーへ送信することでチェックしている。

初回認証後は毎回の通信時に、ブラウザが自動的に Authorizationフィールドに認証情報を記載しているため、都度入力は不要。

HTTP通信で利用できるため利用シーンが幅広く利用難度が低いが、SSL暗号化されていないサイト利用時に通信傍受されると、簡単にパスワードが漏洩してしまうため、次の Digest認証 が生まれた。

Digest認証

Digest認証（見た目はBasic認証と変わらない）

Basic認証におけるパスワード漏洩リスクを改善した認証方法。

サーバー側から発行される nonce や realm といったデータを含めて、ユーザ情報やパスワードをMD5でハッシュ化したものを送信している。これにより、通信傍受されたとしても複号化が困難となり、Basic認証に比べて安全性が担保されている。

サーバーが発行するデータ

  • nonce: ランダムな文字列
  • realm: 認証領域
  • qop: auth または auth-init がはいり、どちらかによりMD5ハッシュ化の範囲が異なる

クライアントが発行するデータ

  • cnonce: ランダムな文字列（多分 clinent + nonce という意味だと思う）
  • nc: nonce-count（同じnonceで、同じnonce-countがリクエストされると異常とみなすための安全装置みたい）

Basic認証同様、リクエストヘッダのAuthorizationフィールドによって認証が行われる。特に response 要素に、下記のロジックで暗号化された認証情報が含められる。

A1 = ユーザ名 ":" realm ":" パスワード
A2 = HTTPのメソッド ":" コンテンツのURI
response = MD5( MD5(A1) ":" nonce ":" nc ":" cnonce ":" qop ":" MD5(A2) )

※ qopがauth-initの場合、A2は次のようになる
A2 = HTTPのメソッド ":" コンテンツのURI ":" エンティティボディ

FIDO認証（Fast IDentity Online Alliance）

顔認証（iPhone）

指紋認証や顔認証といったものに代表される、パスワードの入力を必要としない認証方式のこと。

例えば、iPhoneの顔認証を例にとってみると、

あるサービスに登録する場合、自分のiPhoneと利用サービスのアカウントに対して一意の、新しい公開鍵/秘密鍵のペアを生成し、秘密鍵はiPhoneに保存され、公開鍵は利用サービスに送信され、自身のアカウント情報に紐づけて保存される。

ログイン時には、まずサービスからiPhoneへ認証要求（チャレンジ）がレスポンスされ、それをiPhoneに保存されている秘密鍵で暗号化したものを送り返し、サービス側の公開鍵で検証して認証を行っている。

（個人的に、サービスのアカウントごとに秘密鍵を作っている感覚がなかったので、新しい気付きを得ました）

OAuth認証（Open Authorization）

Twitter認可

SSO（シングルサインオン）を実現するための認証方法の1つ。

アクセストークンを利用した「認可」を実現している。（「認証」と「認可」は別物。）

通常、OAuthは認可を実現する仕組みなので、認証（ログイン）には利用されない...のだが、認可によりサービスがプロフィール情報にアクセスして本人情報を取得することにより、認証のような動作を実現することができる。

OAuthによるソーシャルログインを提供している企業（IdP: Identity Provider）

  • Twitter: OAuth2.0ベースの独自仕様
  • Facebook: OAuth2.0ベースの独自仕様

例えば、Twitterによる認可を例にとってみると、

利用サービスはユーザー経由でTwitterからの認可コードを取得し、それをもってアクセストークンの発行を依頼する。

認可コードが正しい場合、アクセストークンが発行され、利用サービスはそれをアカウントに紐づけて保存する。

アクセストークンを利用することで、利用サービスはユーザーに代わってTwitterへのアクセスが可能となり、ユーザーのプロフィールやツイート情報を取得することができる。

OAuthの流れ

ただしOAuth認証には、アクセストークンが盗まれると悪意のある第三者による不正ログインができてしまう脆弱性が存在する。

この脆弱性をさらに改善したものが、OIDC認証になる。

OIDC認証（OpenID Connect）

SSO（シングルサインオン）を実現するための認証方法の1つ。OAuthを拡張した進化版みたいな感じ。

IDトークン（JWT形式）を利用した「認証・認可」のどちらも実現している。

OIDCによるソーシャルログインを提供している企業（IdP: Identity Provider）

（後日、更新します）

SAML認証（Security Assertion Markup Language）

SSO（シングルサインオン）を実現するための認証方法の1つ。

SAMLとOAuthという2大プロトコルが存在し、それぞれ認証方式が存在しているという状態。

と、ここまで書いてはみたけど、実際に実装してみないとイマイチわからないです...

最後に

Threadsの登録者数の伸びを見ていると、やっぱりSNS認証は強いなと感じます。

認証機能を提供するサービス（IDaaS）の現状のスタンダードは Auth0 だと思われます。

月並みですが、Auth0 といった IDaaSを利用して、OIDC認証やFIDO認証をサクッと組み込める

そんなことができれば、一般的なエンジニアとしては十分なんじゃないでしょうか。

【イベント感想】Qiita Night～AWS vol.2～に参加してきました

イベント感想 エンジニア

イベント情報

イベント構成

  • LT #001（不参加）
  • LT #002：Trivyという静的解析ツールを使う話（ほぼtfsec）
  • LT #003：ECSからECRのイメージpullしてたら金額がやばかった話
  • LT #004：よく覚えてない
  • LT #005：VPC Latticeというサービスを使った話

感想（気になった事）

LT #002：Trivyという静的解析ツールを使う話（ほぼtfsec）について

tfsec自分もterraformのリポジトリで必ず利用していますが、AquaSecurityという企業に買収されており、Trivyというツールの一部になっていたようです。

下記のdiscussionで、Trivyに移行するように2月に書かれています。ただ 👎 が多いのが気になりますね😅

github.com

Trivyは、DockerイメージやGithubリポジトリなど、いろいろなスキャン対象があるので、もしかしたら今後はいろいろなところで見かけるようになるのかな。

LT #003：ECSからECRのイメージpullしてたら金額がやばかった話

このLT、「ECRはVPC外にあるから気軽にイメージpullしてたらやっべえぞ」的な文章なので、「なんやECRとかVPCが悪いんか？」って思われがちだと思うんですが、結局NATゲートウェイ気をつけようねって話だと自分は思います。

NATゲートウェイ、コストを考える上で必ずネックになるリソースだと自分は思っていて、自分も気をつけたいです。だってprivateサブネットから外部通信したい場面って割とあるだろうし・・・

このLTでは、VPCエンドポイントを使って解決するべきだった。というオチで終わっています。確かにそうですね。

8/31追記

こちらの件、自分の認識が甘かった。

タスク定義でpublicなimageを指定した場合、ビルドの度にNATゲートウェイを通ってimageを取得しにいくから気をつけようねって話だった。

ごめんなさい。これは、初見じゃ気づかないわ。。。自分も気をつけます。

ECRには、プルスルーキャッシュという機能（publicなimageをprivateリポジトリに保存して、1日1回だけimageの更新が行われる）が追加されたので、

外部のimageを利用するときはこちらを使って実現しよう。

最後に

インフラ（AWS）のコストって、昨今の円安も相まってビジネス的にも重要性が増している気がします。

MVP的なノリで新規サービスのリソース作って、なんかめっちゃコストアラート鳴ってる〜〜、とかならないように自分も注意していきたいです。

【テックブログ】バックエンドエンジニアがPCをM2Proに変更してみた

テックブログ エンジニア

数ヶ月前に、勤務している会社でPCのリプレイス案内がきました。 ざっと、このようなリプレイスになります

  • 旧：MacBookProの15インチ（Intel CPU）
  • 新：MacBookProの14インチ（Apple Silicon）※ M2 Pro

今回は、Railsアプリのバックエンドを担当している場合に起こりうる影響を確認してみました。

Railsコンテナが、nokogiriのエラーで立ち上がらない問題

公式のRubyイメージを元にしてDockerfileを作成している場合、おそらくnokogiriでエラーが発生します。

$ docker-compose build --no-cache
（省略）
> ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:

直接の原因は、Rubyイメージにプリコンパイルされているnokogiriが参照したいファイルが足りていないからのようです。 ただもちろんこれは Apple Silicon に変更したからでしょう。

結論から言うと、bundle の platform を ruby に強制することで改善します。 自分はDockerfileの記述に下記を追加しました。

RUN bundle config set force_ruby_platform true

bundle の platformは、特に指定しない限り、ホストPCのプラットフォームになります。 つまり、M2Proだと arm64-darwin-22 という名称のプラットフォームとして、bundle は動作します。 おそらくこのplatformだとインストールされないファイルがnokogiriには必要なのだと思われます。

docker-compose up できない問題

Railsアプリ、皆さんの開発環境ではどのデータベースを利用していますでしょうか？多くの方が MySQL か PostgreSQL かと思います。

自分は MySQL を利用していて、docker-compose.yml ではmysql:8.0.28 を指定していました。 その環境で docker-compse up を実行した時に下記のエラーに遭遇しました。

docker-compose.ymlを下記のように修正し、MySQLは無事に立ち上がるようになりました。

$ docker-compose up
（省略）
> no matching manifest for linux/arm64/v8 in the manifest list entries

これは、mysql:8.0.28 のイメージに、AppleSilicon（arm64）に対応したものが存在しませんでした。というエラーです。 どうしてこのような動きになるかというと、イメージの取得はホストPCのプラットフォームに依存して行われるからです。 そのため、明示的にプラットフォームを指定する必要があります。

db:
    image: mysql:8.0.28
    platform: linux/x86_64 # 追加

その他トラブルシュート

もし改善されない場合、例えば Dockerfile がマルチステージビルド形式で記載されていて、記述が意図せz反映されていないなどを疑った方がいいかもしれません。

最後に

実は本業では Github Codespaces を利用しているため、PCリプレイスの影響は全くありませんでした（笑） M2 Proめちゃくちゃいいです。キーボードはタイプしやすいし、画面は綺麗で動作もサクサク。そして電池の持ちがすごいです！

【イベント感想】App Runner Night!! に参加してきました

イベント感想 エンジニア

目的

定期的にイベントに参加して、エンジニアとして意識を高く保とうと思ったのがきっかけです。 （よくイベントに参加している優秀なエンジニアが身近にいて、ケツを叩かれたのが実情）

「どんなイベントでもいいから出るぞ」とは思ったものの、実際どれにしようか迷った挙句、めちゃくちゃ置きにいった選択をしました（笑）

自分は「App Runner」を使ったサービスを運用しているため、とりあえず話についていけない事はないだろうと思ってポチりました。

イベント情報

イベント構成

  • 1部: AWSのマッシモさんによる、AppRunnerの基本機能説明
  • 2部: マッシモさんへの質疑応答
  • 3部: 有志によるAppRunner関連のLT会

感想（気になった事）

質疑応答で、こんな質問がありました

  • 「質問というかお気持ちなのですが、AppRunnerはWAFやSecretManagerなど、他サービスとのインテグレーションを増やしていますが、どちらかと言うとサービスを隠蔽するように機能追加されると嬉しいです」

自分も同感です。App Runnerの良いと思う所はいくつかありますが、例えばwebアプリが公開に至るために必要な機能が最低限揃っており、それらリソースが機能として内包されているところ、は真っ先に挙げられると思います。

これに対して回答を要約すると

  • 「妥当な意見だと思う。一方で柔軟性という観点から、リソースによってはインテグレーションによる連携という方向性でいる。ちなみにAWS CDKに、隠蔽という思想の一部を担ってもらう、ということも可能だと考えていて、引き続き内部でディスカッションを深めていくつもりだ」

うーん...正直言うとAWS CDKがあまり好きではなく、このアプローチはあまりやって欲しくないかなと個人的には思いました。 現状IaCのスタンダードはTerraformだと思っていて、自分もTerraformはかなり好きですし、Googleも推奨するmoduleを使ったベストプラクティス構成だと、環境ごとのリソース状況が見通しやすくて凄くいいんだよな...（脱線しすぎました）

皆さんはどう思ったんだろう・・・？

最後に

このブログ書いてて思ったんですが、「GCPのCloudRunをどのくらい意識していますか？」みたいな質問すれば良かった（笑）

ここ最近のApp Runnerのアップデートを見ると、おそらく相当CloudRunを意識しているし、AWSも力を入れてる気がしてます。IaaSは断然AWS派なので、是非とも頑張って欲しいです！また何かイベント参加したら記事にするつもりです。今回は以上にします！

ビール醸造所で働くエンジニアの自己紹介

エンジニア 雑談

自己紹介

はじめまして。 自分はWebアプリのエンジニアで、主にバックエンドを担当しています。 普段はRuby on Railsで作ったアプリケーションを、Docker環境で開発し、CI/CDで検証してデプロイし、AWSで運用しています。

本業ではないのですが、ビール醸造所のお手伝いをしています！ ビール醸造所って、めちゃくちゃアナログな世界なんです。その辺の苦労や、解決のために四苦八苦したことも書いていけたらと思っています。

新卒からエンジニアをしてるにも関わらず、30代になってようやく、バックエンドなら大体やれるなと感じはじめました。

でもハッキリ言います。自分はエンジニアとして とても平凡 です。 スポーツ選手を表すレーダーチャートが、もしエンジニア界隈にあるとするならばきっとこうです。

レーダーチャート

今はまさしく「ヘイボンジニア」ですが、「ヒボンジニア」へ成長できるよう頑張っていきます。

どんなコメントでも良いので、残してもらえると嬉しいです。