まもりあいJapanの知見がまじすごいのでもっと注目されて欲しい

プログラム全般

まもりあいJapanのコードがオープンソースとして公開され、過程もnoteとして公開されました。

同じCode for Japanの東京都新型コロナウイルス感染症対策サイトと比べるとあまり注目されていないのが、めちゃめちゃもったいないです!

全体的に勉強になる点がたくさんあるのですが、特にサーバサイドのアーキテクチャが、私が欲しかったものだったので、(勝手に)勉強させていたく事にしました。

今回は、そもそも何がすごいのか、について少しでも伝えられれば、、、と思っています。

まもりあいJapanって?

あらまし。

Code for Japanが接触確認アプリ「まもりあいJAPAN」のソースコードをGitHubで公開 | Techable(テッカブル)
一般社団法人コード・フォー・ジャパン(以下「Code for Japan」)による接触確認アプリ「まもりあいJAPAN」のソースコードが、今月18日にGitHubで公開された。 同団体がアプリを開発する中で培ってきた知見...

東京都新型コロナウイルス感染症対策サイト(フォークして作成した北海道版は私も関わっています)の開発のCode for Japanさんが、接触確認(コンタクト・トレーシング)アプリの開発を続けていた、、、のですが、色々な事情でこちらのアプリはリリースできない事になり、オープンソースとして公開されたものです。

接触確認アプリはシンガポールのTraceTogetherが多分最初だと思います。

現在、GoogleとAppleが、それぞれAndroid、iOS向けにAPIを開発し、それを組み込む方針で開発が進められているようです。

政府のコロナ接触確認アプリ、AppleとGoogleのAPI活用し6月公開目指す
  日本政府は、新型コロナウイルス感染症(COVID-19)の接触確認アプリの仕様書案を5月17日に公開しました。AppleとGoogleが共同開発したAPIを使用し、6月中の公開が目指されています。 Appl

公開されている知見

ソースコードがGitHubに、開発に至るまでの各種ノウハウがnoteにて公開されています。

まもりあいJapan
まもりあいJapan. まもりあいJapan has 5 repositories available. Follow their code on GitHub.
まもりあいnote|Hal Seki|note
「まもりあいJapan」の参加メンバーが、それぞれの専門家としての視点で、活動内容とかける想いをつづっていきます。

そうそうたるメンバーが、各専門領域について深く考え実践したノウハウが惜しみなく公開されています。サービス開発に関わる方々(そうじゃない人もですが)は是非読んでほしいです。

エンジニア目線で

実サービスのコードが公開されている

エンジニア目線で素晴らしいと思ったのが、まず、リリースされる(想定の)サービスがまるごとオープンソースとして公開されている事です。

フレームワークやライブラリをオープンソースとして公開というのはもはや一般的ですが、実際のサービスのコードを直接見られる機会というのは、実は意外と少ないのです。

普通、業務として関わる時にしか触れられない、実サービスのコードが公開されて誰にでも見られるというのは、めちゃめちゃ貴重です。

セキュリティをすごく考慮したアプリ

アプリの特性上、セキュリティについてかなり気にして作成されています。

これは技術だけの問題はありませんが、どうアプローチしてどう解決していくのか、非常に勉強になります。

こちらのnoteがわかりやすいです。

接触確認アプリ「まもりあいJapan」の全体設計について|Takuya Kawatsu|note
はじめまして。河津と申します。 普段はFintech企業のCTOとして金融システムのデザイン(企画/方式設計/技術採択)を生業としております。縁あって「まもりあいJapan」プロジェクトに参画させていただき、こちらでも企画/方式設計を担当しています。 この記事について この記事では接触確認アプリとはどのようなもの

スケーラビリティ(負荷対策)を意識した構成

日本に住むたくさんの人が使う想定のアプリなので、サービスの負荷は半端ないはずです。

サービス特性上、がんがんサーバにアクセスするようなタイプはありませんが、日本に住む人のX割以上が使ってほしい、、、というレベルのものなので、負荷に対する考慮はめちゃめちゃ大変です。

採用したインフラのアーキテクチャとして、

  • AWS Lambda
  • Firebase
    • 認証
    • DB(Firestore)
    • Cloud Storage

となっています。

全てフルマネージドなServerless構成で、初期導入にかかるコストをほとんどかけない & 負荷対策おまかせ、となっています。

さらにこの構成で負荷対策テストまで実施済です。

以上から、インフラの導入と運用にかかる手間コストをできるだけ抑えた構成として、めちゃめちゃ良いのでは、、、と思います。

「まもりあいJapan」 開発試行錯誤の裏話 後編|Daisuke Hirata|note
引き続き、モンスター・ラボ CTO の平田です。接触確認アプリ「まもりあいJapan」プロダクト開発チームで開発をしています。「まもりあいJapan」は5/18にコードを公開しました。開発試行錯誤の裏話 ~前編はこちらです。 BLE の課題をクリアすればオッケーではなかった。個人情報保護、データプライ

Serverless + NestJS + Lambdaという組み合わせが熱い

apiサーバの技術スタックとして、「Serverless + Node.js + TypeScript + NestJS」が採用されています。

これは個人的な興味なのですが、

  • 最近TypeScriptを使っていて、お気に入り
  • TypeScriptのサーバ側のFWとしてNestJSがファーストチョイス
  • AWS LambdaでTypeScript + NestJSを使ってみたいとぼんやり思っていた
    • が、あまり知見が広まっていない

というわけで、私の興味ドンピシャ構成になっています。

これがうまくいくなら、ほとんどのWebサービスのバックエンドはこれで良いんじゃないの、と期待しています。

まとめ

というわけで、「まもりあいJapan」の知見が公開された事の素晴らしさが少しでも伝わりましたでしょうか。

この知見を有効活用するべく、動かしたりコード読んだりしていく予定です。

コメント

タイトルとURLをコピーしました