2020年と社会人3年目の振り返り
2020年
例のアレが流行ったこともあり、リモートワークが当たり前になり、インターンシップや面談など、全てがオンラインで完結されるようになった。(もうそろそろコロナ終わってほしい。)
そして、気がつけば私も社会人3年目になった。本当に早いな・・・。ざっくり3年目を振り返ると。
- 一人暮らし
- 投資
- AWS
- 洋書
- 健康
一人暮らし
これまでの人生で一度も一人暮らしをやったことがなかった。学生時代は家から学校通ってたし、新卒の頃もシェアハウスで友人と住済んでいたし、本当に一人で暮らすという状況は初めてだった。(インターンの時とかのマンスリーマンションはノーカウント)
しかも、例のアレが流行り始めたのもあり、家で過ごす時間が圧倒的に増え、生活をいい感じにする必要が出てきた。
一人暮らしで、これはよかったな集を雑にまとめてみた。
- 自炊は適当にやれば続く
- 掃除が憂鬱だったので、家事代行を頼むようにした
- ドラム式洗濯機は人生の時間を増やしてくれる
- 防音性の高い家を選んでよかった(隣人トラブルが起きにくい
- ロボット掃除機が居ると部屋を片付ける
投資
一人暮らしを始めて、家計の収支管理がある程度回るようになったところで、投資を本格的にやり始めた。
最初は将来が心配だし、いつ失業するか分からないから、準備しておこうくらいのノリで始めたけど、だんだん楽しくなって、今では正直ゲーム感覚になっていたりする。ちなみに私が手を出している金融商品としては以下。
最初は怖かった時もあったけど、運用資金が100万を余裕で超えたあたりから、リスク管理の感覚やマインドセットなどが出来上がってきたのもあり、今ではお給料が入ってくると、そのまま投資に回すくらいのノリになった。
AWS
この一年間、無限にAWSに関連する仕事をしていた。
- ネットワーク構成の改善
- バッチ基盤のマルチリージョン化
- IaCでゴリゴリ構築
- AWSのセキュリティ施策系
- データの分析基盤構築
要件を整理し、技術選定、アーキテクチャ設計、IaCで構築して、上に乗っかるアプリケーションも書いてがやれば出来るなっていう感覚が掴めた一年だった。
洋書
私は全くと言って良いくらい英語に必要な基礎的な教養がない。(海外旅行駆動でしか勉強しない)
これまではあまり困るケースに遭遇してこなかったけど(スタックオーバーフロー読めば良いくらいの問題で済んでた)、一切経験がないデータ周りの仕事をやり始めてから、まとまった情報がある洋書を読まざる得ない状況になり、嫌でも長文の英語を読むようになった。
実際読んでみるとなんとなくわかるし、最近はDeepLとか使えばだいたい分かるし、なんとかなるやん!ということが分かった。この体験のおかげで、発売されたばかりの話題の洋書の技術書とか、脳死でポチポチ出来るようになった。
健康
2020年最後くらいにハマったのが健康管理でした。元々1日1食(朝と昼はプロテインとかサプリしか摂らない)で生活していた。 理由としては、適当にパクパク食べてると肌の不調が発生するので、食べる頻度を減らしてみたところ、いい感じやん!となり、1日1食になった。(人によっては体調崩すのでおすすめしない)
という話を会社の人にしたら、飢餓状態になっていることをえらい心配されたので、食の回数を増やしつつ、肌がぶっ壊れない方法を探すことにしてみた。とかやってたらハマっていったりしている。
ちなみに体調は、1日1食の時とそこまで変わりはない。色々見てるとわかったのが、健康管理方法には絶対はなく、体に合ったものを探すと良さそうと結論づいた。若い時は無理出来るので、1日1食とか1日5食とか世にある健康法を片っ端からやってみると良さそう。
※飢餓状態になることで、無駄に筋肉が分解されるのは嫌だなと思ったので、いまの食生活を維持するつもりである。
最後、アフィリエイトみたいになってるけど、普通に良いものなので、おすすめしておく。健康は大事だぞ!
来年の話
「やりたい」にもっと素直になる一年にしたいと思っている。例のアレが流行ってわかったけど、お金があっても旅行が突然できなくなることがある。いつでも出来るように見えることは、実は今しかできないかもしれない。「やりたい」と思った時にすぐやる。
あと、来年もよろしくおねがいします。
AWS ECRのuntaggedを定期的に消す(シェルスクリプト)
定期的にuntaggedを消したい
jenkinsなどで、以下のコードを定期実行するだけ。
コードのrepository idはECRのコンソールから確認してコピってください。
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
ScalaをIntelliJ IDEAで使う時の設定
Pluginインストール
Preferences | Plugins | Scala
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の設定に、上で取得したパスを入れる。他の設定は適当にお好み。
PATHも通す(必要に応じて)
JAVA_HOMEに1.8に設定し、パスを通す。
export JAVA_HOME=`/usr/libexec/java_home -v 1.8` export PATH=$JAVA_HOME/bin:$PATH
CloudWatch Logs Insights 使い方と注意点(Go)
高速でインタラクティブなログ分析!!!!
新機能 – 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
全体の流れ
StartQueryInput
でクエリを作成するStartQuery
にStartQueryInput
に渡し、queryId
を受け取る(この時、既にクエリが実行開始している)GetQueryResults
を実行して、実行中のクエリの結果を受け取る- 実行中のクエリのステータスを見て、結果を返すか決める(あとで、取り上げる)
- 結果を返す
4. 実行中のクエリのステータスを見て、結果を返すか決める
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ではなく、全部の結果を受け取った上で、ソートし直すなどをしてるっぽく、指定範囲をフルスキャンになり、時間がかかってしまう
Bonfire Backend #2 参加レポート
イベントの参加レポートです。スライドを見ればわかる内容はここでは書きません。
Apache Kafkaによるログ転送とパフォーマンスチューニング
www.slideshare.net
この発表では、Kafkaについての発表でしたが、起きた問題については、リクエスト数が多いサービスなどでは、既知感のある課題でした。
僕もいまの会社で似たような問題に直面したことがあり、チューニングするなどをしたことがあったのですが、やっぱ、人々はログストリームどうする問題に直面しているんだな・・・って気持ちになった。
スライドでは、細かい仕様が示されてなかったので、サービスの特徴は想像するしかなかったのですが
- Producerの数減らせない
- Partitionを減らせない
- タイムアウトを長くできない
などの制限があったそうで、なかなか、面倒そうだと思う一方で、Kafkaはかなり色んな便利機能を用意してくれてるんだなーということが分かった。 弊社では、ほとんどのサービスをAWSで構築しているので、Kinesisに比べてKafkaどうなんだろう?とか気になっていたので、ちょうど色々話が聞けてよかった。
- AWS での Apache Kafka – アマゾン ウェブ サービス
- Amazon KinesisとApache Kafkaの類似点/相違点まとめ - 夢とガラクタの集積場
- KafkaとAWS Kinesisの比較
Better docker image+
Dockerについて、ひたすら語る発表でした。たまたま、EC2などで動いていたサービスをコンテナ化をして、Fargateで動かすなどをしていたので、Dockerのベストプラクティス周りの話を聞けてよかった。 特にこれから、Docker使っていくぞい!って人にはかなりおすすめな内容でした。
- curlやwgetで何か取得する時に遅い問題に対して、並列ダウンロードで解決するは、盲点だった
- buildkitをとりあえず使ってみよう
- dockerについてここまでやり込むのは単純にすごいと感じたw
Akka streamsを活用したログ集計に優しいデータフローの構築
adtech studioのログ集計で、Akka streamsを使った話でした。僕も現在、アドの開発、運用に携わっているのですが、あまり他社の実装例を見る機会がなかったので、興味深い内容でした。
- 既存の置き換えに、Firehoseってそのまま使えないのわかる
- 便利そうだけど、Akka stremesの管理コストとかどうなんだろとか、いちいち思う自分は、フルマネージドサービスを使って済ませたい側の人なんだなと聞いていて感じた
広告配信サービスにおけるパフォーマンス対策、やるかやらないか
弊社のCTOの @katzchang による発表でした。内容としては、パフォーマンスチューニングに対する取り組みについての、現場感のある発表でした。
実際のところどうなの?って話ですが、弊社の開発のノリそのままです。
この発表を聞いて、改めて実感した弊チームの良い点は、 アイデアを試せる権限を与える でした。配属されてから、当たり前のように本番環境へのデプロイをしたり、本番で計測してみたりを、この前まで学生だったひよっこエンジニアにも出来るように権限が与えられている点です。これによって、改善しようと思えば出来るという環境が整っていることです。
最初は、本番に何かするというのは、恐怖に近い感覚を持ちましたが、いまはそれが出来るお陰で、スピード感を保って開発が出来ているんだなと確信している。
SpeedCurveを駆使した継続的なパフォーマンス改善
www.slideshare.net
パフォーマンスの改善したいけど、わりと大変だったりするし、何か新しい機能が増えるわけではないので、実際やろうと思うと、色々ビジネス観点のメリット見えにくいから進めにくいですよね?みたいな話でした。
技術者目線、サービス目線を見て、両者が納得をもって進めれるWin Winの仕組みがあるそうで、それは、サービスのKPIとパフォーマンスの因果関係を証明すれば、改善しても良い というものでした。企業規模の大きい会社でも、フットワーク軽く動けるように、仕組み化までしていて、素直にすごいなと感じた。
感想
東京に来てから、わりと知識欲が満たされがちで、勉強会を開催するも、参加することがあまりなかった僕ですが、友人が中心となって主催していたことや、弊チームのCTOが発表することもあり参加しました。
全体的に自分にとってタイムリーな話題や、気になっていたことが発表で出てきたりと、最初から最後まで楽しめた。また、バックエンドと題しているだけあって、踏み込んだ話が多かったのも良かった。(個人的にはもっと具体的な話でも良いくらい
運営のみなさま、お疲れ様でした。また、参加出来そうなら参加したいと思います。
絶対に仕事を安請けしない
( 名 ) スル
確信もないのに請け合うこと。また、軽々しく引き受けること。 「 -して後で困る」
大体出来るけど、安請けしない
仕事をやっていると、「これ出来る?」という話が結構出てくる。大体出来るんだけど、すぐに「やるよ」とは絶対に言わない。
課題解決は大小問わず、脳が疲れる
何も考えずに「やるよ」としてしまうと、いま進めているメインタスクから、脳を切り替える必要がある。個人的に違う仕事に切り替えるは、スーパー重い処理だと感じている。もし、そのタスクが終わったとしても、削れた集中力はもう戻ってこない。
※緊急度の高いバグとかは別です。時間問わず対応します。
「やるよ」ではなく、「なんでやるの?」を議論する
既存の仕組みでなんとかなることもあるので、すぐ出来る解決策を検討する。既存の仕組みだと出来ない場合は、「なんでやるの?」をヒアリングする。そして、絶対やった方がいい!ってなったら、やる。かもしれない。それくらい、何かの仕事を中断してまでやるってのは重い決断だと思っている。
やるとき
大体の場合、メインで進めているタスクが終わったら、次やろっかに落ち着くことが多い。けど、それで良いことが多い。なんでかっていうと、既に優先度が高い仕事をやっているので、逆転することはそうそう起きない。
半年間の社会人生活で学んだこと
社会で生きてみた
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
- なんか色々あった気がする
経験したこと
- リリース作業
- リバート作業
- 設計
- コーディング
- ヒアリング
- レビュー
- ミーティング
配属当初は本当に色々あった
- うまくコミュニケーションが取れずに手間取る
- 設計の掘り下げが甘くて手戻り
- リリース作業心労し過ぎて腹痛
- 諸問題で何回もリバートしたりした
- 体調バグりがち
- リリース作業中エラー起きたらパニクる
- 周りが優秀過ぎて、自分の意見に自信が持てない
変わったこと
- リリース前に最悪のケースを想定する
- コードを書く前に具体的な設計を練って、相談をして手戻りなくす
- 結果を出すことに執着し過ぎず、多少時間かかっても、確実に終わらせることに集中する
- しんどい時は、帰る
- 起きた時にしんどい時は、諦めて寝る
- 家で勉強する習慣をやめた(本当に必要だと思うものだけ勉強する)
- 人が言ったことを鵜呑みせず、本当か?って姿勢で議論する
- 頑張ってるという感覚までやるのをやめた(自分の場合、やりすぎになっている)
残りの半年間やっていきたいこと
いつも、最高のパフォーマンスで業務に臨める時間を作れるように、良い感じに生活する。