Snowflake のリソースモニター通知を Slack で受け取る

Snowflake にはコスト管理や予期しない使用状況回避のためにリソースモニターという仕組みがあるが、
現状アカウント管理者に Web インターフェイスまたはメールを通してのみ通知される点がちょっと使いづらい。
というわけで、この通知を Slack に流して誰でも確認できるようにしているよという tips メモを残しておく。

Slack にはチャンネルにメールを流す仕組みがあるので、これを使う。
手順に従って取得したメールアドレスを ACCOUNTADMIN ロールを持つユーザのメールアドレスとして設定し、ウェブ上から通知を有効化・電子メール受け取りに変更するのみ。

alter user <admin_user> set email = 'x-hoge@xxx.org.slack.com';

これだけ。
通知の有効化も SQL でやりたいなとか非管理者も通知を受け取りたいな、メールと Web 以外でも通知を受け取りたいなという気持ちではあるが、一旦はこれでなんとかなるので今後のアップデートに期待したい。

2020/05/24 自粛期間とリモートワークと自分

緊急事態宣言が25日に解除になりそうな雰囲気が出てきた。
会社として解除後どうなるかは分からないが、一旦約2ヶ月のフルリモートワーク期間を振り返ってみる。

良かったこと

  • 自宅環境に投資できた
    • これまで買い渋っていたキーボードやモニター等購入に踏み切れた
    • オフィスより開発環境が良くなっている
  • 通勤時間がなくなった
  • 外食をしなくなった
  • 技術検証系の業務に集中できた
  • アイドルやアーティストなどのオンラインコンテンツが充実した
  • 読書の時間を確保できるようになった

通勤時間がなくなったのは特に良かった。毎朝の満員電車生活はやっぱりきつい。

良くなかったこと

  • 生活リズムがおかしくなる
  • ライブやスポーツ観戦が一切できない
  • 外に出るのが億劫になる
  • 定時内に集中できなかったときは夜中に一気に仕事をする
  • 仕事のパフォーマンスにかなり波がある
  • 光熱費や飲み物への出費がかさむ

仕事については改善の余地ありそう。

気をつけていること

  • 仕事で雑談を増やすようにしてる
    • オンライン勉強会とか週1で技術雑談するとか
  • チャットの使い方
    • あとで反省することも多いけど…
    • ハイコンテクストな文章は避ける・きつめに受け取られそうな文章は書かない等

自分だけが気をつけても効果は薄いので、各々が気をつけられるようになると良いと思う。

気づいたこと

  • パフォーマンスが良くなっているのか悪くなっているのか分からないがフルリモート自体は意外と問題ない
  • 今までは気付きにくかったような会社の問題がけっこう見えてくる
    • 会社の問題と書くとネガティブに見えるけど自分は改善ポイントが見えて良かったと思ってる派
  • 蒙古タンメン中本に納豆を入れるとめちゃくちゃおいしい
    • 納豆はひき割りのほうが良い
  • 部屋の電気が暗い
    • 確実に目が悪くなっている気がする。はやく買おう
  • 運動が少ない
    • 自粛という事情がないただのリモートであれば運動ももう少し活発にするはず…
  • 料理が下手
  • 引っ越したい
    • 合わせて都内でそこそこ良い家は家賃が高いことにも気付いた(それはそう)
  • ゲームをやりすぎる

2020/05/23 日記

眠れないので日記を書く。

モニター、買った

前回の記事を書いてからすぐにモニターを買う決心がついたので購入した。
買ったのはこれ https://www.amazon.co.jp/gp/product/B07XYVNHGH/ref=ppx_yo_dt_b_asin_title_o04_s01?ie=UTF8&psc=1
使い始めて3週間ほど経ったけど、1画面に多くの情報を詰め込める点は良いなと感じている一方で、Mac の Retina ディスプレイに見慣れてるとけっこう見づらさが気になるのが辛かったりもする。ただ、買ってよかったとは思っているし、実際にデスクで作業する時間が圧倒的に増えた。

トラックパッドがほしい

BAROCCO を買ったはいいが、トラックパッドのために Mac を開いてなければならないのがちょっとつらい。手の移動距離も長いし。
ということでここ最近は Mac の内蔵キーボード生活に戻ってきてしまった。Magic Trackpad 2 を買おうかすごく悩んでいる。 Touch ID がとてつもなく便利(社内のサービスでも Touch ID を使えるものがあったりする)なので、Magic Trackpad に Touch ID 搭載してくれたら即買いなんだけどなー。

SHIROBAKO の菅野さんの言葉を定期的に思い出す

特に何があったとかではないんだけど、タイミングよく思い出したので書く。

これをわしが描く意味って何だろう。

これとか

アニメーターも人間だから、この仕事はお前にしかできないって言われたいんだよね。

これ。ちなみに第12話。

自分も何のコンテキストもなく決まった仕事をただ渡されるのはちょっと苦手かもしれない。
菅野さんみたく、この仕事はお前にしかできないって言われたいのかもしれないし、
せっかくプロジェクトやチームに所属しているのに、言われたことだけをやる関係性になるのが嫌なのかもしれない。
自分もなにかを依頼するときは気をつけようとふと思った。

2020/04/28

この記事は新しく買ったものが届いて嬉しくなって書いたただの日記です。

BAROCCO MD770

これ: https://www.archisite.co.jp/products/mistel/barocco-md770-rgb/

キーボード

自宅の開発環境を整えるためにも、まずはキーボードをと思って買った。単体のキーボードを買うのは人生で初めてで、普段は MacBook Pro の内蔵キーボードで過ごしている。(MBP のキーボード普通に使いやすくて好き)
買うなら分割キーボードをと思っていたが、やはりすぐには慣れない。特に自分は右手の担当領域が大きいっぽくて、左分割されたキーボードのBをしきりに右手で押そうとしてしまう。矯正しないと…

感想まとめ

  • 良い点
    • バックライトがきれいでテンション上がる
    • セパレート型なので自由に配置可能
    • Mac 向けの設定があって便利
  • 大変な点
    • 不慣れたためにタイミング速度がかなり落ちる
    • ちょっと腕が疲れるかもしれない
      • パームレストとか買ったほうが良いのかな
    • 一番右の列は個人的に不要
      • 間違えて押すことがかなり多い
    • MBP がスリープから復帰するとキーボードを認識しなくなる

ちなみに、けっこう人気っぽい。Amazon はすでに売り切れていたのでツクモで買った。

Kraken X

これ: https://www2.razer.com/jp-jp/gaming-audio/razer-kraken-x

フルリモートに切り替わってオンラインミーティングがけっこう耳にダメージ与えてくるなと思ったのでキーボードを買う流れに乗ってヘッドセットを購入してみた。こちらも購入は初。普段は Pixel 3 XL を購入したときに付属されていたイヤフォンを使っていた。
あんまり機能性みたいなものを求めていなかったので、おおむね満足している、、んだけどしばらく着用すると熱を帯びてくるのがしんどい。耳周りめっちゃ熱くなる。

会社で zoom 雑談ルームを作ってみた

もともと技術の話があんまりできなかったり、エンジニア同士の交流が少ないと思っていたので、せっかくならと思ってそれらを達成する裏目標のもと雑談ルームを始めてみた。
初回は2人来てくれた(少ない、、w)が、2時間ぐらい色々喋れたので個人的にはやって良かった。ちょっと時間使いすぎた反省もあるので、もう少し短めにして週1ぐらいのペースでやれたらなと思う。

話した内容は

あたり。

About me

  • 名前: 金谷直輝(Naoki Kanatani)

  • 所属: CyberAgent, Inc.

  • 経歴:

    • 2012 / 04 - 2016 / 03: 東京工業大学情報工学部
    • 2016 / 04 - 2018 / 03: 東京工業大学情報理工学院
    • 2018 / 04 - 現在: CyberAgent, Inc.
  • リンク:

ElastiCache のノードタイプを変更する際の注意点

注意: この記事は aws elasticache list-allowed-node-type-modifications を知っていれば(ほぼ)読む必要はありません。

背景

今見ているサービスで RI の購入タイミングになったので、m4.4xlarge のものを m5.4xlarge に変更しようという話になりました。
しかし、実際にオペレーションをしたところ変更ができなかったのでスケール時に確認しておくべきことなどを自分用にメモとして残しておきます。
(いやその変更は直接は無理でしょ!と一瞬で分かった方には不要な記事です)

原因・事前にやっておくべきこと

結論から述べると、ドキュメントに記載してある通り、スケールアップ先として選択可能なノードとそうでないノードが存在します。
AWS CLI であれば aws elasticache list-allowed-node-type-modifications を使うのが良いです。


$ aws elasticache list-allowed-node-type-modifications --replication-group-id xxxxx
{
    "ScaleUpModifications": [
        "cache.m4.10xlarge",
        "cache.m5.12xlarge",
        "cache.m5.24xlarge",
        "cache.r3.4xlarge",
        "cache.r3.8xlarge",
        "cache.r4.16xlarge",
        "cache.r4.4xlarge",
        "cache.r4.8xlarge",
        "cache.r5.12xlarge",
        "cache.r5.24xlarge",
        "cache.r5.4xlarge"
    ],
    "ScaleDownModifications": [
        "cache.m3.2xlarge",
        "cache.m3.large",
        "cache.m3.medium",
        "cache.m3.xlarge",
        "cache.m4.2xlarge",
        "cache.m4.large",
        "cache.m4.xlarge",
        "cache.r3.2xlarge",
        "cache.r3.large",
        "cache.r3.xlarge",
        "cache.r4.large",
        "cache.r4.xlarge",
        "cache.t2.medium",
        "cache.t2.micro",
        "cache.t2.small",
        "cache.t3.medium",
        "cache.t3.micro",
        "cache.t3.small"
    ]
}

なぜ変更できないのか

ドキュメントには詳細な仕様は明記されていません。
今回のケースでは「別のノードタイプに変更する場合は現在よりメモリの小さいものには変更できない」というルールが存在していてそれに引っかかったのだと思われます。
また、これ以外にも変更に関するルールは存在するようなので、必ず事前に調べておく必要があります。

どうしても変更したい

という場合もあるかと思います。その場合は、

  1. 同ノードタイプの現在よりメモリの小さいものに一旦変更
  • 例: m4.4xlarge -> m4.2xlarge
  1. 当初変更予定だったノードタイプに変更
  • 例: m4.2xlarge -> m5.4xlarge

という手順で理論的には変更可能です。(こちらはサポートケースでも案内されました)

Hugo + GitHub Pages + GitHub Actions でこの記事を世に届けている

最近自分のアカウントも GitHub Actions が有効になったので、
早速使ってみようと思いこの GitHub Pages を Actions でリリースするようにしてみた。
実際の YAML を見るのが早いと思うので貼る。以下の通り。

name: publish

on:
  push:
    branches:
      - develop
jobs:
  build-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: build
      uses: peaceiris/actions-hugo@v0.58.1
      with:
        args: --gc --minify --cleanDestinationDir
    - name: deploy
      uses: peaceiris/actions-gh-pages@v2.2.0
      env:
        ACTIONS_DEPLOY_KEY: ${{ secrets.ACTIONS_DEPLOY_KEY }}
        PUBLISH_BRANCH: master
        PUBLISH_DIR: ./public

すでに世に出回っている Action が便利なのでそれを使うだけの記事になってしまった。

参考

ハローワールド

文章を書きたいけどどこに書こうか迷った結果 GitHub Pages にたどり着いた。