2020年の振り返りとグローバルチームのプロジェクトの話

Takuma Morikawa

Published in

Eureka Engineering

28 min readDec 23, 2020

この記事は「eureka Advent Calendar 2020」 23日目の記事です。

22日目はBackendチームの@daisuzuによる「go testを高速化して開発効率の向上に繋げたい」でした。

go testを高速化して開発効率の向上に繋げたい

この記事は「Eureka Advent Calendar 2020」の22日目の記事です。

medium.com

（タイトルの話は中盤以降になるので、無駄テキストに興味がない方はスクロールで飛ばしてください…）

長い挨拶

みなさまいかがお過ごしでしょうか。エウレカの森川と申します。今年もあっという間に終わってしまいましたね。⛄️

エウレカは3月頃から基本的にリモートワークになって、私は12月まで1回も物理出社してませんでした。（* 12月はインフルエンザの予防接種とPCR検査キットの受取のために1回出社）

クーラーが効きづらい家だったのと、更新のタイミングで家賃が約2万円上がるという謎の通知を受け取ったため、良い住環境を求めて引越しをしました。

いつもはオフィス移転のタイミングに合わせて自分もついて行く形で引越しをすることが多い(*)のですが、今回は麻布十番オフィスのまま初めて引越しをした気がします。（* オフィスから3km圏内の場合、単身者3万円、既婚・パートナーシップ登録者5万円の家賃補助が支給されるため）

いつもスプレッドシートでX年間のコスト計算とかして比較しており、今年はコロナ影響で家賃下がってるかなと思って期待してたのですが前回のデータと比較してもあまり変わってませんでした。悲しいです。

今回はこちらのサービスを利用して仲介手数料を抑えることができました。もし引越しの機会があれば一度使ってみてください、おすすめです！

また引越し先はクックパッドマートの冷蔵庫が設置されていて、送料無料で豊富な食材が前日に注文できてQOLが爆上がりしています。生シラスとかまぐろ切り落としとかそのまま食べられるものも少量から注文できるので、Uber Eats派の人も自炊にハマること間違いなしです。（設置場所はここから探すことができます）

とプライベートな話題でジャブをしつつ今回の話題に入ろうかと思うのですが、その前に2020年の振り返りをしてみます。

2020年の振り返り

Pairsでは昨年末から年始にかけて「大切な価値観」という機能が追加されました。プロフィールの上部に表示されるのでどんな人なのか、どんな人を求めているのか少し分かりやすくなったのかと思います。

Pairsアドバイザーというアプリ内チャット画面でアドバイスが受けられる機能に関してはコンテンツの拡充がされています。（A/Bテストを含む機能リリース自体は2019年です。）私も初期実装の担当していたのですがフロントエンド部分とのリクエスト/レスポンス部分はLINEさんのFlex Messageを参考にさせてもらいました。ありがとうございますm(_ _)m

4月には待望のビデオデート機能がリリースされました。リアルで会う前に一度ビデオデートをするという方も多いんじゃないでしょうか。実装もそうですが契約周りで少し時間がかかってたので本来はもう少し早くリリースできたんじゃないかと思います。どうでもいいですがビデオデートってビデオガールみたいで語感が良いですよね。命名は社長の石橋です。

7月にはPC版のUIがリニューアルされてめちゃオシャになりました。それまでは4年間くらいずっとデザインがほぼ変わってなく、AngularJSが使われてたり初回ロードが重かったり時代に取り残されていた感があったのですが、今やレンダリングも早くなってストレスも減ったのではないでしょうか。

9月にはコミュニティにいいね！機能がリリースされ、お相手が自分のどこに興味を持ってくれたのか分かるようになりました。マッチングはもちろん、最初のメッセージでもお話しやすくなったと思います。

10〜11月には本人確認機能が強化されました(eKYC) 。私も自身でやって一度ダメだったのですが、部屋を明るくしたらなんとか審査に通りました…（笑）システム周りについては@emahiroが21日の記事で解説しているので興味のある方は最後まで見て拍手ボタンを10回押しましょう。

Pairs Engageについてはチームが違うのであまり詳しくないのと、2019年のリリースからまだ1年ちょいなので改善点が多くてかいつまんで機能面のアップデートの説明をすることが（私には）できないのですが、なんと11月からTV CMが放映されています。もしかしたら見たことある方もいるんじゃないかと思います。

加えてPairsも今月Web CMを出してます。

もちろんこれらの表面に見える部分以外にも、検索アルゴリズムやセキュリティ周り、細かいUI等の様々な改善を行っています。

また近年のC向けのサービスではTrust and Safetyというお客様の安全を専門に考えるチームを自社に作ってProductチームとLegal/Security/Privacy等のチームとの橋渡しをすることが大きな会社では特に増えてきたんじゃないかと思います。以前のエウレカではMatch Group (MG) のセキュリティチームやプライバシーチームから似たような依頼（エクセルシートに長い質問事項があってそれに回答するとか）が来てたりして、執行役員Information Directorの恩田は若干イライラしてたんじゃないかと思いますが、現在はTrust and Safetyという文脈で似たような話は統合して降りてくるようになったと思いますし、グループサービス間でのすり合わせもしやすくなったんじゃないかと思います。さらに今年は元々Uberで女性やジェンダー関連の暴力に対する安全に取り組んでいたTraceyもMGにJoinしていることもあり、安心・安全を第一に開発や啓蒙が進んで行く流れが加速しそうです。

（開発組織関連は25日に金子が書きたいと思うので書きません。というか1年間1人ぼっちチームでミーティングにほぼ出ていないので何もかも分からないよママン…）

私自身は今年の前半はエラーログの抑制やSAST関連、そしてデータの暗号化を主に行っていました。ナイーブに暗号化すると大量のメール配信が著しく遅くなるし、かといってキャッシュとかしてしまうと暗号化の意味が薄れるので少し大変でした…

とここまでが前置きで、そろそろ本題に入ります。

グローバルチームのプロジェクトの話

今年の後半は主にMatch Groupで使う内部のWebサービスの構築を行っていました。今回はこのプロジェクトで得た知見を共有したいと思います。

エウレカは日台韓の3ヶ国でサービス展開しており、既に各国向けにローカライズされたビジネスロジックやオペレーションを行っているため、グループの他の会社がそれを利用したいという話から今回のプロジェクトは始まっています。

ただしデータ構造や認証、リクエスト・レスポンスはサービスのエンドクライアント向け（Pairs iOSアプリとかの意味です）に最適化されておりそのまま用いるのは難しいため、新しいWebサービスを作ってAPIを提供し、まずグループ内の1サービスが利用するという形になりました。

コミュニケーション編

プロジェクトの話自体は6月くらいに始まって実装開始したのが8月半ば、最終的にリリースをしたのは12月初旬です。

最初はエウレカからは6人、USからも4人くらいでミーティングをしていました。

エウレカ側の内訳は、開発者の私が1人、話を持ってきた人兼社長が1人、遠くからの見守り役兼 CTOが1人、オペレーションチームから2人、USサービスの日本責任者が1人という感じです。USからはPMが2人、バックエンド開発者が2人で、日本時間の朝8時から隔週で打ち合わせをしていました。

Zoomだとやはり英語が聞き取りづらいのもあり、私は出張時や英語のミーティングは大抵iPhoneでOtterを使って記録してます。たまに課金してます。

Zoom外のやりとりは最初はメールベースでしたが、途中でSlackチャンネルを作ってそこでやりとりをするようにしました。

時差があるのと言語の壁があるので、レスが遅くなりがち
CCに入れるタイミング・抜くタイミングが分かりづらい
1つのメールスレッドに話題が混在しやすい ⇒ あとから確認しづらい

という点でSlackの方がやりやすかったです。最後の点はSlackの方がGmailよりも検索しやすく、該当スレッドのリンクを送れば済むので回答側は楽でした。

また職種によっては絶対にメールでやりとりする部署もあるので、そこはメールになってます。（Legal系の場合は証跡という意味合いがあると思われます）ただしフォローとかはSlack DMで来たりするので背景や意図の説明とかはSlack上で行い、決定事項や最終回答がメールになることもあります。

なおSlackはEnterprise Gridで各社ごとにWorkspaceが分かれていますが、DMは自由にできます。

個人的な所管ですが日本に比べてUSは横のチーム間や個人間での情報共有はあまりされないことが多く(*)、似たような質問をされることも多いので、コミュニケーションチャネルは早めに整えて置いた良さそうです。（* もちろん個々人にもよるし、会社によっても程度が違いますが、基本的には個人のタスクを優先して作業しているので共有されないものだと思った方が良い、個人的には感じています。）

早朝Zoomミーティングは欠席か寝坊か、待っていれば出席するのか分かりづらいことが数回ありました。カレンダー上も欠席になってたりなってなかったりするので、そういう場合もSlackで事前に連絡するのが大切だなと思いました。（* 社会人の基礎です）

リリースが近づくにつれステークホルダーが増え、お互いに質問が増えて、誰が知ってて誰が決断して誰が回答するのか不明なこともしばしばありました。特に質問がエウレカ側に対してなのかUS側に対してなのか分からないとき、時差もありUS側ですぐに返信がない場合もあるので、その回答のために調べたり聞いて回ったりするか、一旦無視して実装を進めるかが試されるところでした。

さらにリリース直前の1週間くらいは朝まで起きて向こうのタイムゾーンに合わせる生活をしていましたが、お互いの疑問点がすぐに解決されるので時間がないときはこういうことも必要になるかもしれません。（なので隠れて全社会中も寝てたりました。ベッドでこっそり。😪）

「海外銀行のバックオフィスの人は毎日こんな生活をしてるんだな…」と大変さが少し分かった気がします。

開発コミュニケーション編

開発時に最初から意識してたのは「ドキュメントを作る」でした。日本語で同じオフィスにいてすら認識のズレが発生するのに、英語で時差ありでリモート環境であれば、もう危険な香りがﾌﾟﾝﾌﾟﾝするのは始まる前から分かり切っています🔥🔥🔥

最初はアプリのUIやオペレーションフローを含めた遷移図を現行バージョンと提案バージョンを含めて数種類作りました。こういった図の作成はエウレカではWhimsicalを使うことが多いです。

そして同じくシーケンス図も作りました。mermaidやChart Mageですぐに作れます。

API仕様書はOpenAPI形式のものをStoplight Studioで作り、ReDocでHTMLファイルにしてGCPのCloud Runでホスティングしています。Cloud Runは運用面の手軽さとコスト面での大きなメリットがあります。

Cloud RunへのPublishはGitHub Actionsで行っており、CyberAgent社のわだまるさんの以下の記事を参考にさせていただいてます。

https://blog.wadackel.me/2019/cloud-run-pull-request-preview/

このままだと誰でも見れてしまうので、OAuth2 Proxyを間に入れることで閲覧者を制限することができます。例えばGitHub認証では対象のチームを複数選ぶこともできるので、そこに自社と他社を記述すれば閲覧することができます。（社外秘の場合ならこれでOKですが、関係者外秘の場合は共同チームを作ったり工夫する必要があります）

新規APIや変更点に関しては変更部分をスクショしてSlackでDMして送って確認しています。

そこまで複雑な仕様ではなかったので、API仕様周りで特に大きなトラブルはありませんでした。

ただし英語でドキュメントを書く必要があるので詳細に書かなかったために、違うデータが送られていたフィールドがいくつかありました。例えば creation_date というフィールドに対してコメントで「作成日」とだけ記述していた場合に何の作成日か不明瞭なのでリクエスト送信日が入ってくるようなケースです。（実際には全然違うやつなんですが良い例が思いつきませんでした..）

DynamoDBのデータスキーマについては、最初はGitHub Wikiでマークダウンテーブルで主要なテーブルだけ記載していました。

途中で dbdocs.io を使ってコード管理してみましたが、（パスワードはかけられるが）セキュリティ的に不安だったのと、そもそも誰にもDBスキーマを必要とされたことがなかったので更新が滞ってます。もし今後必要になったらGitHub Wikiで更新を続けるか、または開発者のみの用途ならTerraformコードにコメント入れる形で対応しそうです。

開発編

ここらでそろそろ技術ブログっぽくサービスの技術構成を簡単にご紹介します。

APIアプリケーションはLambda + API Gatewayで作っており、コードはGo言語です。リリースにはServerless Frameworkを利用しています。

WebはNuxt.jsのSPAモードとTailwind CSSを利用し、S3 + CloudFrontで静的コンテンツ配信しています。

インフラ周りはほぼ100% AWSを使っていて、Terraformで管理しています。最初はServerless Frameworkを使っていたのでそこでAWSリソースを作っていましたが、最終的にはAPI GatewayとLambda、そしてCloudWatch EventsとAlarmのみServerless Frameworkで管理して、他はTerraformによる管理になっています。

特に目新しいものはない普通の構成ですが、アプリケーションとインフラで1つずつ何か新しい挑戦をしようと考えて、

アプリケーション側: aws-sdk-go-v2 を試してみる
インフラ側: データ分析基盤にAWS Athenaを使ってみる

ということをしました。

アプリケーション側の aws-sdk-go-v2 関しては、社内ではv1を使っており、「v2が発表されてから2,3年経つしそろそろ試してみても良いかなー」と思って使ってみました。

v1のときと同様に、ちまちまラッパー用のライブラリを書いてました。

構造体のフィールドにポインタ型が多く、レスポンスの構造体の階層が深くて冗長で使いづらい
定型コードを書くことが多くなる

という点と、もし他のプロジェクトで使う際に共通コード化しておいた方が便利だろう、程度の感じです。

v1でラッパーを作ったときの使いづらい点を踏まえて3種類のAPIを提供することにしました。

Wrapper API ⇒ ポインタ型をなるべく減らし、不要な構造体階層を減らしたもの
RawAPI ⇒ そのまま生のaws-sdk-go-v2を使うためのもの（Wrapper APIを作ってないAPI用）
X API ⇒ 自身があった方が便利だと思ったAPI （例: CloudWatch LogsでStartQueryして、GetQueryResultsで実行ステータスが変わるまで待ってから結果を取得する.）

これ自体は良かったんですが、使い始めた際のバージョンはv0.24.0でしたが、9月にリリースされたv0.25.0でかなり破壊的な変更が入ってしまいました。さらに一部機能自体が無くなったもの(*)もあったのでバージョンに追従できてませんでした。

（* 例えばDynamoDBのMarshalerとかPresign URLとか。2,3ヶ月経ってようやく再実装された模様。おそらくSmithyから生成したコードを利用する方式に変えたので、色々と間に合ってなかった）

ここで得た教訓はたとえ2,3年経っていたとしてもAWSの「Developer Preview (aka beta)」はいつまで経っても「ベータ版」ということです。利用して得られるメリットとリスクを考慮した上で選択しましょう…😭

AWS Athenaに関しては、元々エウレカの分析基盤はGoogle Cloud の BigQueryを使っており、コスト以外は満足しかしてなかったので試す余地がありませんでした。ただ年に1回くらいは障害が発生するのと、AWS内のみに閉じることによってコストやセキュリティの面でメリットがあるのは間違いないのでAthena中心の生活を一度は試してみたい存在でした。

結果的には思ったよりも使いやすくテーブル定義変更も楽なので、AWS内にアプリケーションが閉じており、データをS3に保存している場合は特に合理的な選択になるかと思います。

このプロジェクトではAthenaから変えるつもりはありませんが、BQの方がクエリ実行面ではメリットが多いように感じます。

BQの方が結果が早い気がする（* 年々早くなってる）
コンソールでのSQL実行前に課金額がなんとなく分かる
Athenaの (Presto) SQLが書きづらい…

なのでPairs本体で今から変えることはないと思いますが、新規サービスの際は選択肢の1つになりそうです。

AWS編

今回のAWSアカウントは本番やステージング等の環境ごとに作っており、Okta経由でロールを選択してログインする形になっています。この辺りの内容は昨年の恩田による「AWSのマルチアカウント管理におけるIAMマネジメントで試行錯誤した話」が参考になるかと思います

大元のプロバイダーがGSUITEになっている関係で、STSによる一時的なクレデンシャルが発行しづらい状態なので、手動での作業時にはアクセスキーを発行していたりしました。

AWSアカウントを分けていれば構築時に特に注意することはないですが、グローバルで適用されるものには例外があります。例えばS3バケットの命名規則を決めておかなかったりすると後で本番環境構築時に整合性が取れなくなったりします。（結局ステージング環境のS3バケット再作成＆コード修正をしましたが、その環境で脆弱性診断が行われていたのでダウンタイム無しで進めるのに少し気を使いました。。。）

またちょうど同時期にセキュリティチーム側で AWS Organization のサービスコントロールポリシー（SCP）を設定していたらしく、一部のリージョンしか使えない設定になっていました。そこでAWS Chatbot（グローバルリージョン？）を設定しようとしたら自動的になぜか us-east-2 のリージョンが使われており、SCPでエラーになっていてハマりました。気をつけましょう。

あとはAWSのエンタープライズサポートに契約すると、調べてもよく分からなかったことが簡単に解決する可能性があります。弊社では専用のSlackチャンネルでコミュニケーションを取っています。

例えば今回だとGlueの料金について質問したところ、今回の構成ではGlueクローラを使わないでAthenaのPartition Projectionで簡単に構築できると教えてもらい、実際に簡単に構築できすぎてとても助かりました。ありがとうございますm(_ _)m

（めちゃくちゃ高いですが）時間と知識を金で買うと思って、まだ契約してない方は今すぐしましょう！

実装スケジュール編

実際の実装スケジュールは大体↓みたいな感じでした

8月中旬〜: ドキュメント作成
9月〜: APIコード作成
9月中旬〜: ステージング環境の作成・US側へ提供開始
10月〜: Web側作成開始
10月中旬〜:（差し込みでPairsのタスクで健康保険法改正による自動マスキング対応が入る…）
11月: Web側作成再開
11月中旬: 脆弱性診断・本番環境構築
12月1日: リリース予定

反省点はWeb側の提供が遅くなってしまいギリギリBoysになっていたので、オペレーションのマニュアル作成がぎりぎりまで出来なかったらしいことや、Serverless Frameworkでリソースを管理していた時期にCloudFormationのDeletionPolicyをRetainにしておらず、ベータ版ブランチでリリースしたり元に戻したりした際にAWSリソースが消えたりしてデグレってたことや、そもそも実装に時間かかりすぎってのもあります。

時間がかかった主な要因を振り返ってみると

アプリ上で利用されるDynamoDBのクエリイメージの全貌が見えてなかったので設計が進まなかった
ラッパーを書きながらDynamoDBの複雑なクエリをサポートするのが辛かった
ベースのWebデザイン・遷移を考えるのが辛かった（オシャレさはいらないが、UXの最適化が必要）
App/Web/Infra/設計/ドキュメントのコンテキストスイッチ切り替え（特にどれかの作業中にノっている状態で、依頼やスケジュール都合等で他の領域の作業をしないといけない時が辛い）

って感じです。

人を増やせば解消する面もありますが、逆に全て一人で進めてたのでApp/Web/Infra間のコミュニケーションが要らなかったのと、ドキュメント無しでも全体像が見えていたのでやりやすい面もありました。急に仕様変更しても自分が辛いだけで嫌がられたり怒られたりしなかったという点も大きいかもしれません。

セキュリティ編

リリースの10日くらい前からはMGのセキュリティチームに脆弱性診断をしてもらいました。この時はまだ本番環境を用意できてなくて、脆弱性診断のレビュー利用も兼ねてServerlessFrameworkや手動で作ったAWSリソースを、Terraformで管理しようと動き始めました。

最初に野村友規さんの『実践Terraform AWSにおけるシステム設計とベストプラクティス』を買って読んで（とても助かりました）、そこから作業を始めたんですが全然終わらなくて3日くらいかかりました。今見たら11月24日に買ってるので本当にギリギリの戦いでした。

リリース日を優先するために手動で本番環境を作ることも視野にいれていましたが、ステージングと本番で差分なく構築でき、レビューでも役に立ったので結果的にはこの試みは良かったと思います。

脆弱性診断で指摘された事項は個人的に勉強になったので、以下で一部共有いたします。（もちろん解消済みの項目です）

API側

Terraformの実行ユーザーの権限が強すぎる

マルチアカウントでの共通化をしており個別にAllowポリシーを作ることが難しかったので、KMSや特定リソースへのDenyポリシーを設定することで対応しました

カスタマー管理のCMKのキーポリシーにデフォルトの権限が残ってるので制限を加える

// 修正前
{
    "Sid": "Enable IAM User Permissions",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::000000000000:root"
    },
    "Action": "kms:*",
    "Resource": "*"
},// 修正後
{
    "Sid": "Enable IAM User Permissions",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::000000000000:root"
    },
    "Action": "kms:*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:principaltype": "Account"
        }
    }
},

KMSのキーローテーションを設定する
S3のバケットポリシーでSSE-KMSの強制をする

以下の記事の設定をする必要があります。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/s3-bucket-store-kms-encrypted-objects/

アプリケーション側からもPutObject時にキーを指定しています。未指定でも自動的にS3の設定が適用されますが、ミスを減らすための設定になると思います。

IPアドレス制限

APIは API Gatewayのリソースポリシーで設定可能です。WebはAWS WAFを利用する必要があります。

（CloudWatch Logsのログ保存期間が短すぎる）

Firehose → (Lambda) → S3 という形でS3に保存していたので、短くても無問題でした。

（Lambdaのコード署名の利用を検討する）
オペレーションの操作ログを詳細に記録されていない（誰が、いつ、どこで、どこから、どのリソースに対して）

アプリケーションコード内のロギング処理を呼び出す箇所によっては入っていないデータがあったので、どこからでも詳細なログになるようにログ機構を作り替えました（contextにログ用のデータを持たせた）

Web側

httpでアクセス可能

CloudFrontのViewer Protocol Policyの設定漏れでした（Redirect HTTP to HTTPS）

ログアウトしてもCookieに機密情報が残っている

vuex-persistedstateで全て保存されていたので、ログアウト時に明示的にremoveするようにしました

ref: https://github.com/vuejs/vuex/issues/1118

robots.txtがない

static/ へ手動で追加しました

セキュリティ関連のヘッダー追加

Lambda@Edgeを使う必要があります

ref: https://aws.amazon.com/jp/blogs/networking-and-content-delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/

なお、診断はAppSec担当が3~4名、AWS担当が1名だったのですが、Slack DMで同じような質問がきたり、別々に指摘された点の優先順位が分からなかったりで、個人的にはかなり大変でした。（なので無駄だと思いながらももう一つSlackのメッセージグループを作った）

そして terraform import と rm stateの土木作業はもうやりたくありません。

ローンチ・運用編

リリースは12月1日と言いながら、日本時間で2日だったのですが、US側の調整でさらに1日伸びてくれました。

「だったら私も調整したいからあと1週間伸びてくれないかな…！」と密かに祈ってたのですが1日後にはしっかりローンチされてしまいました。

1日辺り最大で数十万程度のリクエストを想定していて、そこまで大きくないサービスなのですが、A/Bテストのように最初は10%くらいのボリュームしか流さない想定でした。しかし設定トラブルで1日数十件しかリクエストが来ないという謎の事態が発生し、実際に10%くらい来たのはさらに2日後でした。

むしろ個人的にはこの間にいい感じにログ周りや監視周りを調整できて良かったです。

（本来は事前に完全な統合テストをしたかったんですが、なぜか先方があまり乗り気じゃなくてできなかった）

運用チームは特にいないので、サーバーレス構成を取った恩恵をここでようやく享受できています。

監視は主にLambda部分のみに絞っており、CloudWatch AlarmによるLambdaの実行関連と、CloudWatch Logsを監視してログレベルがエラーのものをSlackへ通知しています。Alarmはserverless-plugin-aws-alertsを用いて、以下の監視をしています。

エラー
スロットル
実行時間（デフォルト2秒以上）
実行数（20分間ずっと0件 or 1分間に大量の実行）

実行数に関してはAPIごとに傾向が異なるのと、固定のしきい値を設けるとサービス拡大に応じて定期的に変更しないといけないため、最初は「異常検出」が良さそうだと思って試してみました。

しかし、ローンチ時はトラフィックボリュームを制限しており数日ごとに増加していって傾向が変わることと、そもそものデータが貯まっていないから機械学習の恩恵を得ることもなくずっと鳴り続ける壊れかけのレディオ状態だったので一旦諦めました。

今はトラフィックボリュームも100%である程度の期間のデータも貯まっているので、暇なとき(*)にもう一度試してみたいと思います。（* 一生来ないやつ）

AWSの運用コストは今のところ1日1桁ドルです。

そこにはDatadogによる自動的なCloudWatch監視やほとんど見てないX-Rayのコストも含まれているので、あと1,2ドルくらいは削れそうですが、会社全体からしたら誤差の範囲なので一旦このままにすると思います。

データ分析は当初QuickSightを使ってみようと思いましたが、GUIでの操作に全く慣れてないのと、AthenaからSQLで取得したカスタムデータをデータソースに使っていじってたら、ListBucketの課金が跳ねててびびったので断念しました。

跳ねたといっても10ドル程度なんですが、データソース指定してグラフを2,3個作っただけだったので、どの操作でデータがロードされてるかよく分からず、ローンチ1週間程度のデータが少ない状態だったので、「1ヶ月後には一体どうなってしまうんだ…」と思ってやめてます。

今はRedashを使うようにして大好きなSQLが使えるようになってHappyです。

（RedashでAthenaを使う際には Use Glue Data Catalog にチェックを入れないとテーブル一覧に表示されないのと、バージョンにもよるかもですがモジュールインストール＆再起動が必要だったりするようです）

次回の予定

昨年のアドベントカレンダーはSlack Botについて書きましたが、Gistで作ったコードスニペット貼るのが結構大変だったため、今年は「なるべくMediumでコードを書かないようにする」という内容になってます。

ただ以下の4つの項目は別途、他の媒体で（=コード付きで）年明けにも記事を書きたいと思ってるので、書き終えたらリンクを張るようにします。

Serverless Framework
Lambda用のGoコード
GitHub Actions周り
今回のTerraformサンプル

おわりに

リリースから3週間以上経ちましたが、今のところは安定稼働していてホっとしています。今回のローンチを終えたらM1チップのMacをCTOの金子に買ってもらえると信じてここまで頑張ってきました。

ただ、一度ズレた体内時計を戻すのは難しいです。本当は戻りかけたのですが、この記事を書くために今も当日の朝になりかけてるのでまたズレる可能性が高そうです。そんな忙しい時でもクックパッドマートがあれば美味しく健康な食が保証されるので本当におすすめです。今も糖度12以上のみかんを食べながら書いてます。

ちなみに私はまだ「話を持ってきた人兼社長」の石橋から「リリースお疲れさまでした」とか「オーパスワン飲みますか？」とか「M1のMac買ってあげるよ」とか何も言われていません。一言もありません。おそらく何もないまま2020年が終わると思いますし、このブログに対して拍手ボタンも押してくれないと思います。こんなことがあるのであろうか。（いや、ない）

代わりにみなさま、拍手のほどよろしくお願いいたします。

明日の24日（クリスマスイブ）はMISチームの池嵜による「入社オンボーディングのBOT化について」の予定です。お楽しみに。