安否確認の仕組みを真面目に考えてみた
安否確認の基本要件
安否確認が必要になったら自動で発動すること
ユーザが一気に来ても耐えられる事
ユーザの事前登録(通知先、居所)が可能なこと
(出来れば)マルチテナントで複数社が相乗り出来ること
ユーザの管理そのものは管理者が行うこと
費用はなるべく安く!
安否確認の情報はなるべく本家に近いところから取得として...
気象業務支援センター Japan Meteorological Business Support Center
地震速報(警報)に限定すれば3万円あれば十分
真面目に探すとサードパーティっぽいAPIはもっと安いので上限はこのくらい
ユーザの管理は色々面倒なので、Auth0あたりにまるっと任せる方針として
Auth0: Secure access for everyone. But not just anyone.
費用はMAU(月間アクティブユーザ)なので、ほぼ10ユーザのアクセスもないんじゃ無いかと想定。最大アクセスはユーザ管理したい全員なので...金額はpriceページでどうぞ
APIへのアクセスは常時実施する必要があるので、Fargateあたりで常駐させる前提
固定IPが必要な場合はNAT経由してと...
ユーザ情報、事前登録情報、警報情報はまるっとDynamoDBで管理
管理画面系はAPI Gateway & Lambda & S3で構築
安否確認とかトレーニングしないときの固定費がかかるのはこれくらい
ユーザ毎の費用は無視すると10万円いかない程度?
安否確認イベントが発生したら...
登録ページを用意(S3)
dynamodbにイベント情報を登録
fargateの通知taskを実行
戻りのURLはLambda@EdgeなURLにしてLambdaで直接DynamoDBに登録しつつ、集計
一定期間の間、定期的にLambdaで管理者への集計結果の通知メッセージ&緊急対応が必要な人のリストを送信
イベント発生時の費用はこれくらいなので...たぶん通知にかかる費用が一番高そうな程度でだいぶ安い
ほぼ固定の費用はないし、リクエストの上限も無視出来る(Lambda@Edgeのリミットに引っかからなければ)
ということで実はAWSとかSaaS使えば安否確認の仕組みって実装コストの方が圧倒的に高いだけだって事に気がついた夜中の地震でした
思いつきで書いたkotlinのコード
別に意味は無い
internal fun enumConditon() {
val noString = ConditionData("")
assertEquals(noString.enum, CDEnum.NOSTRING)
assertEquals("ERROR", perocessData(noString))
assertEquals("strが空です", getMessage(noString))
}
sealed interface DataAddType
class OK: DataAddType
class ERROR: DataAddType
class MISSING: DataAddType
data class ConditionData(
val str: String
) {
val enum: CDEnum = CDEnum.test(this)
}
enum class CDEnum(val condition: (ConditionData) -> Boolean,val addType: DataAddType, val msg: String){
OK(
{it.str.isNotBlank() && 10 <= it.str.length && it.str.length < 50}, OK(), ""
),
NOSTRING(
{it.str.isBlank()}, ERROR(), "strが空です"
),
LENGTH_OVER(
{it.str.isNotBlank() && 50 < it.str.length}, ERROR() ,"strの文字長がオーバーしてます"
),
LENGTH_MINI(
{it.str.isNotBlank() && it.str.length < 10}, ERROR(), "strの文字長が不足してます"
),
MISSING({true}, MISSING(), "判断外のエラーです");
companion object {
fun test(data: ConditionData): CDEnum = values().first { it.condition(data) }
}
}
fun perocessData(data: ConditionData): String {
return when (data.enum.addType) {
is OK -> "OK"
is ERROR -> "ERROR"
is MISSING -> "MISSING"
}
}
fun getMessage(data: ConditionData): String = data.enum.msg
SQLだけで 2WAY SQLっぽいことをやる
ぼんやりしてたらなんとなくイメージが沸いたのでちょっとやってみた
完全に同じ事が出来るかというと...微妙なのでっぽいこと
確認したのはpostgresqlだけ
select * from table1
where (:v is null OR field = :v)
ちょっとだけメモ
:v に null を入れるとis null がtrue になって、この()内の条件が常にtrueになる
:v が null 以外の時は field との比較になるので比較条件がチェックされる
技術に階層があるなぁって思った
ある技術Aを身につけるとして、それに必要な技術Bがあったときに、技術Bが他の技術のベースになってたり、応用に使えたりするのをよく見かける
ということは、「ベースの技術」を多く身につければそれだけ応用の技術にも対応しやすくなるんだろうなぁ〜ってある日、ふとある人と話をしてて思った
でも、目立つ技術とか流行の技術は応用の技術な事が多いから、ベースの技術は「いにしえの技術」って言われる中に埋もれて興味を持たれない様にも見える
ベースの技術かどうかの見極めが出来る程度のエンジニアならベースの技術を理解してるだろうし、それを伝えたくても書籍含めて廃版だったりして色々大変な時代だ...
数学とかなら足し算かけ算を理解せずに次に進めれないとかはわかりやすいのに、なんでソフトウェア開発はベースを身につけずに次に進めれるような気がしてしまうのか...
そんな難しいことを考える2022年の1/24が過ぎ去ったある日の土曜日
2022年令和4年 あけおめことよろ
あけおめことよろ
去年気がついた事
- 自分のプログラミングの方法と他の人のやり方が違うっぽい(詳しくはわからんw)
- 西野七瀬かわいい
今年やりたいこと
- コロナに感染せずに元気に生活する
- 運動する(2021比で増やす)
- 仕事する
- 飛行機飛ばすのもう少し上手くなる
- 良い所に引っ越せそうなら引っ越す
OSSとかメンテとかお金の話
同時にそのOSSのメンテしてるのが主に2人って見て
ぼんやり考えたこと...
世界中の先進国の新規開発と保守の予算の0.001%でもいいから使ってるOSSの寄付に回ればOSSの分野はいっきに成長しそうだなぁ〜っておもった
企業が人と予算を割り当てるような大規模OSSは良いと思うけど、小規模(かつニッチ)なOSSをやるとしたらそこにお金を出す人も居ないだろうしなぁ〜
Youtuberみたいにお金になればOSS開発したい!(この場合なにを?は置いておく)ってひとが出てきて、良いOSSなら贅沢は出来ないかも知れないけどお金になるみたいな流れになるともしかしたらburiも維持出来たのかなぁ...
今だとSpringBuriになるのか?でもブリの旬って冬だよな...
って、年の瀬にCVEって文字列を沢山見たのでちょっとおもった