NewRelicの新料金プランについてまとめる

昨年の夏頃にNewRelicでは新料金プランを打ち出していました.

newrelic.com

この頃は私が関わっているところでは、料金プランの変更が次回更新時だったため詳細について見るのを後回しにしていました.
そしてそろそろ更新タイミングに差し掛かるため、新料金プランがどういった料金体系や仕組みになっているのかをまとめます.
間違っているところもあるかしれないのでそこはご注意ください.

料金について

旧料金プランでは、利用する製品ごとにホスト数やAU数による従量課金でした.
新料金プランでは、Full userというユーザ数課金と、無料枠を越えた場合の従量課金の2軸になっています.
料金の詳細についてはNewRelicのページを見てほしい.

newrelic.com

無料枠を越えた場合の従量課金については、どれぐらいになるのかが想定できないので端折りますが、
ユーザ数課金は1開発者として考えるとかなり高くなる可能性があります.
新しい料金プランでは、Basic userとFull userという2種類のユーザモデルが存在しており、
Basic userは無料で使えるが、Full userはそのユーザ数分の料金が請求されます.
恐らく大部分の開発者はFull userでないと困る可能性が高く、開発者が多い組織では開発者数分の料金が徴収されます.
具体的にどれぐらいの料金なのかはページに表示されていないため、ここでは触れないが組織によっては驚くような徴収額になる可能性が高いです.
とはいえ、利用できる機能や管理しているサービスやホスト数によっては全然ペイできるとは思う価格帯だとは私は思っています.

ちなみに本家の方のページには日本のページにはないStandardなるプランがあります.

newrelic.com

Basic userとFull userの違いについて

NewRelic公式ドキュメントにユーザモデルの違いについてのページがあります.

https://docs.newrelic.co.jp/docs/accounts/accounts-billing/new-relic-one-user-management/new-relic-one-user-model-understand-user-structure

それぞれのユーザでできることを見る限り、APMやBrowserなどでパフォーマンスやエラーなどをチェックする人というか、
基本的に開発者はFull userでなければNewRelicを導入する意味はないです.

下にドキュメントから抜粋しておきます.

Full-Stack Observability

機能 Full user Basic user
Application perfomance monitoring(APM) UI
Infrastructure monitoring UI
Digital Experience Monitoring(Browser, Mobile, Synthetics) UI
Serverless monitoring UI
Logs in context with other UI experiences
Synthetics checks
New Relic Edge with Infinite Tracing (tail-based sampling)
Subscribe to New Relic One catalog apps
Assorted curated UI experiences (distributed tracing, Kubernetes cluster explorer, workloads, etc.)

Applied Intelligence (AI)

機能 Full user Basic user
Proactive Detection ✔(read-only)
Incident Intelligence ✔(read-only)

Telemetry Data Platform

機能 Full user Basic user
Data ingest from any source (Metrics, Events, Logs, Traces)
Alerts and notifications
Interactive query interface
Custom charts and dashboards (not New Relic-built)
Encryption at rest
Standard data retention
NerdGraph (GraphQL) API
Security and compliance
Integrations
Data management
Logs UI
Build custom New Relic One apps

おわりに

実際にNewRelicの方と話をして実際にいくらになるのかは、事前に見積りを取っておくことをオススメします.
もしも、見積もりをとった上でペイできないような料金になりそうであれば、開発体制の見直しや別サービスの導入をする時間があった方が良いはずですからね.

CloudWatchアラーム一覧を表示する

どのリージョンにどんなCloudWatch Alarmがあるのかを知りたかったので、Bashスクリプトを書きました. 利用するツールは、jqとAWS CLIv2の2つ.

#!/usr/bin/env bash

# 利用可能なリージョンを取得
get_regions() {
    aws ec2 describe-regions | jq -r '.Regions[].RegionName'
}

# 指定されたリージョンのアラームを取得し、「リージョン\tアラーム名」というTSV形式で出力
get_alarms() {
    local region="$1"
    aws --region $region cloudwatch describe-alarms | jq --arg REGION "$region" -r '.MetricAlarms[] | [$REGION, .AlarmName] | @tsv'
}

main() {
    for region in $(get_regions); do
        local alarms=$(get_alarms $region)
        if [ -n "$alarms" ]; then
            echo "$alarms"
        fi
    done
}
main $*

個人事業主としての活動を始めるまでにやったこと

私が2020年に副業として個人事業主としての活動を始めようとした時にやった作業を振り返ります.

  • 「個人事業の開業届」と「所得税青色申告承認申請手続き」を税務署に提出する
  • 個人事業用の預金口座を用意する
  • クラウド会計ソフトを導入する
  • 事業で利用するためのPCを用意する

他にも事業用のクレジットカードを作っても良いかもしれませんが、私は2020年度には作成していません.

「個人事業の開業・廃業等届出書」と「所得税青色申告承認申請手続き」を税務署に提出する

開業してから1ヶ月以内に「開業個人事業の開業・廃業等届出書」を税務署に提出・郵送する必要があります.
また青色申告をするためには事前に「所得税青色申告承認申請手続き」を提出・郵送しておく必要があります.
白色申告の場合は、開業届だけで問題ありません.

e-Taxでの提出にも対応しているようなので、気になる人は検索してやり方を調べると良いかもしれません.
私は、開業時に住んでいた場所が税務署に近かったので散歩がてらに直接提出してきました.

開業届などの申告書類は開業freeeを利用して作成したので、あまりつまづかなかった記憶があります.

事業用の預金口座を開設する

プライベート用の口座を事業利用すると

といったデメリットがほぼ100%発生します.
確定申告時に慌てたり、仕訳の手間を減らすためにも事業用の口座を別途作成しておいいたほうが良いのは間違いないです.

また、口座に紐づくデビットカードもあれば間違いなく仕訳が楽になります.

私はジャパンネット銀行で口座を開設しましたが、自分の利用用途と使いたいクラウド会計ソフトとの連携ができるかどうかで選ぶのが良いかもしれません.
※ 屋号がある場合は屋号付き口座が良いようです.

クラウド会計ソフトを導入する

私は会計freeを利用していますが、口座やクレカとの連携をしておくことで自動仕訳なども利用可能で非常に便利です.
クラウド会計ソフトはいくつか種類がありますが、自分に合いそうなソフトをいくつか試してみたりすると良いかもしれません.

freeeが良いというわけでもないので、絶対に自分に合いそうなツールを探したほうが良いです.

事業で利用するためのPCを用意する

事業で利用するためのPCを用意しておきます.
自分の利用用途にあった、1世代ぐらい型落ちの中古PCがコスパもよく個人的にはオススメです.

私はゲームや開発をするために元々自作していたPCがあったので、それを利用することにしました.
正直、これだと経費としては落とせないですが、ある程度事業資金が貯まったら利用用途に合いそうなPCを買おうと思っています!

2020年買ってよかったもの

既に1月半ばになってしまったけれど、2020年に買って良かったモノや契約して良かったサービスをまとめました.
元々ゲームを快適にプレイする環境を整えていたので、リモートワーク向け製品は少なめです.

1. audio-technica ATH-M70x(ヘッドホン)

当時利用していたヘッドセットのイヤーパッドがボロボロになってしまい、交換用のイヤーパッド価格が新品の半分ぐらいの値段をしていたため、
これを気に新しいヘッドホンにしようとしてATH-M70xを購入.

フラットな音が好きというのもあり他社製品やM50xと悩んだが、
どんなもんかという好奇心だけでM70xに決めた.

Pros

  • 個人的に好みの音

Cons

  • 解像度が高いからこそ聴き疲れしやすい
  • メガネをかけていると痛くなる可能性はそこそこある(側圧は弱くはない)
  • 付属のケーブルが捩れる

低音がやや弱めな気はするが、フラットよりでしかも情報量が多く、初めて買ったヘッドホンを思い出した時の感動でした.
とはいえ、もしモニターヘッドホンの中でオススメするとしたらM50xか、SONYやらYAMAHAの定番機から選ぶ可能性は高い.

audio-technica プロフェッショナル モニターヘッドホン ATH-M70x

audio-technica プロフェッショナル モニターヘッドホン ATH-M70x

  • 発売日: 2015/02/20
  • メディア: エレクトロニクス

2. iPhone SE(第2世代)

FeliCa対応している中価格帯の中で、eSIM含めて複数回線契約できる機種を探していた結果、
iPhone SEしかなかったという理由で買った.

不満があれば書こうかと思ったが、本当に不満に思ったことがなにもない.

他機種と比べて劣る点はもちろんあるから、そこは注意が必要.

3.コアラマットレス

入眠にかかる時間がかなり早くなった気がする.
クイーンサイズを買ったので、それなりに広く寝転がれるというのも便利.

Pros

  • 値段相応の寝心地(な気がする)

Cons

  • 腰痛持ちには向かない
  • サイズに気をつけないと引っ越す時にサイズの問題で大変かもしれない

4. ボクガール(漫画)

ストーリーとしてはド王道な展開なんですが、今まで読んできた漫画の中で1番ぐらいにキャラクターが好きです.
もう完全に一目惚れ. そういうレベル.
仕事やプライベートで辛い時に出会えて本当に心の支えになりました.

ジャンルとしては「TSラブコメ」になると思います.
内容としても王道なラブコメですが、ほんちょぴっと性的な表現が出てくるので読む時は
周りをよく確認して読むことをオススメします.

5. Notion(メモ、タスク管理などのWebサービス)

これがないとタスク管理としてTrelloを使っていたが、代替として12月から本格的に使い始めました.
かなり自由度が高いため、フォーマットや仕組み作りに時間をかけられる人にはオススメです.

時間をかけらない人でもテンプレートが出回っていたりするので、それをベースにして色々やってみると面白いかもしれません.

Notion

6. nosh(宅食)

いわゆる宅食サービス. 正直、割高感は否めないがご飯を用意しなくてよいという点に限っていえば体験が良かったです.
Uber Eatsで頼むよりは全然安いよ?

nosh

もし、興味があれば以下の紹介リンクからどうぞ!
初回割引されます!

nosh

AWS LambdaでRubyコンテナを動かす

re:InventでAWS Lambdaがコンテナをサポートしたようなので、
aws-lambda-rubyコンテナを使った動作確認をしてみました.

corrupt952/aws-lambda-container-ruby-sampleにファイルを置いてきます.

TL; DR

  • コンテナがサポートされたことにより関数を実行するランタイムの柔軟さが向上した(ように思える)

  • Lambdaで実行しづらかった一部のユースケースが利用可能になる程度で、ECSなどで実行されているような処理が置き換え可能になるわけではなさそう

Lambda Functionを作成する

コンテナを使ったLambda Functionを作成手順は、以下のような流れになります.

  1. Lambdaで利用するためのECRリポジトリを作成

  2. Rubyランタイムで実行可能なコードを作成

  3. Lambdaで実行するためのDockerfileを作成

  4. コンテナイメージをビルド

  5. コンテナイメージを1で作成したECRリポジトリにプッシュ

  6. Lambda Functionを作る時に5で指定したコンテナイメージのURIを指定

それぞれについて少しだけ詳細に書いておきます.

1. Lambdaで利用するためのECRリポジトリを作成

特筆して書くことはないですが、コンテナイメージをプッシュするためにECRリポジトリを作成しておきます.

2. Rubyランタイムで実行可能なコードを作成

Ruby の AWS Lambda 関数ハンドラーを参考にRubyランタイムで実行可能なコードを作っておきます.

今回はapp.rbというファイル名でwww.khasegawa.netへリクエストするだけのコードを作成しておきます.

# app.rb
require 'faraday'

module LambdaFunction
  class Handler
    def self.process(event:, context:)
      response = Faraday.get 'https://www.khasegawa.net'
      puts response.body
    end
  end
end

3. Lambdaで実行するためのDockerfileを作成

Lambda Runtime API どんなコンテナでも動作するというわけではなくLambda Runtime APIが実装されているコンテナである必要があります.
実装するのは面倒なのでamazon/aws-lambda-rubyを使ってコンテナイメージを作成します.

FROM amazon/aws-lambda-ruby:2.7
COPY Gemfile Gemfile.lock $LAMBDA_TASK_ROOT
# vendor/bundleにインストールしないと参照できないので注意
RUN bundle install --path vendor/bundle
COPY app.rb $LAMBDA_TASK_ROOT
CMD ["app.LambdaFunction::Handler.process"]

4. コンテナイメージをビルド

docker build -t xxx.dkr.ecr.ap-northeast-1.amazonaws.com/hasegawa-sandbox-lambda:latest .

5. コンテナイメージを1で作成したECRリポジトリにプッシュ

ビルドしたコンテナイメージをECRにプッシュします.

aws ecr get-login-password | docker login --username AWS --password-stdin xxx.dkr.ecr.ap-northeast-1.amazonaws.com
docker push xxx.dkr.ecr.ap-northeast-1.amazonaws.com/hasegawa-sandbox-lambda:latest

6. Lambda Functionを作る時に5で指定したコンテナイメージのURIを指定

以下のように、コンテナイメージを選択した上で、ECR上にあるコンテナイメージのURIを指定して関数を作成します.

f:id:corrupt952:20210127074603j:plain

実行

実際に実行した結果としては以下のようになります.(見づらい)

f:id:corrupt952:20210127074625j:plain

さいごに

Lambdaでコンテナがサポートされたころにより、今までよりもランタイムが柔軟になり、
利用するハードルやコンテナイメージの作成自体のハードルも低く、とても魅力的に感じました.
他にもyumなどのパッケージマネージャ経由でパッケージをインストールして、それらを利用することも可能ですし、
非常に可能性を感じました.

とはいえ、実際に使ってみた感想としてはランタイムの柔軟性が増しただけのような気もするので、
ユースケースによってはマッチしない可能性はありそうですね.

WSL上で実行されているかどうかを判定する

スクリプトがWSL上のLinuxで動作しているかどうかを判定できるようにしておくと、
macOSやWSLといった複数環境をサポートするスクリプトを書いている時に少しだけ便利になります.

判定方法としては、ファイルの内容やコマンドの実行結果によって判断する方法などいくつか存在しますが、
今回は「/proc/sys/fs/binfmt_misc/WSLInteropファイルが存在しているかどうか」で判定する方法です.

/proc/sys/fs/binfmt_misc/WSLInteropファイルが存在しているかどうか」だけなので非常に簡単に判定することができます.

[ -e /proc/sys/fs/binfmt_misc/WSLInterop ]

実際にスクリプトで使う利用する場合には、関数として切り出しておき必要に応じて呼び出すようにしておくと良さそうです.

#!/usr/bin/env bash

os::is_wsl() {
  [ -e /proc/sys/fs/binfmt_misc/WSLInterop ]
}

# e.g. if-statement
if os::is_wsl; then
  # WSL
else
  # Others
fi

※ 個人で利用しているdotfilesではos::is_wsl()のように関数として定義しています

指定したプロパイダのバージョンを一括変更する

既視感がありますが、指定したproviderのバージョンを一括変更するためのスクリプトを業務終了間際に少し書いてみました.

今までそれなりの数のTerraformを触ってきましたが、
バージョンアップデートをする時に1ファイルずつを置換するのが正直なところかなり面倒臭いです.

全てのプロパイダのバージョンが統一されていればよいのですが、
単純なバージョン文字列の置換だけだは対応できないケースも存在しているため、
そういったケースでもバージョンを置換できるようなスクリプトを書きました.

#!/usr/bin/env bash

set -o pipefail
set -o errexit

if [ "$#" -lt 2 ]; then
    echo "置き換え対象のプロパイダと新しいバージョンを指定してください"
    exit 1
fi

provider="$1"
version="$2"

for fpath in $(find . -name "provider.tf");
do
    current_version="$(python3 -c "import hcl; obj = hcl.load(open('$fpath', 'r'), ); print(obj['provider']['$provider']['version'])" 2>/dev/null)"
    if [ "$(uname -s)" == "Darwin" ]; then
        sed -i '' -e "s/${current_version}/= ${version}/g" $fpath
    else
        sed -i -e "s/${current_version}/= ${version}/g" $fpath
    fi
done

./update_providers.sh aws 2.54.0を実行したと過程して、大まかな処理の流れとしては、

  1. provider.tfをカレントディレクトリ配下から再帰的に探索
  2. pyhclでprovider.tfにある指定したプロパイダのバージョンを抜き出す
  3. sedで引数に指定されたバージョンに置き換える

となります.
HCLの自前パースは時間的に面倒だったので、pyhclを使って指定したプロパイダのバージョンを抜き出しています.
単一のprovider.tfに同一プロパイダが複数存在するケースは考慮してないですけどね.

これとは別に利用するバージョンを統一するようなルールを機械的にさせる予定です.