研究開発職

 

応募要項はこちら

R&D DevOps/MLOpsエンジニア

 
 
オフィスについて
業務環境・社内制度について
 

研究開発部メンバーの連載記事

 

研究開発職に関する記事

【R&D DevOps通信】Kinesis Data FirehoseでログをETL処理してRedashからクエリする - Sansan Builders Blog
R&D Architectグループの辻田です。SBB*1 2回目の登場です。 今回は【R&D DevOps通信】連載の5回目として、Kinesis Data Firehoseを使用したログのETL処理について書こうと思います。 CloudWatch Logsサブスクリプションフィルタ + Kinesis Data Firehose + Lambdaを使用してログをETL処理し、S3へ出力したデータをAthenaテーブルに読み込み、Redashからクエリできるような仕組みです。これらのリソースをTerraformで構築する方法を紹介していきます。 R&Dで運用しているとあるバッチにて、実行後にサーバ上のログファイルから必要なデータのみをスクリプトでcsvに抽出し、それをクラウド上に配置し他部署に共有するという運用を行っているものがありました。 この手動運用を自動化し、他部署の人がログを参照する際の検索性も向上させて一連の運用フローを改善するため、今回の仕組みを作ることになりました。 最終的なアーキテクチャは以下のようになります。 CloudWatch Logsのサブスクリプションフィルタを作成し、フィルターパターンと一致するログをリアルタイムにKinesisに配信するようにします。 ロググループごとに最大2つのサブスクリプションフィルタを関連付けることができます。 まずはフィルターしたログを配信先に配信するための権限を付与するIAMロールを作成します。 Kinesisにログを配信するためにサブスクリプションフィルタのIAMロールに firehose:PutRecord と firehose:PutRecordBatch の権限を付与しています。 次にサブスクリプションフィルタを作成します。 resource "aws_cloudwatch_log_subscription_filter" "test_logfilter" { name = "test_logfilter" role_arn = aws_iam_role.subscription_filter_role.arn log_group_name = "example" filter_pattern = "filter pattern" destination_arn = var.kinesis_stream_arn } ポイントは以下です。 filter_pattern にはフィルターしたい語句を指定します destination_arn には配信先リソースのARNの指定します。Kinesis Data Stream、Kinesis Data Firehose、Lambda が選択可能で、今回はKinesis Data Firehoseを指定しています。 続いてKinesis Data Firehoseのリソースを作成していきます。 まずはKinesisが使用するIAMロールを作成、各リソースへのアクセス権を付与します。今回必要となった権限の概要は以下です。 S3バケットにデータを配信する権限 データ配信エラーをCloudWatch Logsに記録するための権限 データ変換のためのLambdaの実行権限 ロールの次はKinesis Data Firehoseの配信ストリームを作成します。 ポイントは以下です。 destinationで配信先を指定します。S3, Redshift, Splunk, サードパーティーサービスプロバイダーが所有するHTTPエンドポイントなどがサポートされています。 processing_configurationはtrueを指定してデータ変換を有効にします。変換用のLambdaを用意することで、受信したデータを変換してから送信先に配信することができます。 データ変換を有効にするとデフォルトで最大3MBまで受信データをバッファするようになります Lambdaの同期呼び出しモードを使って、バッファされたバッチごとに指定されたLambdaを非同期で呼び出します。変換されたデータはLambdaからKinesisに送信されます。 送信先バッファサイズまたはバッファ間隔に到達した時点で送信先のS3バケットに送信します。デフォルトはバッファサイズが5MB ...
https://buildersbox.corp-sansan.com/entry/2022/06/14/110000
gokart の環境変数周りでバグを発見したので、修正 PR を出したら爆速でリリースされた話 - Sansan Builders Blog
こんにちは。技術本部 R&D 研究員の青見です。 4月で社会に出て1年になりました。 この時期は花粉症が辛くて記憶がくしゃみにかき消されがちですが、入社式のやっていきを思い出して2年目も頑張っていきます。 さて、 R&D では積極的にパイプラインツールを使って開発しようという流れになってきており、その1つとして gokart を利用しています。 gokart は Luigi という Spotify が開発している Python のパイプラインライブラリのラッパです。 特徴として機械学習利用のパイプラインに特化しており、再現性の担保という観点では非常に Luigi と比べて使いやすく感じます。 gokart と Luigi について詳しくは同じチームの髙橋が連載で紹介しているので、ぜひそちらを御覧ください。buildersbox.corp-sansan.com 今回は実際に使用していた gokart においてバグを発見したので修正の PR を出したところ、マージ後高速でリリースされ、即座に業務で利用することが出来たという話をします。 Luigi や gokart では処理の一つひとつをタスクという単位でまとめ、パイプラインとして実行します。 このタスクやパイプライン全体に対してパラメータをうまく扱う仕組みがあり、これらのパラメータを設定ファイル (.ini ファイルなど) として管理することが出来ます。 パラメータに関する設定ファイルは、 Python built-in の configparser に準拠しており、以下のようにセクション単位で機能やタスクのパラメータを管理します。 [TaskOnKart] workspace_directory=./resources local_temporary_directory=./resources/tmp [core] logging_conf_file=./conf/logging.ini [TaskA]
https://buildersbox.corp-sansan.com/entry/2022/04/07/110000

Sansan エンジニアに関する記事

 

Sansan株式会社について

 

Sansan Tech Podcast

当社のエンジニアがお届けするPodcastです。Sansanエンジニアの技術のこと、カルチャーのこと、日々のSansanライフについて自由に語っています。