AWS CodeBuildでカスタムイメージを使ってRuby 3.0のCIができるようにする

Webエンジニアの本間です。 最近、急に寒くなりましたね、鍋が美味しい季節になりました。 今シーズン、みなさんは何鍋から始めますか？自分は安定のごま豆乳鍋でした。

さてRuby 3.0がリリースされてからそろそろ10ヶ月が経過しようとしており、弊社でもRuby 3.0ベースでアプリケーションを開発する機会が増えてきました。 しかし、1つ問題があります。なんと、いまだに CodeBuildのランタイム にRuby 3.0が追加されません。 そのためせっかくRuby 3.0で新しいアプリケーションを作っても、CodeBuildでCIをサクッと動かせない問題がありました。

Ruby 3.0のCIをCodeBuildでやろうとする場合、以下のいずれかの対応が必要になると思います。

1. CodeBuild内でRuby 3.0をインストールする。
2. Ruby 3.0を追加したCodeBuild用のDockerイメージを作成し、CodeBuildで使う。
3. CodeBuild内で ruby:3.0 のイメージをpullして、Dockerを使って動かす。

1の方法は、時間がかかるため現実的ではありません。 2と3の方法が現実的ですが、今回は「2」の方法を使ってRuby 3.0をCodeBuildで使えるようにしてみたのでご紹介しようと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
予約者	スレッド
サイトに入る	許可を取る
予約完了	許可を戻す
待ち画面	スレッドが待つ
予約画面に入る	スレッドが起きる