id:cohalzです．2018年8月付で株式会社はてなに入社しました．
職種はSRE (Site Reliability Engineer) で，勤務地は京都です．
まえがき
はてなとの出会いは、2017年のはてなインターンに参加したことがきっかけでした。 はてなインターンの特徴の一つに、ほとんどの参加者が参加したときの内容をブログ記事として書いていることがあります。インターン参加記事には、技術やWebに対する大きな熱量がこもっており、すっかり自分もWeb技術をやっていくのだと感化されました。 ダメ元で選考に望んだところ、運良く選考通過のお知らせをいただいてとてもうれしかったことを今もよく覚えています。 そこから毎年インターンの参加者をみてきていますが、とてもハイレベルで、よく自分が選考通過したものだと今でも思います。 この出来事が自身の人生にとって大きな転機だったと言えるでしょう。
インターンの2ヶ月後にアルバイトスタッフとして入社し、配属されたのは、はてなのITインフラを担当するシステムプラットフォーム部という部署でした。 今でこそ当たり前のようにSREのような基盤技術を専門としていますが、当時はサービス開発をするアプリケーションエンジニアを志望していました。 しかし、システムプラットフォーム部での仕事を通して、サーバがたくさんあってそれらが相互に通信してひとつの系をなすというWebシステムに魅せられ、今でいうところのSREを志しました。インターン中に行われた
id:masayoshi さんによるインフラ講義に感銘を受けたことも影響しています。はてなでインフラ研修を受けました - Re:cohalz の記事にて、アルバイト時代に、何を学んだかを書いています。 そこから新卒で内定をいただいたにも関わらず、大学院を中途退学してしまいましたが、その後も快く受け入れてくださったはてなにはとても感謝しています。*1
正社員として入社してから既に半年以上，アルバイトを含めると1年以上はてなで働いていたので，この機会に振り返ってみようと思います．
アルバイト時代
アルバイトとして入社した2017年11月時点では，ミドルウェア，Linux，クラウドサービスのことは何もわからない状態でした．
そんな中，最初にアサインされたタスクはLet's Encrypt証明書を自動で取得・更新するという基盤作成のタスクでした．
このタスクをアサインされた当時の状態でわからないことで言うと，
- Let's Encryptって怪しいものだと思っていた．
- AWS CLIはおろかAWS自体何一つ触ったこと無い
- 何をしたらどういった変化が起こるのかわからず，とにかく操作が怖い
- webサーバってどうやって立てるの？
- セキュリティグループってやつで80番開放したら立つのかと思ってた
- nginxはなんて読むのかは知ってるけど何なのか知らない
と言うレベルで，とにかく1から進めていきました．
そんな状態で本当にやっていけるのか，もちろん不安ではありました．
しかし，所属していたチームの座談会を見たところ，その不安はなくなりました．
この記事では，当時アルバイトメンターをしてくれていた 
id:dekokun さんや，まだ新卒入社して年数の経っていない 
id:taketo957 さんや，雲の上の存在だった 
id:y_uuki さんまでも昔からインフラに詳しいわけではなかったという事実が助けになりました．
アルバイトでは研修と，AWSを中心とした運用・基盤作成を主なタスクとしていました．
研修の内容については上に書いてありますが，その結果Chefやkeepalivedなどのオペレーションはできるようになり，関連ツールも作成することもありました．
研修内容は入社した今でも役に立っていて，最近ではアプリケーションエンジニアにkeepalivedの挙動を教えたり，同じチームとなった 
id:hokkai7go さんにChefを教えるといった事もありました．
AWSについてもどんどん理解を深めていき，入社前には既にLambdaを利用した基盤ツールを多く作成できました．
上に書いたLet's Encrypt証明書の基盤もLambdaで動いており，ブログに書いたところ，大きな反響があって嬉しかったのを覚えています．
ちなみに，今年の1月に行われた「Hatena Engineer Seminar #11」にて発表した内容はすべてアルバイト時代に作成したものになります．
資料はこちらです．
入社後
8月に正社員として入社して，初めて渡されたタスクはかなり印象に残っています．
タスクはデータセンターで使っているサービスのログ経路を変更するというものでした．
近い内にでログを保存しているホストのストレージが枯渇するため，それまでにディスクの交換が必要になっていました．
そしてそのディスクを交換する作業というのは大変だったので，「そのホストを使わないような配送経路を作成し切り替えることでディスク交換を不要にする」ということを行いました．
結果的にできた配送の仕組みとしては単純にcronでS3に定期的にアップロードするというだけでしたが，難しいところがいくつかありました．
例としては，
- アクセスログも含まれているので欠損してはならない
- 配送に問題があったことを気がつけるようにしたい
- ログの配送によってネットワーク帯域を潰してはいけない
欠損の対策として，S3側ではクロスリージョンレプリケーションを利用しました．
また，S3にアップロードする際にエラーが起こった場合，ファイルが欠損することはあるのか，という部分についても検証を行ってから進めました．
また，ログ配送の際にエラーが起きていると配送元のディスク容量枯渇したり，欠損が起きる可能性があったので監視設定も追加しました．
監視ではcron実行時にエラーが起きていないか，そもそもcronが実行されているのか気がつけるように，horensoとMackerelのチェック監視(check-file-age)を組み合わせて監視を行いました，
これによりcronの成否確認およびcron自体が実行されているかの確認が行えるようになりました．
ネットワーク帯域に関しては，様々なサービスのログが流れてくるというものもあり，S3にアップロードする際に帯域を潰さないように配慮する必要がありました．
aws cliでの帯域制御や社内で利用しているフォワードプロキシを利用することで，帯域に配慮したログ配送を実現しました．
以上により配送経路の変更が完了し，今まで使っていたストレージにログが転送されないことが確認できました．
また，この作業と並行して，はてなインターン2018において，前半後半どちらともメンター業も行いました．
後半過程ではアプリケーションをコンテナで動かすための検証をインターン生と一緒に行っていました．
この当時はコンテナやECS/Fargateについて全然知らなかったのですが，この検証をもとに社内でコンテナ化を進めていこうという気持ちになりました．
そしてありがたいことに，現在では社内でコンテナ化を進めていくプロジェクトのメインエンジニアとして活動をしています．
そしてつい最近に，本番で稼働しているアプリケーションの一つをコンテナ化・ECS移設を無事成功することができました．
コンテナ化以外の活動としては，AWS CDKというアプリケーションに興味を持ち，バグ報告やプルリクエストなども積極的に行っているというのがあります．
Issues · awslabs/aws-cdk · GitHub
AWS CDKを使って社内用のECSクラスタを簡単に作成するライブラリを作るなどもしていました．
これらのように，今までインフラ側ではなくアプリケーションのコードを書いていた経験が生きていると感じる事が増えていて，こんな自分でも役に立つことがあるんだと思うようになってきました．
アルバイト入社当時は「自分はこんなにインフラのこと何もわからないのに役に立つとは思えなかった」のですが，以上の経験からある程度のインフラ知識を獲得し，さらに元々ある程度持っていたコードを書く能力が合わさり，自分の強みとなりつつあるのを感じています．
こんな何もできなかった自分を拾ってくれてありがとうございます．
これからもよろしくお願いします．
