naoki86star

インターネットの片隅でなにかしら書いてみる

Amazon SQS in aws sdk

 こんどはAmazon SQSのAPIを使ってみた。*1

https://docs.aws.amazon.com/sqs/index.html

 これも特にすぐ利用する目的もなくちょっと動かした程度。結論的には、まあ選択肢の一つとしていいね、っていう感想。メッセージキューはいろいろシステム構築に使える手法はあると思うので、実装しやすさ、メンテナンスしやすさ、費用といつもの比較検討で考えていくことになる。
 - 実装は、しやすいのだけども、特性とかクセを理解してそれを考慮すると思ったよりあれもこれも準正常な処理を加えていくことになりそうな予感。なれない人間としてそう思った。
 - メンテナンスは、クラウドサービスという点が圧倒的に加点要素だと思う。ただジャンボな仕様変更が突然起こるとかは怖い。
 - 費用は曲者。今時点「1,000,000 Requests of Amazon Simple Queue Service」単位の課金で最初の1塊が無料枠、とかくAPI使ったリクエスト数で決まると理解。受信で短周期ポーリングすると1,000,000は結構小さく思える。だからそれを実装で緩和するような仕様もあるみたい。

 お試し時にアレっとおもったことは、メッセージキューの名前には含めていけないキャラクターがあったらしい。名前がアクセスポイントURLの一部になるのでそれで分かれよっていえなくもないが、ちょっととまどったです。



==
 コロナで個人的に思い始めたこと。日本でのコロナ対策が、失敗するシステム開発で起こることと、何かアナロジー的に似たにおいを感じる気がしてきた。1)どこのなにが悪いのか初期段階で明確に明示しない。皆、悪い部分は後からわかってくるが、その時点でも(最後まで)明確な説明はもらっていない2)効果のある対策をださずに進む。システム開発とかだとQA的なチームが教科書的な原因から教科書的な対応案を出してくるんだけども、できるかどうかは別問題。提言する人はそれ専門の立場の提言であるけども、それをマネージャーがどスルーでメンバー全員に”周知”して、やりましょう、にとどまる。最初はみな無理目でも作業するんだよねー。で数週がすぎていって進捗が少なくメンタルが疲弊。
 まぁでもこんな歴史的社会全般の難題に比べたら、システム開発なんて余裕でうまくいってもいいような気もした。

*1:仕事では、メッセージキューといえば昔のSystemV メッセージキューをsolaris2.5のときのとあるシステムで面倒をみていた。sendmsgにIPC_NOWAIT が指定されていて、でもEAGAIN時の処理がなく一発エラーでお守りに呼び出されるようなことになっていた。あの時は上限の決まってるnプロセスが同時にsendmsgしていてそれがたまる分は問題ないと判断し、IPC_NOWAIT をはずすという修正を選択した。遠い思い出。