ぺい

渋谷系アドテクエンジニアの落書き

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

定期的に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

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

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

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

全体の流れ

  1. StartQueryInput でクエリを作成する
  2. StartQueryStartQueryInput に渡し、queryId を受け取る(この時、既にクエリが実行開始している)
  3. GetQueryResults を実行して、実行中のクエリの結果を受け取る
  4. 実行中のクエリのステータスを見て、結果を返すか決める(あとで、取り上げる)
  5. 結果を返す

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ではなく、全部の結果を受け取った上で、ソートし直すなどをしてるっぽく、指定範囲をフルスキャンになり、時間がかかってしまう

Bonfire Backend #2 参加レポート

f:id:tikasan0804:20181209172453p:plain

yj-meetup.connpass.com

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

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

www.slideshare.net

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

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

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

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

Better docker image+

speakerdeck.com

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

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

Akka streamsを活用したログ集計に優しいデータフローの構築

speakerdeck.com

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

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

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

speakerdeck.com

弊社の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
  • なんか色々あった気がする

経験したこと

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

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

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

変わったこと

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

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

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

「するべき」というパワーワード

あまり強い言葉を遣うなよ

tikasan.hatenablog.com

以前アップした記事にあった「するべきこと」に対してのコメント @ 弊社Slackの個人チャンネル

f:id:tikasan0804:20181006135912p:plain

自分はあまり気にせず使ってしまっていたので、何故だろう?を考えてみた。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

参考資料として貼ってもらった記事を雑に翻訳。

medium.com

「するべき」または「すべきではない」の濫用。 例えば、我々は中断してはならない... 。

中身がなく意味がないレトリック。
「私達は皆、豊かでなければならない。」
「本当に?私達はより良い新しい車を持ってる必要がありますか?」

実は、私達が”すべき”を使う時、目の前の現実を受け入れていません。実際にシステムを見ていません。スタートが基本的な透明性が失われいる場合、どのようにして、効果的な変化を望むことが出来ますか?

”すべき”はいまの既存バージョンの理想郷の説明することが出来ます。それは私達が目指している場所の表現として良いかもしれません。Kataのアプローチは、”すべき”というシチュエーションを打ち消し、コーチングするのに有効なテクニックです。

Abuse of “should“ or “shouldn’t” e.g. We shouldn’t have interruptions…”

More empty rhetoric. We should all be rich, am I right? We should all have better, newer cars, ya get me?

The thing is, when we use the word ‘should’ we are not accepting the reality in front of our faces. We are not seeing the system as it really is. If our starting point lacks this basic transparency, how can we ever hope to be effective change agents?

‘Should’ can describes a utopian version of an existing scenario. That might be a good expression of where we want to get to. The kata approach can be a good technique to counter and coach these ‘should’ situations.

Kataとは、日本のTOYOTAの行っている型というアプローチのことらしいです。
わかりやすい記事があったので紹介させていただきます。

radiocat.hatenablog.com

  • 問題を取り上げる
    優先度の高い問題を見つける
  • 状況把握(行って見る)
    問題の発生点を見つけても台を明確にする…問題の発生点を見るけるまでは対策に入らない
  • 原因を調査
    5回の「なぜ」を行う
  • 対策をつくり試験する
    一度に1つしか変えない
  • フォローアップ
    ふりかえり

”すべき”というワードを使うことで安心をしていた

色々読んでわかったのが、すべきと言っておけば、それっぽいことしてる風に聞こえる。それが中身のないことだったとしても強いワードはパワーを持ってしまう。”すべき”はすぐに使わずに、実際に問題を直視し、見たものから状況から判断する。そうすることで、勝手にやったほうが良さそうなことが見えてくる。

”すべき” を使いすぎ。だめ絶対!