みなさんこんにちは！サーバーサイドエンジニアの柿本です。
Zoom などの WEB 会議で自分の画面を共有している時、参加者の反応がよくわからなかったりチャットの投稿に気がつかないという経験をしたことはありませんか？
特に私はプレゼンの類が苦手（というか緊張する）なので、チャットのアイコンにバッジがついても全く気がつかないのです。
ならいっそのこと、動画共有サイトのように、参加者のコメントが画面上に流れるようにすれば流石に気づくでしょ！ということで、チャットの投稿が画面に流れるようにしました。
続きを読むこんにちは、プロダクトエンジニアリング部のちょうです。ずっと家にいまして時間の流れが気づきにくいと思いませんか。知らないうちに8月も何日しか残らないし、2021年も３分の２までが終わっています。家でテレワークしながら、何かおもしろいものないかなと考えたら、ふっと最近使っていたワクチン接種サイトを思い出しました。
ワクチン接種などのサイトは大量なユーザーから集中的なアクセスを予想できます。いくらサーバーを増やしてもさばけないと思われます。そしたら
などの施策が必要となります。アクセス時間帯を分けるのは利用するユーザーのIDなどをベースにアクセスできるタイミングを分散して集中アクセスを減らすアプローチです。そして減らした集中アクセスを予測してサーバーを増やすだけで対応できる可能性があります。すごくシンプルな考え方です。
そもそも負荷によって自動的にサーバーを増やして対応してもいいのではと思ってもかもしれませんが、ワクチン接種いわゆるチケット予約サイトはサーバーよりデータベースなどが先にボトルネックになってしまいます。複数枠、例えばワクチン接種予約の時間帯、を用意しても一つのレコードにロックをかけると、処理は一つずつになります（アクセスが集中するとき楽観ロックより悲観ロックがいいというデータがある）。案件によって、予約して裏側で非同期処理で結果を通知する仕組みもありますが、やはり時間内で結果を知りたいのが多いです。そうすると、リクエストをさばけるように事前に処理能力を計算し、サイトに入れるユーザーを制限するわけです。
制限といったら、API制限というのがあります。一般的にAPI制限はtoken bucketなどのアルゴリズムを利用し、一定時間内のアクセス数を制限します。これらのアルゴリズムは基本一台のサーバーなら簡単ですが、複数サーバーになると、Redisに計測値を共有して特殊のスクリプト（token bucketアルゴリズムにすくなくとも時刻と残るtoken数などのデータがある、Redisで安全に複数データを変更する方法がないため）で計算する方法があるらしいが、私が以前、1000回/60秒で2台でしたら500回/60秒を一台ずつ、サーバー数増減したら各サーバーの回数を自動的に調整できる仕組みを作っていました。ただ、API制限は基本チケット予約サイトに使えません。制限を超えたら、エラーになるだけです。ユーザーにとっては、「ただいまアクセスが集中しています」みたいの表示になり、リロードを試みるしかないです。
残りはキュー一択になります。自分の知る限り、ticket master、オリンピックチケット予約サイトなどに入ると、あなたがいま何番目のが表示され、自分の番になるまで待つだけでいいです。とても親切のように見えます。中身は何なのかはおそらく作った人しかわからないですが、今日は自分の理解でどうすれば同じ仕組みを作れるかを説明してみたいと思います。
処理能力内でしたらサイトに入る、処理能力を超えたら待つという仕組みは実際並列処理のSemaphoreととても似ています。Semaphoreに決まった数の許可（permit）があり、許可を取ろう（acquire）とするとき、まだ許可が残っているなら即時成功、残っていないなら待つ状態になります。一方、許可を取得したスレッドが許可を戻す（release）するとき、待っているスレッドがあればその許可をもらって処理を続けます。ここまで理解できるひとは「同時に取ろうとするスレッドがあれば誰がその許可をもらう？」という疑問を持っているかもしれません。ここで最初に待っているスレッドがもらうなら公平（fair）なSemaphoreといい、同時に取ろうとするスレッドが取れる場合は不公平（unfair）なSemaphoreといいです。現実でいうと先頭に割り込みとなります。ではSemaphoreとチケット予約サイトを比較してみましょう。
| チケット予約サイト | Semaphore |
|---|---|
| 予約者 | スレッド |
| サイトに入る | 許可を取る |
| 予約完了 | 許可を戻す |
| 待ち画面 | スレッドが待つ |
| 予約画面に入る | スレッドが起きる |
Unifa プロダクトデベロップメント本部 副本部長の西川です、こんにちは。
今日は予告通り、前回決め方の数理2：勝率の数理(AND編)の続きです。 テーマは、「ORはANDよりも強し。だが……」です。
こういう思わせぶりなテーマにつられ、長文記事をつい最後まで読んでしまう…
そんな好奇心旺盛なあなたのご参画を、Unifa一同、絶賛お待ちしております！
(という採用PR)
こんにちは、データエンジニアリングチームの宮崎です。
少し今更ですが、最近SageMakerにオリジナルのTensorFlowモデルをデプロイできることを知ったので試してみました。 (これまでSageMakerで学習したモデルしかデプロイできないと思っていました…。)
以前、コチラの記事でAWS Lambda上にTensorFlowモデルのデプロイについてご紹介しました。 しかし、AWS Lambdaですとコールドスタート時は応答に20秒前後かかり、応答速度が求められるタスクには辛いところがあります。 また、常に多数のクライアントから推論リクエストがくるケースにも不向きです。 そういったケースはTensorFlow Servingが良さそうですが、ECSにデプロイしようとすると、ロードバランサなどの設定も必要で少々面倒です。
そこで今回は、マネージドでTensorFlow ServingをデプロイしてくれるSageMakerを用い、オリジナルのTensorFlowモデルをデプロイしてみました。
続きを読む
こんにちは、プロダクトマネージャーの田嶋です。
はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑
週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！
続きを読む