How to use React Hook Form at Next.js | Pathee Advent Calendar 2021 Day 25
これはPathee Advent Calendarの25日目の記事です
こんにちは。土田です。
気持ちをリフレッシュさせるために、タイトルを英語にしてみました!
でも全然リフレッシュしなかったあげく、5日目の予定だった記事を25日目にしてしまいました!!
圧倒的敗北、無念!!!
・・・今回はSTORECAST Managerで採用したReact Hook Formについて、Next.js基準で利用方法を書いていきます。
続きを読むAWS Lambda(など)の失敗をうまく取り扱う
Calendar for Pathee | Advent Calendar 2021 - Qiita
Pathee Advent Calendar 2021 9日目の記事です。
STORECASTエンジニアのkeisei1092です。
Patheeにジョインし、バックエンドを本格的に触るようになってから間もなく丸2年となります。
STORECASTにおける非同期処理や定期実行処理は、Serverless Frameworkを用い、AWS Lambda、Step Functionsなどのリソースをデプロイして動いています。
Lambdaでの処理や内外との疎通において、失敗をうまく処理することは大切です。 今年までに対応を行ったケースを振り返ってみたいと思います。
Lambda内でのAPIエラーについて
Lambda内でAPIリクエストを行った際に、エラーが返ってきた場合、エラーの種類によって、以下のような対応をします。
- 400系エラーの場合
- リクエストに問題があるため、エラー内容を通知し、処理終了
- 500系エラーの場合
- サーバに問題があるため、リトライを行う
- サーバ側が詰まっていることが考えられるため、間隔を開けてリトライを行う
- retrying モジュールを使うとお手軽に実装できる
Step FunctionsのMapステート内部の失敗について
Step FunctionsのMapステートを使って、複数のタスクを順番に実行する際に、あるタスクがエラー終了すると、後続のタスクが処理されません。
これを防ぐために、Mapステート内のエラー終了する可能性のあるタスクにはCatchフィールドを、後続のステートとしてHandleExceptionステート(名前は何でも良い)を定義します。
失敗しても後続のタスクが実行されるようなMapステートの例を以下に示します。
SomeState: Type: Map InputPath: "$.some_ids.body" ItemsPath: "$" MaxConcurrency: 1 Iterator: StartAt: SomeFunction States: SomeFunction: Type: Task Resource: arn:aws:states:::states:startExecution.sync Parameters: StateMachineArn: Ref: SomeFunction Input: AWS_STEP_FUNCTIONS_STARTED_BY_EXECUTION_ID.$: "$$.Execution.Id" some_id.$: "$" OutputPath: "$.Output" Catch: - ErrorEquals: - States.ALL Next: HandleException End: true HandleException: Type: Pass End: true End: true
ErrorEquals
の中に例外の名前を指定すれば、特定の例外の場合にのみCatchすることも可能です。
Retryフィールドも併用すれば、再実行したい例外の種別と終了したい例外の種別で流れを分けることができます。
SQSからトリガーしたLambdaのエラーについて
SQSのメッセージ経由でLambdaを実行する際、SQSの以下の概念を理解しておくとエラー時の流れを追いやすいです。
- メッセージ保持期間 (Message Retention Period)
- キューに存在するメッセージが削除されるまでの期間
- 累計受け取り回数 (Maximum Receives)
- キューに存在するメッセージが削除されるまでの受け取り回数
- デッドレターキュー (Dead Letter Queue)
- 正常に処理できないメッセージを移動するキュー
SQSのメッセージ経由で実行されたLambdaがエラー終了した場合、そのメッセージがキューの指定したメッセージ保持期間以内かつ累計受け取り回数以内であれば、キューに戻ります。
キューに戻ったメッセージは、再度Lambdaに渡って実行されます。
メッセージ保持期間を超えたり、累計受け取り回数分失敗し続けたメッセージは、デッドレターキューに移動されます。
デッドレターキューには、届いたメッセージをSlackに通知するLambdaを連携させたキューを設定することで、失敗し続けたメッセージを開発者が検知する運用にしています。
終わりに
この辺の動きは見えにくく、概念を知らないと追うのが難しいですが、一度理解すれば以後運用しやすいです。
AWSのマニュアルで各サービスの概念や、処理の流れをよく理解しておき、今後別のサービスと疎通する場合にもしっかり開発時の考慮に組み込めるようにしていきたいです。
リモートワークのスクラム開発で仕事をうまく切り上げたい! | Pathee Advent Calendar 2021 Day 4
これはPathee Advent Calendarの4日目の記事です
こんにちは。エンジニアリングマネージャの土田です。
すでに連続で書くのが厳しくなってきましたが、頑張っていきたいです。
リモートワークで働きすぎ問題
世間的にはリモートワークにすると「社員がサボるんじゃないか?」を管理職が気にする、といったような記事があったりなかったりしますが、 私は本来管理職が気にすべきことは仕事の成果と社員のメンタルだと思っているので、サボるのであればサボるような仕事の振り方をしている自分に問題あるという認識でいます。
仮に、社員自身としてはサボっていたとしても、期待している成果が出ているのであれば、それはそれで成果を出すためのプロセスだと考えているので、良いと思っています。
ただ、これはエンジニア独特の傾向なのかもしれませんが、リモートワークにするとサボるよりむしろ働きすぎてしまう傾向にある気がします。
実際、ふと見逃していると、23時まで働いているメンバーがいたり、自分自身が夜中までやっていたりするので、これをどうしたものかというのは悩みとしてあります。
オフィス勤務であれば、「帰れ帰れー、コミットは明日しろー」と言って帰したり、「終電だ!やば、帰らなきゃ」と外部要因をトリガーに仕事を切り上げたりできるのですが、 各自の働いている場所がそもそも家なので、やろうと思えば際限なく仕事ができてしまいますよね……
特にスクラム開発では、タスクを上から順々に取っていくので、自分の次やることが明確なのも、仕事を続けやすくなっている要因かと思います。
本来はその効果を期待しているので、皮肉なところです。
そこで、定時での切り上げを周知するのとは別に、ある施策を考えてみました。
続きを読むフルスタックNext.jsアプリケーションのディレクトリ構成 | Pathee Advent Calendar 2021 Day 3
これはPathee Advent Calendarの3日目の記事です
こんにちは。土田です。
前回STORECAST Managerのお話をさせていただきましたが、
今回は、フルNext.jsのアプリケーションで、どういったディレクトリ構成を取って開発しているのかをお話させていただきます。
続きを読むSTORECASTの管理アプリケーションについて | Pathee Advent Calendar 2021 Day 2
これはPathee Advent Calendarの2日目の記事です
こんにちは。土田です。 実はテックリードも兼務しているので、今日はそちら側の色強めで書きたいと思います。
STORECAST Manager
弊社プロダクトのSTORECASTですが、まだプロダクト自体が手作ぐりなため、管理アプリケーションの検討まで手が回っていない状態でした。 これからSTORECASTを成長させていくためにも、そろそろ管理アプリケーションが必要な感覚があったのと、ちょっと検証したいこともあったので、 10月くらいからSTORECASTの管理アプリケーション作成に着手し始めました。
ちなみに弊社の管理アプリケーションは伝統的(?)に「Manager」が付いているので、 STORECASTの管理アプリケーションも「STORECAST Manager」という名前になりました。
続きを読む