FLINTERS Engineer's Blog

FLINTERSのエンジニアが綴る技術ブログ

業務アプリケーションをScala 3で動かしてみた(後編)

こんにちは。FLINTERSでTech Adviserをしています、OE(@OE_uia)です。

Scala 3.0.0が2021年5月14日にリリースされたことを受けて、いつアップデートするか検討中の方も多いかと思います。 実際、今FLINTERSではScala製プロダクトのScala 3へのバージョンアップを試みています。前回の「業務アプリケーションのScala 3アップデートを試してみた(前編)」の記事では、主にScala 3マイグレーションに役立つ情報や機能についてご紹介しました。

labs.septeni.co.jp

今回はその後編です。

続きを読む

Row Level Security で事故らないアプリケーションを構築する

こんにちは、清水です。直近の業務でマルチテナントな DB でアプリケーションでのスイッチロール機能を実現するために Amazon Cognito や表題にある Row Level Security について技術検証や設計検討を行っていました。

今回はこの Row Level Security について PostgreSQL での例を挙げて挙動を確認しながら、実際に導入するにあたって必要な知識や注意点までを網羅します。本記事が安全で堅牢なアプリケーション構築の一助となれば幸いです。

  • 1. マルチテナントとは
  • 2. Row Level Security とは
  • 3. 実際に試してみる
    • 3-1. 実現するための SQL
    • 3-2. RLS 有効化前
    • 3-3. RLS 有効化後
  • 4. 補足
    • 4-1. クエリのパフォーマンスについて
    • 4-2. ユーザーとロールの管理について
    • 4-3. コネクションの管理について
    • 4-4. BigQuery などでも RLS が使える
  • 5. さいごに
続きを読む

Tech × Marketing Conference 2021に登壇しました

FLINTERSでエンジニアをしている堀(@ho1yHero)と申します。

去る2021年12月10日、弊社が共同主催として名前を連ねている、Tech × Marketing Conference 2021というイベントがオンラインで開催されました(公式Twitterこちら)。本エントリーはその登壇レポートエントリーですが、登壇のきっかけや感想など、当日に触れられなかったことにフォーカスしてお伝えします。

続きを読む

イーサリアムキラーの本命?Solanaのプログラムを作って遊んでみる!

こんにちは。菅野です。

今年も暗号資産界隈は話題に事欠かないですね!
その仕組みを支えているのはブロックチェーンです。
最近もAmazonGoogleが注力している分野の一つです。

そして2021年に最もホットで技術的に魅力なブロックチェーンといえばSolanaでしょう!

Solanaって?

solana.com

詳しくはググってほしいのですが、簡単に言うと

のような技術的な特徴があります。

私はEthereumやEOSのスマートコントラクトを作って遊んだことがあります。
でも、EthereumはSolidityというあまり馴染みのない言語で書く必要があり、EOSはwasmにコンパイルすることでRustで書くことが出来ましたがRustの強みをあまり活かせてない感があります。
SolanaはLLVMのBPFバックエンドを介してRustプログラムを動かせるのでRustのパワーを活かせると思います。

ちなみにRustとはC並に速いネイティブアプリを作れて、ヌル参照と無縁で、かつ超強力な文法を有する、とてもホットで素晴らしいプログラミング言語です。Rustはいいぞ。

Solanaを試す

Install the Solana Tool Suite | Solana Docs

まずはCLIツールをインストールしましょう。
公式のドキュメント通りに作業すれば入ります。

ツールをインストールしたらウォレットとなる鍵を作成しましょう!

solana-keygen new

で作成できます。ちょっと試すだけなら回復用のパスフレーズ無しで作成しても良いと思います。
シードフレーズを覚えておけと言われますが、本物のお金を入れないのであれば鍵を失くしてもウォレットを再作成すれば良いでしょう。
キーペアは$HOME/.config/solana/id.jsonに保存されます。

続きを読む

BigQuery ML のモデル作成機能を使ってレポートの推移を予測してみた

TL;DR

本日はBigQuery MLの時系列モデルを用いてレポートデータの予測をしてみました。

時系列モデルを使ってモデルの作成からモデルの作成までをSQLライクにできて非常にかんたんでした。

今回はそちらのやり方・内容・料金面についてご紹介させていただきます。

完成したグラフはこちらです。

f:id:s_hayase:20210812124925p:plain

モデル作成してから利用するまでの流れ

今回はモデルを作成してから、100日後までの気温を予測しました。

-- モデルの作成
CREATE MODEL IF NOT EXISTS `sample_model` 
  OPTIONS(
      -- MODEL_TYPE: モデルのタイプを設定する。ここでは時系列データ。
      -- TIME_SERIES_TIMESTAMP_COL: トレーニングデータのタイムを指定しているカラム
      -- TIME_SERIES_DATA_COL: 予測する値のカラムを指定する。1つのデータしか予測できない。
      MODEL_TYPE = 'ARIMA_PLUS'
      , TIME_SERIES_TIMESTAMP_COL = 'date'
      , TIME_SERIES_DATA_COL = 'temperature'
) AS

-- トレーニングデータの指定
SELECT
    date,
    temperature
FROM
    `sample_reports`

下記のようにクエリ結果が出力されます。

処理時間は5.7 KiBで約12秒かかりました。

前に実験で100GBぐらいの処理を行ったときには約10分程かかりました。

f:id:s_hayase:20210812112310p:plain

モデルから予測値を取り出す方法は下記のようにFROM句にモデルを記載してあげるだけです。

-- 100日分の気温を予測する
SELECT
  date(time_series_timestamp) AS date,
  if(time_series_type = 'history', time_series_data, null) history_data,
  if(time_series_type = 'forecast', time_series_data, null) forcast_data,
  prediction_interval_lower_bound,
  prediction_interval_upper_bound
FROM
  ML.EXPLAIN_FORECAST( MODEL `sample_model`,
    STRUCT(100 AS horizon, 0.8 AS confidence_level) )

注意すべき点

クレンジングされたデータを使ったほうがいいです。

IDやタイムスタンプなどにNULLが入っているとモデル作成時にエラーが発生するので、モデルを作れませんでした。

モデル作成時のクレンジングに関してはKaggleのCause(英語)などが参考になると思います。

お金の話

BigQuery 料金をもとに計算しました。

  • CREATE MODEL
    • 時系列モデルの場合は $300.00 per TB。モデルタイプによって内容は変わってきます。
    • 無料枠は毎月 10 GB までの処理
  • 評価、検査、予測(すべてのモデルタイプ)
    • $6.00 per TB
    • 無料枠は毎月1TBまでの処理

またモデルや予測を実行すると下記のように、処理にかかるリソースの割合を示してくれます。

f:id:s_hayase:20210812112346p:plain
モデルの処理規模予測

今回の場合過去1年分の天気データを用いてモデルを作成した結果

  • CREATE MODEL: 5.7 KiB
  • 予測: 42.7 KiB

かかりました。

そのため、毎日1ヶ月モデルの再構築と予測をおこなった場合はおおよそ、

ぐらいで無料枠に収まりました。

逆に、数年分のデータ x IDの量が膨大になってくると料金は爆発的に伸びることが考えられるので、料金を落とすにはデータを集約したり不要なデータの排除を事前に行うことが必要になってくると思います。

感想

BigQuery MLに用意されたテンプレートの時系列モデルを活用することで、データの活用を効率的に行うことができました。

その予測値の精度に関しては確認していないので、ML.ARIMA_EVALUATEなどを用いて確認する部分が課題です。

セプテーニグループは大量のレポートデータを保持しているので、時系列モデルを用いたデータ活用に関しては非常にマッチしていると思いました。