yoshiki-0428

案件概要

「みんなのサブスク」という今までなかったサブスクレビューサービスをゼロから企画をし開発しました。「本当に必要なサブスクサービスをあなたに」というキャッチコピーでわかりやすいデザイン、レビュー入力しやすいデザインで構成しています。

開発に至った経緯

サブスクサービスが年々急激に増えていくのに対しユーザにとって適切なサブスクサービスを選びづらい状況だと考え企画兼開発をしました。サブスクはいわば固定費となるのでユーザにとっては慎重に選びたいと考えるはずで私自身も様々なサブスクを登録しておりどれだけお金を支払っているのか管理できなくなりつつあったので、登録している全サブスクの月料金を確認でき、サブスクのレビューやユーザストーリーを確認できるWebアプリが必要とされていると考え開発に至りました。

課題解決

管理画面をゼロから作らない工夫

今回、StrapiというCMS OSSを利用し開発に至っています。よくあるCtoC Webアプリでは管理画面の開発がボトルネックかと思います。今回の開発予算もそれほど多い案件ではなかったため、どうにか管理画面というコストを下げるべく、様々なCMS SaaSを検討しました。

検討したCMS SaaS

• Contentful
• esa.io
• airtable

ですが、結局どれも伸びてきた頃にはデータの移行作業が発生してしまいあまり拡張性がないと判断し、StrapiというCMS OSSを選択しました。StrapiはGUI or JSONでDB定義を設定でき、DBもMySQL, pg, MongoDBなど様々なOSSを選択することができます。伸びてきた頃に集計処理や細かいグルーピングなどをしたくなってきた頃にAPI開発を行えば良いと判断し選択しました。

結論を言うと「まずはMVPを重視しStrapiを選択」しました

toC アプリなのでBackendコストよりもFrontendコストに注力する

業務アプリならいざしらずtoCアプリはUI/UXが非常に重要です。少ない開発リソースをFrontendに注力するため、Frontendに人員を裂き画面優先で開発を進めました。バックエンドは後からなんとでもなると判断し、UI/UXに注力しました。

おかげで約50人のアンケートで半数以上がデザインが良いと判定をしていただけました。

案件概要

マイクロサービスアーキテクチャで構成されており、医療機器(IoT)からPOSTされるレコードをMessagingAPIでDBに保存をし、保存されたデータをリアルタイムにダッシュボードに表示させ、医療従事者に稼働状況などの監視情報などの価値を提供するシステム開発です。

課題解決

バックエンド別

1000万レコード以上あるテーブルをサマリーする機能の速度を60秒から0.6秒の100倍にした話

• 1日に1秒間間隔で機器のステータス情報がDBのレコードに保存される仕組みがあり、そのレコードを1日毎、1時間毎でサマリーする機能があった。
  • 日時情報をto_char関数で変換した値をGroup Byをしており、レコード量が多ければ多いほど指数関数的にクエリー時間が増えるという課題があり、SQLチューニングし課題解決した
  • 案件の性質的に要件定義、設計、実装のフローが早く、当時はとりあえずの実装になっていた。
    • 試行したこと
      • to_charをする項目を増やしその項目に対し、Indexを貼る
        • 速度は倍になったが、実用でないため不採用
      • Materialized Viewを使用し、1時間毎の集計データをViewに保存し解決
        • 100倍になりました。

Matelialized Viewの更新をk8sのCronJobタスクで自動化

• Materialized Viewは定期的にRefreshが必要であり、以下の方法を模索しコストの低いCronJobタスクで解決をした。
  • 対象テーブルのInsertをトリガーにViewを更新する
    • 1秒間隔でInsertされるため、DBコストが高いため不採用
  • k8sのCronJobタスクで指定時間にRefreshコマンドを起動させる
    • 要件的に更新されるべきタイミングが1日毎だったため採用

海外タイムゾーンの対応

• 当時の課題
  • システムを将来的には日本以外の国で使うことになるため、GMT基準でシステムが組まれていた。
    • 課題は、APIとフロントエンド間は　どんな形（日時表示なのかUnixタイムスタンプなのか）で誰がローカル時間に変換する役目を担うのか。
    • 試行したこと
      • バックエンド側でバックエンドのシステムタイムゾーンで変換し日時表示で返却を行う
        • バックエンドの設定タイムゾーンで日時が変わってしまう。
        • （アメリカから日本のサーバにアクセスされると日本時間で返却をしてしまう）国別にサーバを置くことは現実的ではないため不採用
      • 取り扱う日時をUnixタイムスタンプにし、サーバ側では完全にUnixタイムスタンプで連携し、フロントエンド側で設定のタイムゾーンで変換を行う。
        • フロントに一任することによりブラウザのタイムゾーンが適用されるためコストが少なく、海外タイムゾーン対応が実装できた。

SPAとAPI間の認証周りをSpringCloudGatewayで解決した話

• 案件の認証の仕組み
  • AWS Cognitoのような外部認証サービスを使用しOAuth2で認証することにより、ユーザログインを行う
• 当時の状況
  • 認証基盤の実装がとりあえずのもので正しく実装されていなかった（固定アクセストークンでシステムにログインをするような状態）
• 試行内容
  • SpringCloudGatewayという最新のFWの認証を使用しOAuth2の実装を完了（Api-keyやSecret-key、Redirect URLなどの設定情報を記述することで認証周りの処理を行ってくれる）
  • MicroService的な思想で構成されているため以下のような構成となる
    • Front <=> SpringCloudGateway <=> API (BFF) <=> その他API
  • 当時あまり日本語の情報がなかったが、GitHubのサンプルコードなどを参考にシステムを構築し解決しました。

画像データ、マスターデータをRedisでキャッシュする対策

• 当時の課題
  • APIサーバのリソースは限られており、余分に画像の取得などでリソースを無駄に使用していた
• 解決内容
  • 画像データやマスターデータを取り持つためにRedisでテキストデータで保存し、余分なリクエストを減らすことができた

フロントエンド別

医療機器の3Dモデルをリアルタイムに動かすことができるDigitalTwin（手術ロボット）の稼働部分をThree.jsのAnimationでリアルタイムに動かす

• 当時の課題
  • TypeScript用のサンプルコードが少なく、Three.jsをリアルタイムで動かすという実装をしている人が少なかった
• 解決内容
  • 別チームに3Dモデルの作成、パーツごとの動きの設計をしてもらい、MessagingAPIで受け取ったパーツ動作情報をThree.jsに当てはめ、リアルタイムに動く機能を実装した。
  • Animationクラスがリアルタイムの動きに対応していないので、別でWrapするクラスを作成し解決した。

案件概要

読んだ本に対してTOI(問)を与え、回答するだけで本に対して理解が深まる。インプットとアウトプットが両方できるWebアプリです。
構成は、API部（Java）Front部（Vue.js）で別れており, AWS EC2, AWS Amplifyで構成されています。

課題解決

本の情報をRakuten Books APIより取得し、本情報を外部化する

• 本の情報のリソースを内製すると手間と時間がかかる
  • Rakuten Books APIを使用することで外部の本情報を利用することができた
  • 更にOpenAPIのYML形式でAPIドキュメントを作ることでほとんどコードを書くことなく、外部APIの呼び出し部分の作成することができた

BtoC用に外部ユーザを手軽に取り込めるようにしたい(OAuth2認証を実装)

• Spring OAuth2 Clientを利用することでOAuth2認証を手軽に実装。認証に必要な情報を設定するだけでOAuth2の認証を実装
  • 認証ベンダーとしてAWS Cognitoを利用。（外部のサービス連携が強く、コストが低い）