2020-12-27

2020年と社会人3年目の振り返り

人生

2020年

例のアレが流行ったこともあり、リモートワークが当たり前になり、インターンシップや面談など、全てがオンラインで完結されるようになった。（もうそろそろコロナ終わってほしい。）
そして、気がつけば私も社会人3年目になった。本当に早いな・・・。ざっくり3年目を振り返ると。

一人暮らし
投資
AWS
洋書
健康

一人暮らし

これまでの人生で一度も一人暮らしをやったことがなかった。学生時代は家から学校通ってたし、新卒の頃もシェアハウスで友人と住済んでいたし、本当に一人で暮らすという状況は初めてだった。（インターンの時とかのマンスリーマンションはノーカウント）

しかも、例のアレが流行り始めたのもあり、家で過ごす時間が圧倒的に増え、生活をいい感じにする必要が出てきた。
一人暮らしで、これはよかったな集を雑にまとめてみた。

自炊は適当にやれば続く
掃除が憂鬱だったので、家事代行を頼むようにした
ドラム式洗濯機は人生の時間を増やしてくれる
防音性の高い家を選んでよかった（隣人トラブルが起きにくい
ロボット掃除機が居ると部屋を片付ける

投資

一人暮らしを始めて、家計の収支管理がある程度回るようになったところで、投資を本格的にやり始めた。
最初は将来が心配だし、いつ失業するか分からないから、準備しておこうくらいのノリで始めたけど、だんだん楽しくなって、今では正直ゲーム感覚になっていたりする。ちなみに私が手を出している金融商品としては以下。

積立NISA
保険
不動産
投資信託
ETF
CFD

最初は怖かった時もあったけど、運用資金が100万を余裕で超えたあたりから、リスク管理の感覚やマインドセットなどが出来上がってきたのもあり、今ではお給料が入ってくると、そのまま投資に回すくらいのノリになった。

AWS

この一年間、無限にAWSに関連する仕事をしていた。

ネットワーク構成の改善
バッチ基盤のマルチリージョン化
IaCでゴリゴリ構築
AWSのセキュリティ施策系
データの分析基盤構築

要件を整理し、技術選定、アーキテクチャ設計、IaCで構築して、上に乗っかるアプリケーションも書いてがやれば出来るなっていう感覚が掴めた一年だった。

洋書

私は全くと言って良いくらい英語に必要な基礎的な教養がない。（海外旅行駆動でしか勉強しない）
これまではあまり困るケースに遭遇してこなかったけど（スタックオーバーフロー読めば良いくらいの問題で済んでた）、一切経験がないデータ周りの仕事をやり始めてから、まとまった情報がある洋書を読まざる得ない状況になり、嫌でも長文の英語を読むようになった。

実際読んでみるとなんとなくわかるし、最近はDeepLとか使えばだいたい分かるし、なんとかなるやん！ということが分かった。この体験のおかげで、発売されたばかりの話題の洋書の技術書とか、脳死でポチポチ出来るようになった。

健康

2020年最後くらいにハマったのが健康管理でした。元々1日1食（朝と昼はプロテインとかサプリしか摂らない）で生活していた。理由としては、適当にパクパク食べてると肌の不調が発生するので、食べる頻度を減らしてみたところ、いい感じやん！となり、1日1食になった。（人によっては体調崩すのでおすすめしない）
という話を会社の人にしたら、飢餓状態になっていることをえらい心配されたので、食の回数を増やしつつ、肌がぶっ壊れない方法を探すことにしてみた。とかやってたらハマっていったりしている。

ちなみに体調は、1日1食の時とそこまで変わりはない。色々見てるとわかったのが、健康管理方法には絶対はなく、体に合ったものを探すと良さそうと結論づいた。若い時は無理出来るので、1日1食とか1日5食とか世にある健康法を片っ端からやってみると良さそう。

※飢餓状態になることで、無駄に筋肉が分解されるのは嫌だなと思ったので、いまの食生活を維持するつもりである。

あすけんっていうアプリは簡単に栄養管理出来てよかった
おいしい完全食Baseパンいいぞ
- 招待リンク
タンパク質はプロテインで補った方が楽
- 招待リンク
家に懸垂マシン置くと、運動捗る

最後、アフィリエイトみたいになってるけど、普通に良いものなので、おすすめしておく。健康は大事だぞ！

来年の話

「やりたい」にもっと素直になる一年にしたいと思っている。例のアレが流行ってわかったけど、お金があっても旅行が突然できなくなることがある。いつでも出来るように見えることは、実は今しかできないかもしれない。「やりたい」と思った時にすぐやる。

あと、来年もよろしくおねがいします。

2019-01-11

AWS ECRのuntaggedを定期的に消す（シェルスクリプト）

AWS ECR

定期的にuntaggedを消したい

f:id:tikasan0804:20190111145141p:plain

jenkinsなどで、以下のコードを定期実行するだけ。
コードのrepository idはECRのコンソールから確認してコピってください。

f:id:tikasan0804:20190111143756p:plain

echo start
aws ecr get-login --no-include-email --region ap-northeast-1 --registry-ids !ここにrepository id!

aws ecr describe-repositories --output text | awk '{print $5}' \
  | while read rname; do echo $rname; aws ecr list-images --repository-name $rname --filter tagStatus=UNTAGGED --query 'imageIds[*]' --output text \
  | while read imageId; do aws ecr batch-delete-image --repository-name $rname --image-ids imageDigest=$imageId; \
  done; \
done
echo done

ライフサイクルでもよかったけど、毎度人間が設定するとは思えなかったので、却下した。 docs.aws.amazon.com

2018-12-30

ScalaをIntelliJ IDEAで使う時の設定

f:id:tikasan0804:20181230153057p:plain

Pluginインストール

Preferences | Plugins | Scala

f:id:tikasan0804:20181230155011p:plain

sbt設定

Preferences | Build, Execution, Deployment | Build Tools | sbt

$ brew cask install caskroom/versions/java8
$ /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands/java_home -v “1.8”
/Library/Java/JavaVirtualMachines/openjdk-11.0.1.jdk/Contents/Home

JREの設定に、上で取得したパスを入れる。他の設定は適当にお好み。

f:id:tikasan0804:20181230154755p:plain

PATHも通す（必要に応じて）

JAVA_HOMEに1.8に設定し、パスを通す。

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
export PATH=$JAVA_HOME/bin:$PATH

2018-12-26

CloudWatch Logs Insights 使い方と注意点(Go)

AWS CloudWatch インフラログ

f:id:tikasan0804:20181226194654p:plain

高速でインタラクティブなログ分析!!!!

新機能 – Amazon CloudWatch Logs Insights – 高速でインタラクティブなログ分析 | Amazon Web Services ブログ

仕事で導入する機会があり、その時の使用感とハマりポイントをまとめてみました。

ユースケース

ログがレコード数6,500,000/1時間くらいあるものから、特定の文字列にヒットするものを取得したい。フルスキャンしなくていいので、1日の中から10件の対象ログを探したい。

使用感や注意点

※利用したログでの使用感です

日付の範囲を1日とかにすると、そこまで早くない（検索完了まで3分〜4分はかかった）
従来のログ検索だと、5分のレンジで検索しても、15分以上かかっていたけど、Insightsなら、10秒程度で検索が完了した
リアルタイムに何か検知するのは無理。インデックスを作成しているか何かで、3分くらい経たないと検索結果に出てこなかった（インデックスが済むと速い）
リアルタイムに検知したいなら、サブスクリプションフィルタのが優れている
検索結果が返ってくるまでの状態管理に、少しコツが必要だった（コードで説明する）
limitがクエリにも、APIのインターフェイスにも用意されてるけど、使い分けが分からない
フルスキャンして、高速検索はBigQueryでやろう

Goでの実装例

今回は、Golangで実装した例です。動作などは、godocを見れば、大体雰囲気わかります。
cloudwatchlogs - GoDoc

github.com

全体の流れ

StartQueryInput でクエリを作成する
StartQuery に StartQueryInput に渡し、queryId を受け取る（この時、既にクエリが実行開始している）
GetQueryResults を実行して、実行中のクエリの結果を受け取る
実行中のクエリのステータスを見て、結果を返すか決める（あとで、取り上げる）
結果を返す

4. 実行中のクエリのステータスを見て、結果を返すか決める

https://github.com/pei0804/go-cloud-watch-logs-insights/blob/be35e2e44d010a8fbc7764a07e6b74a23d12b650/main.go#L85-L118

func getQueryResultsUntilCompleate(cwl *cloudwatchlogs.CloudWatchLogs, queryId string, limit int) (*cloudwatchlogs.GetQueryResultsOutput, error) {
    getQueryResultInput := &cloudwatchlogs.GetQueryResultsInput{}
    getQueryResultInput.SetQueryId(queryId)
    for {
        getQueryResultOutput, err := cwl.GetQueryResults(getQueryResultInput)
        if err != nil {
            return nil, err
        }
        time.Sleep(5 * time.Second)
        switch *getQueryResultOutput.Status {
        case "Running":
            if len(getQueryResultOutput.Results) < limit {
                continue
            }
            stopQueryInput := &cloudwatchlogs.StopQueryInput{}
            stopQueryInput.SetQueryId(queryId)
            stopResult, err := cwl.StopQuery(stopQueryInput)
            if err != nil {
                return nil, fmt.Errorf("stop query error=%s status=%v", err.Error(), stopResult)
            }
            return getQueryResultOutput, nil
        case "Scheduled":
            continue
        case "Failed":
            return nil, errors.New("job failed")
        case "Cancelled":
            return nil, errors.New("job cancelled")
        case "Complete":
            return getQueryResultOutput, nil
        default:
            return nil, fmt.Errorf("unknown status: %s", *getQueryResultOutput.Status)
        }
    }
}

なぜ、forループで待ち続けているのか

StartQuery を実行すると、クエリが走り始めます。そして、GetQueryResults でクエリの状態を取得します。この時点では、完了していないことがほとんどです。そのため、time.Sleep(5 * time.Second) などして、少し時間を置いてから再度取得しています。

ログの量にもよりますが、何周かすると、終了し、Completeに入ります。ステータスの種類はドキュメントに書いてあります。
GetQueryResults - Amazon CloudWatch Logs

Runningで途中でreturnしているのは？

途中でlimit来たら返しているかというと、全部見なくて良いので、あった結果をとりあえず、早く返してほしかった。

1日くらいのレンジで見ていたので、全部見るの待つと、とても時間がかかる
limit 10と設定していても、10件あったらCompleteではなく、全部の結果を受け取った上で、ソートし直すなどをしてるっぽく、指定範囲をフルスキャンになり、時間がかかってしまう

2018-12-10

Bonfire Backend #2 参加レポート

f:id:tikasan0804:20181209172453p:plain

yj-meetup.connpass.com

イベントの参加レポートです。スライドを見ればわかる内容はここでは書きません。

Apache Kafkaによるログ転送とパフォーマンスチューニング

Apache Kafkaによるログ転送とパフォーマンスチューニング - Bonfire Backend #2 - from Yahoo!デベロッパーネットワーク

www.slideshare.net

この発表では、Kafkaについての発表でしたが、起きた問題については、リクエスト数が多いサービスなどでは、既知感のある課題でした。
僕もいまの会社で似たような問題に直面したことがあり、チューニングするなどをしたことがあったのですが、やっぱ、人々はログストリームどうする問題に直面しているんだな・・・って気持ちになった。

スライドでは、細かい仕様が示されてなかったので、サービスの特徴は想像するしかなかったのですが

Producerの数減らせない
Partitionを減らせない
タイムアウトを長くできない

などの制限があったそうで、なかなか、面倒そうだと思う一方で、Kafkaはかなり色んな便利機能を用意してくれてるんだなーということが分かった。弊社では、ほとんどのサービスをAWSで構築しているので、Kinesisに比べてKafkaどうなんだろう？とか気になっていたので、ちょうど色々話が聞けてよかった。

Better docker image+

speakerdeck.com

Dockerについて、ひたすら語る発表でした。たまたま、EC2などで動いていたサービスをコンテナ化をして、Fargateで動かすなどをしていたので、Dockerのベストプラクティス周りの話を聞けてよかった。特にこれから、Docker使っていくぞい！って人にはかなりおすすめな内容でした。

curlやwgetで何か取得する時に遅い問題に対して、並列ダウンロードで解決するは、盲点だった
buildkitをとりあえず使ってみよう
dockerについてここまでやり込むのは単純にすごいと感じたｗ

Akka streamsを活用したログ集計に優しいデータフローの構築

speakerdeck.com

adtech studioのログ集計で、Akka streamsを使った話でした。僕も現在、アドの開発、運用に携わっているのですが、あまり他社の実装例を見る機会がなかったので、興味深い内容でした。

既存の置き換えに、Firehoseってそのまま使えないのわかる
便利そうだけど、Akka stremesの管理コストとかどうなんだろとか、いちいち思う自分は、フルマネージドサービスを使って済ませたい側の人なんだなと聞いていて感じた

広告配信サービスにおけるパフォーマンス対策、やるかやらないか

speakerdeck.com

弊社のCTOの @katzchang による発表でした。内容としては、パフォーマンスチューニングに対する取り組みについての、現場感のある発表でした。
実際のところどうなの？って話ですが、弊社の開発のノリそのままです。

この発表を聞いて、改めて実感した弊チームの良い点は、 アイデアを試せる権限を与える でした。配属されてから、当たり前のように本番環境へのデプロイをしたり、本番で計測してみたりを、この前まで学生だったひよっこエンジニアにも出来るように権限が与えられている点です。これによって、改善しようと思えば出来るという環境が整っていることです。

最初は、本番に何かするというのは、恐怖に近い感覚を持ちましたが、いまはそれが出来るお陰で、スピード感を保って開発が出来ているんだなと確信している。

SpeedCurveを駆使した継続的なパフォーマンス改善

Bonfire Backend #2 継続的なパフォーマンス改善 from Yahoo!デベロッパーネットワーク

www.slideshare.net

パフォーマンスの改善したいけど、わりと大変だったりするし、何か新しい機能が増えるわけではないので、実際やろうと思うと、色々ビジネス観点のメリット見えにくいから進めにくいですよね？みたいな話でした。

技術者目線、サービス目線を見て、両者が納得をもって進めれるWin Winの仕組みがあるそうで、それは、サービスのKPIとパフォーマンスの因果関係を証明すれば、改善しても良い というものでした。企業規模の大きい会社でも、フットワーク軽く動けるように、仕組み化までしていて、素直にすごいなと感じた。

感想

東京に来てから、わりと知識欲が満たされがちで、勉強会を開催するも、参加することがあまりなかった僕ですが、友人が中心となって主催していたことや、弊チームのCTOが発表することもあり参加しました。
全体的に自分にとってタイムリーな話題や、気になっていたことが発表で出てきたりと、最初から最後まで楽しめた。また、バックエンドと題しているだけあって、踏み込んだ話が多かったのも良かった。（個人的にはもっと具体的な話でも良いくらい

運営のみなさま、お疲れ様でした。また、参加出来そうなら参加したいと思います。

2018-10-23

絶対に仕事を安請けしない

仕事

安請け合い・安請合い

（名）スル
確信もないのに請け合うこと。また、軽々しく引き受けること。「－して後で困る」

大体出来るけど、安請けしない

仕事をやっていると、「これ出来る？」という話が結構出てくる。大体出来るんだけど、すぐに「やるよ」とは絶対に言わない。

課題解決は大小問わず、脳が疲れる

何も考えずに「やるよ」としてしまうと、いま進めているメインタスクから、脳を切り替える必要がある。個人的に違う仕事に切り替えるは、スーパー重い処理だと感じている。もし、そのタスクが終わったとしても、削れた集中力はもう戻ってこない。

※緊急度の高いバグとかは別です。時間問わず対応します。

「やるよ」ではなく、「なんでやるの？」を議論する

既存の仕組みでなんとかなることもあるので、すぐ出来る解決策を検討する。既存の仕組みだと出来ない場合は、「なんでやるの？」をヒアリングする。そして、絶対やった方がいい！ってなったら、やる。かもしれない。それくらい、何かの仕事を中断してまでやるってのは重い決断だと思っている。

やるとき

大体の場合、メインで進めているタスクが終わったら、次やろっかに落ち着くことが多い。けど、それで良いことが多い。なんでかっていうと、既に優先度が高い仕事をやっているので、逆転することはそうそう起きない。

2018-10-09

半年間の社会人生活で学んだこと

仕事

社会で生きてみた

VOYAGE GROUP、Zucksでの社会人の半年を振り返りをしてみた。

技術

がっつりとか、少しとか色々あるけど、本当たくさん経験が出来た。

Go
Scala
Lisp
PHP
Python
BigQuery
HTML
CSS
JS
- React
- Angular
- Vue
AWS
- Lambda
- EC2
- Batch
- ECS
- Fargate
- S3
- Dynamo
- なんかもう色々
CI
- CircleCI
- Jenkins
Packer
Docker
Vagrant
なんか色々あった気がする

経験したこと

リリース作業
リバート作業
設計
コーディング
ヒアリング
レビュー
ミーティング

配属当初は本当に色々あった

うまくコミュニケーションが取れずに手間取る
設計の掘り下げが甘くて手戻り
リリース作業心労し過ぎて腹痛
諸問題で何回もリバートしたりした
体調バグりがち
リリース作業中エラー起きたらパニクる
周りが優秀過ぎて、自分の意見に自信が持てない

変わったこと

リリース前に最悪のケースを想定する
コードを書く前に具体的な設計を練って、相談をして手戻りなくす
結果を出すことに執着し過ぎず、多少時間かかっても、確実に終わらせることに集中する
しんどい時は、帰る
起きた時にしんどい時は、諦めて寝る
家で勉強する習慣をやめた（本当に必要だと思うものだけ勉強する）
人が言ったことを鵜呑みせず、本当か？って姿勢で議論する
頑張ってるという感覚までやるのをやめた（自分の場合、やりすぎになっている）

残りの半年間やっていきたいこと

いつも、最高のパフォーマンスで業務に臨める時間を作れるように、良い感じに生活する。