ユニファ開発者ブログ

ユニファ株式会社プロダクトデベロップメント本部メンバーによるブログです。

補聴器をハックしようとしてハマった話。

こんにちは、ユニファの開発・インフラエンジニアマネージャーの田渕です。

気づけば今年も10月になり、あと数ヶ月で2021年が終わりになろうとしています。 ここ数年は毎年恒例アドベントカレンダーもあるので、まだあと何回かブログを書く機会もあるのかなぁと思います。

2021年もコロナに翻弄された一年でしたが、個人的には前回の執筆記事で書いたように文明の利器を使って聴力を補えた!が割と大きなお話でした。 そんなわけで今回は、「補聴器をハックしようとしてハマった話」をお届けしようと思います。 あまりにもニッチすぎて市場の需要がないのは十分に理解しているのですが、私に需要があるので敢行します。

続きを読む

PythonでS3のファイルを読み書きする

こんにちは、データエンジニアリングチームの宮崎です。

ユニファではAWSを使用しており、画像やCSVなどの各種データもS3に保存しています。 そのため、データ分析したいときはS3のデータをダウンロードして行うのですが、その際ディスクに保存して読み込むのは時間や手間がかかります。 そこで、今回はPythonでS3上の画像やCSVデータを直接メモリに展開して読み書きする方法をご紹介します。

続きを読む

地方在住のエンジニアのフルリモート採用を始めました!!

f:id:akanuma-hiroaki:20210914234130j:plain

皆様こんにちは、ユニファCTOの赤沼です。

ユニファでは以前から開発メンバーの採用に力を入れていまして、いろんなところで採用アピールをさせていただいているわけですが、この度エンジニア職を対象に、日本国内の地方在住の方のフルリモートでの採用を開始しました!

ユニファの開発チームではコロナ禍以前からリモート勤務自体は取り入れていまして、特にコロナ禍以降は実質的にフルリモートに近い形ではありましたが、必要に応じて出社いただける範囲にお住まいの方を採用の対象としていました。

しかしエンジニア採用の競争が激しい状況で、優秀なエンジニアの方にご入社いただき、より開発チームを強くしていこうという中で、コロナ禍でリモート勤務がより一般的になり、地方に住みながらリモートで仕事をされたい方も増えている状況を踏まえ、フルリモートでの採用を開始することにしました。

続きを読む

「ルクミー ドキュメンテーション」に関する ありがとう を書いてみた!

こんにちは、PdM(プロダクトマネージャー)の田嶋です。

昨年より企画を担当していた「ルクミー ドキュメンテーション」が先日ローンチされ、9/1より園・施設のみなさまにご利用いただけるようになりました 🎉🎉 lookmee.jp

私にとってはユニファへ入社してはじめて携わったプロジェクトで、プロダクトとしては本当にまだ何も検討されていないところから作り上げていったため、開発工程以降は担当をバトンタッチをしたものの、勝手に我が子を見守るような気持ちで眺めていますw

続きを読む

Slack の投稿を画面上に流そう!

みなさんこんにちは!サーバーサイドエンジニアの柿本です。

Zoom などの WEB 会議で自分の画面を共有している時、参加者の反応がよくわからなかったりチャットの投稿に気がつかないという経験をしたことはありませんか?

特に私はプレゼンの類が苦手(というか緊張する)なので、チャットのアイコンにバッジがついても全く気がつかないのです。

ならいっそのこと、動画共有サイトのように、参加者のコメントが画面上に流れるようにすれば流石に気づくでしょ!ということで、チャットの投稿が画面に流れるようにしました。

続きを読む

集中アクセスに対応するサイトの仕組みについて考えてみた

こんにちは、プロダクトエンジニアリング部のちょうです。ずっと家にいまして時間の流れが気づきにくいと思いませんか。知らないうちに8月も何日しか残らないし、2021年も3分の2までが終わっています。家でテレワークしながら、何かおもしろいものないかなと考えたら、ふっと最近使っていたワクチン接種サイトを思い出しました。

ワクチン接種などのサイトは大量なユーザーから集中的なアクセスを予想できます。いくらサーバーを増やしてもさばけないと思われます。そしたら

  1. 接続数を制限
  2. アクセス時間帯を分ける
  3. キュー

などの施策が必要となります。アクセス時間帯を分けるのは利用するユーザーの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
予約者 スレッド
サイトに入る 許可を取る
予約完了 許可を戻す
待ち画面 スレッドが待つ
予約画面に入る スレッドが起きる
続きを読む

決め方の数理2:勝率の数理(OR編)

Unifa プロダクトデベロップメント本部 副本部長の西川です、こんにちは。

今日は予告通り、前回決め方の数理2:勝率の数理(AND編)の続きです。 テーマは、「ORはANDよりも強し。だが……」です。

こういう思わせぶりなテーマにつられ、長文記事をつい最後まで読んでしまう…
そんな好奇心旺盛なあなたのご参画を、Unifa一同、絶賛お待ちしております!
(という採用PR)

unifa-e.com

続きを読む