Github Copilotを全エンジニアに導入しました
こんにちは。CTOの大久保です。
このたびMGReでは、Github Copilotを全エンジニアに導入しました。 導入してまだ1ヶ月も経っていませんが、今後に向けてとても期待がもてる声もあがっていますので、お伝えしたいと思います。
GitHub Copilotとは
GitHub CopilotとはGitHub社が提供するツールで、AIがコードやコメントの提案や補完をしてくれるツールであり、 エンジニアはコードを書き始めるか、何をするコードなのかのコメントを書くことで、Github CopilotのAIによるサポートを受けることができます。
Github社が謳う通り、AIがペアプロの相手をしてくれるようなツールです。
導入した理由は
生産性の向上も期待していますが、やはり、一番の目的としては生成系AIの体験を毎日のプログラミングの際にもっとも身近に感じてもらいたかったからです。 ChatGPTを始めとしたAIの革新や続々とサービスへの適用がすすむ中で、エンジニア自らがAIの恩恵を日々体感していることは、後々経験として活きてくると思っています。
導入してみての効果
まだ導入して日が浅いため、数値として開発生産性の向上のようなものは計測できておりませんが、明らかに開発者体験のアップデートが進んでいます。
利用者のリアルな感想をいくつか共有します。
- 「もうプログラミングの際にGithub Copilotなしでは生きていけない身体となってしまいました。いままでどうやってコードを書いていたか思い出せません。」
- 「コードをちょっと書き始めたあとに、書きたかった処理そのものズバリを提示されることがあり、便利やすごいを通り越して、ちょっと怖いとさえ思いました。」
- 「今までよりも気軽にコメントを書けるようになりましたし、コメントを書く時間も短くなったと思います。」
Github CopilotがMGRe社内のリポジトリを学習しつづけているため、MGReにおけるコーディングのお作法というかクセのようなものまで勘案して提示されていると思われるため、 開発時の思考を妨げず、違和感なくプログラミングやコメントを記述するサポートを受け入れることができていると思います。
これからもUPDATEしつづけます
さらにGithub Copilotの進化や利用が進み、あたりまえに使いこなすことができるようになったときに、いまはない新しい開発者体験も得られることも期待しています。
エンジニアが日々AIを活用し体感していることは、MGReのバリューとして大切にしている「UPDATE」をエンジニア全員で自ら体現し続けていくことの一助になると思っています。
アップロードキーに苦戦した話
こんにちは、メグリ株式会社でAndroidエンジニアをしている増田です。
以前（10/13）、 STORES 株式会社さんとLTイベントを実施した際の内容をまとめてみました。
題目
アップロードキーに苦戦した話
話したこと
アップロードキーがなんらかの理由により紛失した実体験に基づいて（正確には前ベンダーがキーストアを引き渡してくれないという事件が発生発生していました）、
そんな場合でも対処できる方法があることと、実際の手順について発表させていただきました。
Androidのアプリ署名について
Androidのアプリ署名について軽くおさらいです。
アプリへの署名はPlayストアにアプリを公開する際に必須となっていますが、2020年の8月より、セキュリティの向上を目的とした「Google Play App Signing」という新しい署名方式（以降新方式と記載）が登場しました。
変更点としては、ベンダーが管理する鍵の種類が「アプリ署名キー」ではなく、「アップロードキー」に置き換わっており、アプリ署名キーはGoogleが管理してくれるようになりました。 （ここが重要！）
これにより、アプリの署名方式が新旧の2通りのどちらかを利用できるようになりました。
（ただし、現時点で新規アプリを公開するとした場合は必須となる）
以前新方式での対応が必須となるみたいな記事を見かけた気がしたのですが、今どの方式でもバイナリをアップロードできているので見間違いですかね・・🤔
新旧それぞれの概要については以下図のようになっていて、 最大の違いとしては旧方式ではアプリ署名キーを紛失してしまうと パッケージ名を変更して新規アプリとして公開せざるを得ない状況となるのに対し、新方式ではアップロードキーが再登録して、引き続きアプリの公開が可能となる点です。
アップロードキーの再登録フローについて
再登録には新方式でないと対応できないため、先ほど紹介した新方式のオプトインが必須となりますので、ご注意ください。
（元々新方式ではなかったため、そこだけはなんとか対応してもらいました。旧→新への移行については後ほどほんの少しだけ触れます）
実際にアップロードキーを再登録するためには3つの作業が必要になりますので、それぞれについて軽く触れていこうと思います。
キーストアの作成
まずkeytoolを利用してキーストアを作成します。
作成したキーストアからPEMファイルを作成
上記で作成したキーストアから、先ほどと同じくkeytoolを利用して作成します。
Googleのサポート宛に申請
Play Consoleにログインし、該当アプリのリンクより申請します。
申請に向けて必要情報をフォームに入力していきます。
フォームの下部に、先ほど作成したPEMファイルを添付する箇所があるので添付します。
ここまで出来たら、その下にある申請ボタンをクリックすると申請は完了です。
申請後の流れ
申請後、サポートから返答がメールで届きます。 おおよそ返信が来るまでの時間と、実際に申請したキーストアが利用可能になるまで約1.5日ほどかかるので、少しラグがあります。 急を要する場合は注意が必要です。
また、平日で繁忙期や大型休暇シーズン（年末年始など）ではない時期に申請していたので、もし繁忙期に申請する場合はより時間がかかるかもしれませんので、そこにも注意です。
旧→新への移行
旧→新に移行するにはいくつか方法がありますので、詳しくはこちらをご覧ください。
（弊社では普段はAndroid Studio からエクスポートした鍵をアップロードする方式を利用しています）
https://developer.android.com/studio/publish/app-signing?hl=ja#enroll_existing
まとめ
結論としては、早めにGoogle Play App Signingにオプトインしておくことをおすすめします！
理由としてはアップロードキーの紛失に対応できることと、アプリ署名キーをGoogleが管理してくれるのでセキュリティ的に旧方式よりもセキュリティ面に優れている点、
加えてアプリをインストールする際に端末に適したリソースのみを取得するため、ファイルサイズを小さくできるからです。
ご覧いただき、ありがとうございました🙇♂️
ここがつらいよマルチテナント
こんにちは、メグリでサーバーサイドエンジニアをしている蔵下です。
少し前ですが、10/13にヘイ株式会社（現 STORES 株式会社）さんと LT 会のイベントを行いました。今回はそこで発表した内容に少し追記しつつ改めてまとめてみようと思います。
https://mgre.connpass.com/event/260781/
LT 内容
タイトル
ここがつらいよマルチテナント
本日のお題
マルチテナント向けSaaS開発時の経緯とマルチテナントのつらみについて
弊社では2020年6月に EAP という前身サービスから MGRe にリブランディングを行いました。その際にクライアントごとに個別に環境を用意するシングルテナント方式から、一つの環境に複数クライアントが同居するマルチテナント方式に転換しました。今回はマルチテナントを数年開発・運用してわかったつらみについてお話します。
MGRe について
- マルチテナント向けのSaaS
- ニュース、お知らせ、クーポン、店舗検索、プッシュ通知、アイテム等 + 会員証の基本機能
- 様々なECや会員基盤システムと連携が可能
MGRe の歴史
過去のサービスとの比較
マルチテナントにしてつらかった点
- パフォーマンスの課題
- DB（Aurora Serverless）の性能限界が見えてる
- WAF 等 AWS のリソース上限
- 運用の課題
- テナント領域のアップデートが手間
- テナントが混ざる
- 一番の課題
- やらかすと被害が大きい
パフォーマンスの課題
- DB（Aurora Serverless）の限界
- コンテナ（API）はいくらでも増やせる
- プッシュ配信時のスパイクアクセス
- MGRe のセグメント配信は仕様上キャッシュが難しい
- 通勤時（9時台）やスーパー等の小売はお昼過ぎ（12〜13時台）と夕方（17時以降）
- WAF 等 AWS のリソース上限
運用面の課題
- テナント領域のアップデートが手間
- テナント毎に異なる認証処理を吸収
- mgre-auth という gem を用意
- ある程度共通化はされているものの数が多い
- テナントが混ざる
一番の課題
- やらかすと被害が大きい
対策
パフォーマンスの対策
- 古いデータの削除、非公開化
- インデックスの見直しも含め、取得レコード数を減らすのが最も効果的
- Aurora Serverless v2 への移行
運用面の課題
- テナント領域のアップデートの自動化
- PR 後各テナントのリポジトリにおいてコミット→ PR までの自動化、スタンダードプランにおいてはマージ〜自動デプロイまでの仕組みづくり
一番の課題
- QA（テスト）含むリリース体制の整備
- 項目書を作り計画立てたテストに
- 手軽に行える負荷テスト
- MAU が大きいテナントの分離
- 別の DB インスタンスを用意する
マルチテナントにして良かった点
- アップデートの適用が楽
- 厳密には楽ではないが一度のアップデートですべてのテナントに適用できる
- シングルテナントより開発した機能やバグ修正の適用速度が早い
- SaaS としてプロダクトを成長させるにはマルチテナントという選択は最適だった
まとめ
- Aurora Serverless v2 はいいぞ
- QA さんありがとう
DroidKaigi2022に参加しました！
こんにちは、メグリ株式会社でAndroidエンジニアをしている増田です。
10/5から3日間（最終日のみハンズオンで別会場）にわたって東京ドーム付近のプリズムホームで開催されたのですが、久々のオフラインイベントということもあり、かなり多くの方が見えていました。
Day3に関しては諸事情で参加できずDay1~2のみの参加でしたが、どんな様子だったのか、簡単ではありますがお伝えしていければなと思います！
会場の様子
入場すると、ネームプレートやたくさんのノベルティをいただき、写真にはないですがその他数多くのノベルティもありました👁️
セッションの様子
続いて、印象的だったセッションについての簡単な総括です。
印象的だったセッション
1つ目
1つ目は株式会社Mobility Technologies 駒井覚さんの「アプリエンジニアとQAチームがデバッグ機能の改善に取り組むぞ！」のセッションです。
弊社の現状と、以前のMoTさんの状況がリンクしている部分（機能が増えるにつれリグレッションテストの項目数が肥大化してしまう問題に対応できていなかったetc..）があり、
かつデバッグ機能は前々から話が挙がっていたものの、なかなか着手できない状況が続いてしまっている中で、実際にどう向き合って解決したのかの過程を知ることが出来て、とても為になるセッションでした。
また、上がってきた要望はペイオフマトリクスを用いて影響度や実装難易度を数値化した上で優先度づけをおこなっていて、優先度付の検討においてかなり有効だと学ばせていただきました。
地道でも良いので、デバッグ機能の実現に向けてインタビューなど、やるべきことを着実にやっていかないとなと改めて実感しました。
2つ目
2つ目は株式会社メルペイでエンジニアリングマネージャーを担当されているmicchieさんによる「あらゆる変化を受け入れながら働きつづける 〜 介護・学業編」です。
このセッションはAndroidについてではなく、実生活に紐づく仕事とプライベート（介護・学業）との向き合い方についての話でしたが、今まで考えることもなかったことを考えるきっかけとなるとてもいいセッションでした。
登壇されていたmicchieさん自身のエピソードや、ご経験から来る知見を交えながら今回多くの方が直面するであろう「介護」についてのお話が特に印象に残っています。
正直馴染みのない話と思っていたのですが、聴いていくうちに介護はこの先必ず考えなくてはいけない命題で、今突然訪れるかもしれないと認識を改めましたし、今から考えるのでも遅くはないはずなので、まずは両親がどう考えているのかを知るために対話をしてみようと思います。
Androidとは関連ありませんが、こういった内容のセッションを聴く事ができるのもDroidKaigiの魅力ですね。
3つ目
最後はオイシックス・ラ・大地株式会社のtk-masudaさんによる「移りゆくデファクトスタンダードにチームとしてどう追従するか」です。
このセッションは確かに・・という共感の連発だったような気がしたのですが、特にデファクトスタンダードの定義の中の
「既存の課題の解決に役立つものであり好奇心からくるものではない。取り入れるべきかどうかは極論個人の主観（or チーム内の個々人の主観的な合意ありき）での判断となる」
という言葉が特に印象的でした。
Android界隈でもあらゆるデファクトスタンダードがあり、弊社でもある分野でデファクトスタンダードに追従した方がいいのでは？という共通認識こそあって話が上がったりすることは多々ありますが、
追従する or しないことによって生じるメリット・デメリットを言語化できていないことにも気がつけてとても大きな収穫になりました。
コスト面の問題や時間的な制約もあるかもしれませんが、「デファクトスタンダード」に追従すべきとチーム内で合意が取れた場合は、先の1つ目に挙げたデバッグ機能の作成の段階で試してみるのが良さそうと感じました。
まとめ
いつもとは異なる環境が良い影響を与える？のか、オフラインで様々な方と対面でコミュニケーションを取ったり、外で作業したりするのは良いものだなと実感できましたし、普段聴けない話も聴くことで新たな視点を学ぶ良いきっかけとなりました。
これを契機として、チーム内では月1集まってオフラインで作業しようという話も上がったりしています。
また今回、いろいろな障壁がある中でカンファレンスを開催・運営してくださったスタッフやスピーカーの方々をはじめ関係者の皆様のおかげで、とても有意義な時間を過ごすことができました。
また来年も開催されましたら、是非参加させていただきたいなと思っています。
ありがとうございました🙇♂️
AdHocでUDID自動登録とアプリ再配布を自動化したい
こんにちは、iOSアプリエンジニアの二木です。 今回はAdHoc配布でUDID自動登録とアプリ再配布を自動化した話を書きたいと思います。
AdHoc配布はインストールしたい新しい端末が出てきた場合、その端末のUDIDを特定してからデバイス登録してアプリを再配布する手間がありますが、これまでその作業を手作業で行っていました。（アプリのビルドについてはBitriseで自動化できている。）
メグリ株式会社では、エンジニアにはできるだけ思考するところに注力してもらいたいと思っているので、決まった作業はできるだけ自動化するように進めています。今回はその一環でAdHocアプリのUDID登録と再ビルドしたアプリを配布する処理を自動化した話を紹介したいと思います。
新しい端末登録がインストールできるまでの作業
まず、新しい端末がAdHocアプリをインストールできるようになるまで、どのような作業が必要なのかを整理します。 ざっと以下の作業が必要になります。
1. 新しい端末のUDIDを特定 2. AppleのDeveloperサイトからUDIDを登録 3. 登録した端末にチェックを付け、profileを更新 4. 新しいprofileでアプリを再ビルド 5. 再ビルドしたアプリをDeployGateに再アップロード
上記の作業を自動化するわけなのですが、どうすれば実現できるかをいろいろと模索してみました。
UDID自動登録とアプリ再配布の仕組み
模索した結果、以下の構成で自動化を進めることにしました。
この構成について内容を説明します。
- 1でUDID未登録端末が配布ページにアクセスすると、DeployGateの機能でメールで通知を受け取ることができます。
- 2のメール通知をトリガーとして利用し、Zapierで処理を動かします。
- Zapierではまず初めに、3でメール通知の内容からUDID、グループ名、アプリ名、bundle idを抽出します。
- 4でDeployGateのWebページをスクレイピングして、UDIDをキーにその端末モデル名やOSを取得します。
- 5では、Slackで以下のようなフォームを送ります。（フォームはSlack Blok Kit Builderで作成できます。）
- ※slackでフォームを送らず、そのままUDID登録へ進む選択肢もありましたが、端末登録は100台までと限られているため、敢えて一旦slackで通知して確認作業を入れるフローにしています。
- 上記のslack通知で「端末を登録してビルド」ボタンを押すと6でBitriseをキックしてUDID登録と新しいProvisioningProfileでの再ビルドが行われます。（8と9の部分）
- 再ビルドされたアプリはBitriseからDeployGateに再アップロードされ、未登録端末もインストールできるようになります。
自動化してみて思ったこと
まずは、エンジニアの負担がかなり軽減されたと思います。 slackで通知されるように作ったので、未登録端末がアクセスしたことがわかりやすくなりましたし、手動で行っていた端末登録と再ビルドの作業がボタンひとつでできるようになったことは大きいです。
また、自動化の作業では今回初めてZapierを本格的に使ってみました。1つ1つのステップをテストしながら進められ、作成したステップの成功を確認してから次へ進めるので自動化の処理を作りやすかったです。Zapierは連携しているサービスも多く、他にも使い道がありそうで楽しみです。
メグリのアプリチームでは定期的にメンバーと集まって自動化などの業務改善に取り組んでおり、社内でノウハウを共有して今後も自動化できるものを増やしていく予定です！！
