/var/log/blog

主にサーバー・インフラやシステム開発に関する公開学習メモや雑な記録

Slack Bot 作成時に、Slack からのリクエストを検証する方法のメモ

WIP

Slack Bot を作成する際に、Slackからのリクエストを検証する方法について調べたメモです。

Slackからのリクエスト検証手順

必要なもの

  • Signing Secret
  • Slack から送信される HTTP リクエスト(例えばスラッシュコマンド実行時にSlackから外部へ送信されるリクエスト)

手順

Slack 公式ドキュメントにも記載されていますが、リクエストの検証は以下のステップで行われます。

Signing Secret の取得

Slack のリクエストからタイムスタンプの取得

バージョン番号、タイムスタンプ、リクエストボディをコロン（:）で区切って連結

署名シークレットをキーとして、結果の文字列をハッシュ化し、ハッシュの16進ダイジェストを取得

生成された署名をSlackからのリクエストのヘッダーと比較

AI エージェントの台頭してきた中でのシステムエンジニアリングに関して思うところ

AI エージェントを使ったシステム開発は面白い。特に設計の壁打ちをよく行なっている。

LLMツールが進化し、自然言語による説明からコードを生成できたり、既存コードを最適化することが容易になってきていると感じる。

この楽さに危機感も感じる。対して思考しなくてもアウトプットが出てきてしまう。しかもかなりのスピードで。 この便利さに頼りすぎると、開発者のスキルが向上しなくなる可能性がある。AI エージェントはあくまでツールであり、開発者自身の理解や創造力も必要で、これをおろそかにしていくと、開発者としての成長は無くなってしまうように思う。

アウトプットばかりに意識が行き過ぎると、高速に何かが出来上がることに満足感を覚えてしまい、一方でそれに必要な知識や技術の理解が追いつかないまま物事が進んでしまう。 ゆくゆくはそれでも成り立つ未来が来るかもしれないが、個人的には自分が扱う技術領域に関しての知識や理解も深めていきたい。

一定知識がないと生成されたものの良し悪しも判断できなくなり、自分の頭を使っての意思決定する能力も衰えていく気がするので、学習していく姿勢も大事にしたい。

DynamoDB で時系列データを扱うテーブルを作成する時に参考にしたいドキュメントや公式ブログと設計観点のメモ

それなりの量のイベントログに相当するデータを保存したいとなったときに、DynamoDBを使う場合にどうするのが良いのか調べた自分用のメモです。

設計メモ

テーブル設計

1つのテーブルにデータを投入すると検索などのWCUを意識する必要が出てくるので、保存期間ごとに分けてテーブルを作成していく、というやり方があるらしい。

例えば以下のような形。

  • 2025/05/10 のデータを保持するテーブル
  • 2025/05/09 のデータを保持するテーブル
  • 2025/05/08 のデータを保持するテーブル
  • :

リアルタイムに保存する場合だと、日付の境目のデータをどう保存するか考える必要がありそうだが、バッチ処理なら良さそう。

Lambdaとかで事前にテーブルを作るというやり方が紹介されている。

パーティションキー

パーティションキーはテーブルのデータが格納されている論理パーティションになる。 例えば日付yyyy-mm-ddをパーティションキーとした場合、2025-05-10のデータは、DynamoDBの裏側では同じところに保存されるようなイメージになる。そうなるとI/O リクエストが分散されない。

そのため、今日の日付を表すパーティションキーの場合は、1 と N の間の乱数を選択し、それをサフィックスとして日付に連結する、などにすると良い。

  • 2025-05-10.1
  • 2025-05-10.2
  • :
  • 2025-05-10.128

特定の日のすべての項目を読み込むには、 2025-05-10.1.N キー (ここで N は 1 〜 128) をQueryする必要があり、アプリケーションはすべての結果をマージする必要があるという手間は発生する。 ただ、こうすると、IOが特定のパーティションに集中せず、分散できる、というメリットがある。

参考

MCP 公式チュートリアルの MCP Client の QuickStart を TypeScript でやってみた

前回作った MCP Server と接続して動作するためのMCP Clientがどういうものか理解するためにチュートリアルをやってみたメモです。

続きを読む