千田 航己 / koki.senda

自己紹介

SREのせんちゃんこと千田です。 AWSやKubernetesなどのインフラ管理、サービスのモニタリング、複数のアプリケーションで横断的に使われる基盤システムの開発などをしています。 音声コンテンツが好きで、家にいるときはほとんどずっとVoicyやPodcastを聴きながら生活しています。洗い物をしながら聴くのが至高の時間です。 音声自体にもともと興味があり、学生時代にはディープラーニングに基づく音声変換の研究をしていました。 最近の趣味は将棋とギターとオムライス作り。

Voicyの好きなところ

Give Firstの連鎖が回っているところ

好きなVoicyパーソナリティ

私が思う「声で未来をつくる」

カジュアルに話してみる

音声を聞いてみる

入社エントリー

経年エントリー

ピックアップコンテンツ

Go実装のAWS LambdaでSQSを使う
AWS LambdaのランタイムとしてGoを採用した上でAmazon SQS (Simple Queue Service) を使う機会があったので、その際のコードの書き方を簡単にまとめました。 トリガーの設定等、コード以外の部分は別の資料を参照してください。 また、記事の最後に「GoでLambdaってどうなん?」という話を書いたりもしています。 まず、実行したい処理を関数として実装します。今回は Handler という名前です。 main関数内で lambda.Start(Handler) とすることでLambdaで実行可能となります。 このとき、SQSトリガーを設定した上でHandler関数の引数を context.Context、 events.SQSEvent とすることで、SQSに挿入されたメッセージをGoのプログラムで受け取れます。 func Handler(ctx context.Context, sqsEvent events.SQSEvent) error メッセージ本体は sqsEvent.Records[].Body に保存されています。 JSONで受け取って以下のような Input という構造体にマッピングする例を示します。 今度は、トリガーとなるSQSキューとは別のキューにメッセージを送信したいときの書き方です。 キューURLの用意と、SQSクライアントの作成をします。 キューURLを環境変数として渡す場合の例を書きます。 キューURLは長いので、キュー名を渡しておくこともできます。 この場合、プログラム内でキュー名からキューURLを取得します。 キュー名で直接送ることはできないようです。キュー名は特定AWSアカウントの特定リージョン内でしかユニークでないためです。 以下は、送りたいメッセージ msg Message (構造体) をJSON文字列化してキューに送信する例です。 まず、 sqs.SendMessageInput を作成します。 このとき、この構造体の MessageBody フィールドに送りたいメッセージを、 QueueUrl フィールドに送り先となるキューのURLを指定します。 その後、これを引数に sqsSvc.SendMessage() すると送信できます。 sqsSvc と queueURL は準備のときに作成しておいたものです。 メッセージがスライスで与えられ、1回のリクエストでまとめて送りたいという状況も考えられます。 こちらの方が速度的にも有利です。 すでにJSON文字列化されたメッセージのスライス msgJsons []string が与えられたとして、それらをバッチ送信するコードが以下です。 1件だけ送信する場合とほとんど同じで、 sqs.SendMessageBatchInput を引数として sqsSvc.SendMessageBatch() を実行することでバッチ送信ができます。 違う部分としては、 sqs.SendMessageBatchInput のフィールドに MessageBody ではなく、 Entries を持ちます。ざっくり言うと、メッセージが複数なので、スライスになっているだけと考えて問題ありません。 なお、 sqsSvc.SendMessageBatch の戻り値である sqs.SendMessageBatchOutput を使うことで、バッチ送信した際に一部だけ失敗した場合のハンドリングが可能ですが、本記事では扱いません。 という一連の処理の全体像が以下です。 メッセージの送信は、バッチ送信ではなく、1件ずつ送る方法で書いています。 LambdaといえばNode.jsかPythonで書くのが一般的だと思いますが、Goで実装するのも悪くないです。 やはり静的型付け言語は書きやすいです。 とはいえ、Lambdaを使うタイミングではインスタントに素早く実装したいことも多いと思うので、自分が慣れた言語を使えばいいと思います。 Goを使うメリットとして、ランタイムのバージョンがひとつしかないことが挙げられます。2022年10月現在、LambdaのGoのランタイムは Go 1.x のみです。 そのため、頻繁にアップデートする必要がありません。Goの後方互換性のおかげですね。 参考までに、現在Node.jsは12, 14, 16、Pythonは3.7, 3.8, 3.9のランタイムが提供されており、マイナーバージョンが更新される度に別のランタイムとして扱われます。 デメリットは、各種サポートがメジャー言語から若干遅れることです。 ...
SQSをイベントソースとしたLambdaをTerraformで定義する
こんにちは、@thousan_da です。 本記事では、Terraformを使って、AWS Lambda, Amazon SQSのリソースを定義する方法を紹介します。 また、SQSをLambdaのイベントソースとして設定します。 これにより、SQSにデータがエンキューされるとLambdaが実行されるようになります。 最低限定義する必要があるリソースは以下の3つです。順に説明していきます。 resource "aws_lambda_function" resource "aws_sqs_queue" resource "aws_lambda_event_source_mapping" 参考 ランタイム (言語) ごとに異なります。 スクリプト言語の場合は{ファイル名}.{関数名} という仕様となっている場合が多いようです。 Goの場合は、コンパイル後の実行ファイルのパスです。 参考 SQSへのアクセスを許可したIAMロールを紐づけておきましょう。 以下の権限が必要です。 sqs:ReceiveMessage sqs:DeleteMessage sqs:GetQueueAttributes 参考 参考 message_retention_seconds メッセージの保持期間を秒で指定します。エンキューされてから、この秒数が過ぎたメッセージは消去されます。 visibility_timeout_seconds 可視性タイムアウトを秒で指定します。これが一番よくわからないと思います。 SQSは、メッセージを配信した際、その瞬間にメッセージを消去するわけではありません。一時的に見えない状態にして保持しておきます。 SQS => Lambdaの例では、SQSからLambdaにメッセージが渡されると、渡したメッセージはSQS上で見えなくなります。その後、Lambdaがそのメッセージを正常に処理したことが確認されてから消去します。 この「一時的に見えない状態にしておくこと」が可視性タイムアウトです。 また、一定期間正常に処理されたことが確認できない場合、一時的に見えなくしておいたデータを再度見えるようにして配信します。 visibility_timeout_seconds に設定するのは「配信して見えない状態になってから再度配信できる状態に戻すまでの時間」です。 参考 receive_wait_time_seconds この値により、SQSに対してキュー内のメッセージをデキューするリクエストが来た際、キューが空の場合の挙動が変わります。 0以上、20以下の値を設定することができ、 0に設定すると、キューが空でも即座にレスポンスを返します。この挙動をショートポーリングと呼びます。 1以上に設定すると、キューが空のときは設定した秒数だけ待ってからレスポンスを返します。この挙動をロングポーリングと呼びます。 参考 Amazon SQS ショートポーリングとロングポーリング https://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html Amazon SQSのロングポーリング設定でコストを99%削減した話 https://tech.uzabase.com/entry/2021/02/22/124454 fifo_queue = true を指定すると、FIFOキューとして作成できます。 SQSには2種類のキューがあります。 標準キュー: レコードの順序が入れ替わったり、同じレコードが複数回配信されたりすることがたまにあるが、処理が高速 FIFOキュー: 順序が保証されており、同じメッセージが複数回配信されることもないが、標準キューよりも遅い ちなみに2021年3月にFIFOキューに高スループットが正式リリースされ、処理速度が向上したそうです。 Lambdaでの処理でなんらかのエラーが発生した場合、エラーとなった実行のトリガーとなったメッセージをデッドレターキュー (Dead Letter Queue; DLQ) と呼ばれる別のキューに送る機能があります。 これを定義することで、SQSにデータがエンキューされるとLambdaが実行されるようになります。 resource "aws_lambda_event_source_mapping" "mapping_for_sugoi_function" { batch_size = 10 maximum_batching_window_in_seconds = 5 ...

音声アウトプット

テキストアウトプット

その他アウトプット