こんにちは、エンジニアの <a href="https://twitter.com/tikson">@tik-son</a> <a href="https://twitter.com/kargo113">@kargo</a> です。02020/06/09 - 2020/06/11 に行われた <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital">Google Cloud Day: Digital</a> に 弊社2名で「Multi Cloud」「ML」というテーマでそれぞれ登壇してきました。
こちらのブログでもその内容を簡単にまとめておきます。
<h1>「Google Cloud Day: Digital 基調講演」</h1>
カスタマー エンジニア 技術部長の佐藤 聖規さんから、Container Based MultiCloud を実現する手段として、我々がAnthos GKE on AWS を利用し始めたことを
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/d66e5d06-7109-4834-980c-64e922323ff5/----------2020-06-09-11.14.15-2-------1.png" alt="">
また、Developer Advocate の佐藤 一憲さんからは我々のGCP のML 活用のOverview とKARTE の紹介をして頂きました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/b16b0bcb-8ddf-4431-ad58-7ca186d88b42/----------2020-06-09-11.25.17-2------2-1.png" alt="">
そしてKeyNote で取り上げていただいた2つのトピックについて、それぞれ発表してきました。
<h1>「PLAID’s Journey with multi cloud」</h1>
こちらは <a href="https://twitter.com/tikson">@tik-son</a> よりご紹介致しました。1我々が提供するKARTEは2015年にローンチされ、2016年頃からVm Based MultiCloud になり、現在はContainer Based MultiCloud に取り組んでいるのですが、そのローンチから現在に至るまでのアーキテクチャの変遷をご紹介しました。
Container Based MultiCloud を実現する手段として、<a href="https://cloud.google.com/blog/ja/topics/anthos/anthos-for-aws-is-now-ga">2020 /4/23に発表されたAnthos GKE on AWS</a> の利用を開始しており、発表の中でAnthos GKE on AWS を使ってみての話もしております。
発表については <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d1-appdev04">YouTube Live</a> でご覧いただけます。2また、<a href="https://speakerdeck.com/tikson/plaids-journey-with-multi-cloud-10128526-d75f-41de-98ec-27025f8d35a9">SpeakerDeck</a> に資料もアップロードしているので時間が無い方はこちらを流し読みしていただければと思います。
<script async class="speakerdeck-embed" data-id="bdb90a12b7864ba4b5925e5bf7a52d1d" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>「AI Platform で実現する ML Pipeline」</h1>
こちらは <a href="https://twitter.com/kargo113">@kargo</a> よりご紹介致しました。
私たちが実現するコンセプトは、大量のリアルタイムデータからパターンを発見するMLシステムと人にしかできない思考と発想を継続的に統合するEnd-to-EndのML Platformです。
これを実現するにあたり、以下の3つの課題がありました。
<ul>
<li>パイプラインの実行環境の統一</li>
<li>学習環境のスケーラビリティ</li>
<li>継続的インテグレーション</li>
</ul>
この課題をそれぞれ
<ul>
<li>AI Platform Pipeline</li>
<li>AI Platform Training</li>
<li>Github Actions</li>
</ul>
の導入によって解決しました。 
さらに、今後の展望として
<ul>
<li>リアルタイム基盤</li>
<li>カスタマイズ性</li>
<li>強化学習基盤</li>
</ul>
を構築し、ML Platform の拡充を図ってまいります。
全ての詳細は <a href="https://cloudonair.withgoogle.com/events/google-cloud-day-digital/watch?talk=d3-ml05">YouTube Live</a> よりご覧頂けます。3同様にこちらも <a href="https://speakerdeck.com/kargo113/googleclouddaydigital-plaid-mlpipeline-on-aiplatform">SpeakerDeck</a> に資料をアップロードしているのでお急ぎの方はこちらから是非ご覧ください。
<script async class="speakerdeck-embed" data-id="e730d56572474db6832290df749de1be" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>最後に</h1>
今回はcovid-19の影響もあり、オンラインでの登壇となりました。4普段と異なる環境であり、初めは少し戸惑いましたが、ふたをあけてみると、5オフラインでの登壇の時よりも効率的に発表に対する時間を使うことが出来たり、6普段よりも多い800名以上の方にリアルタイムにご覧いただいたり、様々なポジティブな点がありました。
そして、オンライン上の顧客体験を向上させるKARTEを提供する我々としても、この現状を前向きに捉え、さらなる価値を今回登壇の機会を頂いたGoogleさんをはじめとする様々なパートナーの方々と共に提供していきたいと強く感じました。
そんな弊社ではスピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a> または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！

Google Cloud Day: Digital で「KARTEのMultiCloudアーキテクチャの変遷」と「AI Platform で実現する ML Pipeline」について話してきました

Google Cloud Day: Digital で Anthos と ML について話してきました

Webのプライバシー保護について各社が取り組んでいますが、なかでもGoogleが発表しているのがPrivacy Sandboxです。今回は全体像について読み解きます。

Privacy Sandboxはなにを語るのか - 連載 The Privacy Sandbox | PLAID engineer blog

Privacy Sandboxはなにを語るのか

こんにちは、エンジニアの@tanakoです。
PLAIDでは、CX（顧客体験）プラットフォーム<a href="https://karte.io/">KARTE</a>の機能を iOS / Androidのネイティブアプリから活用できる <a href="https://karte.io/product/app/">KARTE for App</a> のSDK（以降 SDK）をAppチームで開発しています。
さて、Appチームは去る4/7にSDKをOSS化し、ソースコードをGithub上で公開しました 🎉
<ul>
<li><a href="https://github.com/plaidev/karte-ios-sdk">iOSリポジトリ</a></li>
<li><a href="https://github.com/plaidev/karte-android-sdk">Androidリポジトリ</a></li>
</ul>
またOSS化に伴い、SDKをv2（以降 v2）にメジャーアップデートしました。今回は、SDKをOSS化して解決したかった課題や、v2メジャーアップデートの概要、チームとしての取り組みをいくつか紹介します。(この記事は社内勉強会で@wasnotが発表した内容を基に、@tanakoが加筆修正したものです。)
<h2>KARTE for App SDKについて</h2>
前提知識となるSDKについて簡単に説明します。SDKは、イベント送信APIやJavaScriptモジュールを読み込むコンポーネントを内包しており、管理画面で記述されたHTML/CSS/JavaScriptをSDKが管理するWebView（iOSではWKWebView）に読み込むことでアプリ内メッセージを表示できます。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24b3914e-72e7-4c6a-a7fe-03abb2acea98/----------0030-12-22-16.27.18-1.png" alt="">
<h2>OSS化の背景</h2>
KARTE SDKは他の一般的な計測SDKと異なり、活用の仕方によっては積極的にアプリのUIに介入できます。また、OSS化以前のv1 SDK（以降v1）はほぼクローズドソースで提供されていたため、自社アプリへの影響を心配する、次のフィードバックがいくつかのクライアントからありました。
<ul>
<li>コードの品質を直接確認できないため導入に不安がある</li>
<li>SDKアップデート時の差分をコードレベルで把握できず影響が読めない</li>
</ul>
これらの不安に対して我々がSDKの品質に問題ないと言ったところで、それを明確に証明する材料はなく説得力も持ちません。
このようなクライアントに安心して利用してもらうためにも、ソースコードの公開が必要と判断しました。
<h2>OSS化によって提供できる価値</h2>
OSS化するにあたり、利用者に提供できる価値を次のように明文化しました。
安心感の向上
<ul>
<li>SDKの品質に問題がないか確認できる安心感</li>
<li>内部挙動を正確に把握できる安心感</li>
</ul>
信頼性の向上
<ul>
<li>第三者が開発に参加することによる信頼性の向上</li>
<li>多数の開発者の目に触れる（問題のあるコードは速やかに報告され修正されやすい）</li>
</ul>
透明性の向上
<ul>
<li>開発プロセスの見える化</li>
<li>コードの変更経緯が追える</li>
</ul>
これらの価値提供でクライアントの不安は払拭できる一方で、単純にOSS化するだけでは、次に挙げる価値を直接提供することはできません。
OSS化だけでは提供できない価値
<ul>
<li>機能性</li>
<li>拡張性</li>
<li>保守性</li>
</ul>
<h2>OSS化にあたり事前に決めたこと</h2>
えいやでソースコードを公開できれば楽ですが、当然OSS化後も開発は続きます。効果的、効率的にOSSを運用するにあたり次の点を決める必要がありました。それぞれどのような観点で決定したかを紹介します。
<ul>
<li>ライセンスの選定</li>
<li>開発・リリースフローの検討</li>
<li>バージョニングポリシーの変更</li>
</ul>
<h3>ライセンスの選定</h3>
OSSとしてソースコードを公開するにあたり、コードのライセンスについて検討・選定しました。MIT、Apache 2.0、BSDや独自ライセンスなどが候補に挙がりましたが、社内有識者やリーガルチームと相談・議論し、条項の読み合わせを行なった上で、 次の理由で<a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 License</a>を採用しました。
<ul>
<li><a href="https://opensource.org/">OSI</a>の承認ライセンス</li>
<li>利用率の高さ（非コピーレフトだとMITの次点）</li>
<li>特許紛争に関する特記事項の存在</li>
</ul>
特に特許紛争に関する特記事項が記載されていることはクライアントに安心して利用して頂く上で重要なポイントです。
ライセンスの検討にあたっては、「<a href="https://www.amazon.co.jp/OSS%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%81%AE%E6%95%99%E7%A7%91%E6%9B%B8-%E4%B8%8A%E7%94%B0-%E7%90%86/dp/4297100355">OSSライセンスの教科書</a>」を参考にしました。「OSSマトリョーシカ問題（OSS内で利用するOSSが競合するライセンスを持っている状態）」という言葉を知り、事前にSDKが依存するOSSについて精査できたのもこの本のおかげです。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3f5ef028-d97b-4d82-ac79-be19ea1ba4cd/----------2020-04-23-20.04.44.png" /><figcaption>上田 理 (2018)．　OSSライセンスの教科書，図9.2 OSSマトリョーシカ（OSSの中にOSSが入っている）</figcaption></figure>
<h3>開発・リリースフローの検討</h3>
開発中の新機能や特定クライアントのissue等の開示は難しいため、当面はそれらの開発プロセスはPrivateにすることにしています。適切に公開範囲をコントロールするため、開発・リリースフローを次のリポジトリ・CI構成で行うことにしました。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/27bdb86e-1762-44f1-8243-e5927af06ea7/----------2020-05-08-18.45.29.png" alt="">
Publicリポジトリではソースコードの公開だけでなく、issueやPRの公開・受付も行います。また、OSS化することを優先したため、当初PRの受付はバグ修正に限定しています。機能追加のPRは受け入れ体制が整い次第少しづつ受け付ける方針としています。体制が整った段階で<a href="https://github.com/plaidev/karte-ios-sdk/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a>を更新する予定です。
<h3>バージョニングポリシーの変更</h3>
v1では次の運用でバージョンアップを行っていましたが、この運用ではIFに破壊的な変更があるかどうか利用者側から影響範囲が分かりません。
<ul>
<li>微修正はpatchバージョン</li>
<li>機能追加などはminorバージョン</li>
<li>iOS/Android SDKのバージョンは揃える</li>
</ul>
OSS化するv2からは、バージョンアップがアプリケーションに与える影響を把握できるように、セマンティック バージョニング 2.0.0（以降 SemVer）に従うことにしました。これにより、バージョンアップが後方互換性を保った変更なのか、破壊的な変更なのか利用者からわかりやすくなります。
また、SemVerでメジャーバージョンの更新条件は自明となりますが、<a href="https://semver.org/lang/ja/#spec-item-7">マイナーレベルのバージョニング</a>の解釈に曖昧な点が残っていました。
<blockquote>
マイナーバージョン Y （x.Y.z | x &gt; 0）は...プライベートコード内での新しい機能の追加や改善を取り込んだ場合は、上げてもよいです（MAY）。その際にパッチレベルの変更も含めてもよいです（MAY）。
</blockquote>
これについては、<a href="https://ja.reactjs.org/docs/faq-versioning.html#minors-versus-patches">Reactのバージョニングポリシー</a>などを参考にチームで議論し次のように決定しています。
緊急性の高い不具合 
即修正してリリースしなければならない問題については、patchバージョンを上げてリリースする。この場合は master ブランチから hotfix ブランチを切ってリリースする流れとなる。
緊急性の低い不具合（考慮漏れ・仕様バグなど） 
minorバージョンを上げてリリースする。2通常のリリースフローでリリースする流れとなる。
バージョニングポリシーを明確化することで、迷いが減り迅速なリリースが期待できます。
<h2>v2 SDK（メジャーアップデート）で実施したこと</h2>
v1 SDKは、モノリシックなモジュールに多くの機能が詰め込まれており技術的負債が溜まっていました。また、利用者にとっての機能拡張性も十分に提供できているとは言えない状態でした。そのため、OSS化を良い機会と捉え、公開インターフェース及び内部実装の再設計を行い、保守性、拡張性などを高め長期的なSDKの品質維持が容易になるようにv1 SDKに対して非互換なアップデート（v2へのメジャーアップデート）を行う判断をしました。
<h3>モジュール化</h3>
v1では複数の機能が一つのモノリシックなモジュール内に詰め込まれていましたが、v2では各機能単位にモジュールを分割しました。
<figure><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f2c4b3d6-3f24-464a-b598-409c1ff5f353/----------2020-04-23-15.14.22.png" /><figcaption>モノリシックなv1、機能毎にモジュール分割したv2</figcaption></figure>
モジュール化には次のメリット・デメリットがあると考えましたが、デメリットを加味しても利用者が要件に応じた必要最低限のモジュールを選択できること、SDKの機能追加や拡張がしやすい状態に保つことは非常に重要だと考えました。
モジュール化のメリット
<ul>
<li>要件に必要な機能だけをリンクして利用可能</li>
<li>可読性の向上</li>
<li>バグやデグレの影響範囲分離・回避</li>
<li>機能追加が容易（サードパーティによるモジュール追加も可能）</li>
</ul>
モジュール化のデメリット
<ul>
<li>一部モジュール間連携用のAPI公開が必要</li>
<li>クライアントがどのモジュールをimportするか判断が必要</li>
<li>全モジュール利用時のバイナリサイズは拡大する傾向</li>
<li>リリース等の作業が煩雑化</li>
</ul>
連携の方法について
モジュール分割により、モジュールが完全に独立して動くようになったわけではありません。各機能のモジュールはCoreモジュールに依存しており、Coreとその他のモジュールを連携させるための作業が必要になります。
この連携作業において、ツールによっては明示的な連携コードの実装が必要です。v2では、より簡単にSDKを導入できるようにモジュールがリンクされていれば自動的に連携するようになります。具体的にはCoreモジュールに各モジュールをlistenerとして登録し、各イベントを受け取る方式となります。尚、モジュールの自動登録には、各プラットフォームごとの機能を使用しています。
iOSでのモジュール連携内部実装
iOSではクラスがランタイムに追加された時に呼ばれるメソッド(<a href="https://developer.apple.com/documentation/objectivec/nsobject/1418815-load">load</a>)があり、各モジュールのクラスがロードされたタイミングで、Coreモジュールにクラスを登録できます。リンクされたクラスは基本的に全てロードされます。
<pre><code class="language-obj-c">@implementation KRTInAppMessagingLoader

+ (void)load
{
 [KRTInAppMessaging _krt_load];
}

@end

</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessagingLoader.m#L24-L31">Objective-CのloadからSwiftのload用関数を呼び出す</a>
<pre><code class="language-Swift">@objc(KRTInAppMessaging)
public class InAppMessaging: NSObject {
 ...
 @objc
 public class func _krt_load() {
 KarteApp.register(library: self)
 }
 ...
 }
</code></pre>
<a href="https://github.com/plaidev/karte-ios-sdk/blob/6bd7e70836b94deb2823d22b7868b917b38d8f1b/KarteInAppMessaging/InAppMessaging.swift#L48-L53">Swift側でのモジュールの登録</a>
Android (JVM)でのモジュール連携内部実装
JVMは基本的に初期状態ではリンクされたクラスはロードされず、呼び出し時に初めてロードされるため、iOSと同じアプローチは使えません（lazy load）。
JVMのClassLoaderにはリンクしたjar内の決められたファイルを参照する仕組みがあり、そちらを利用することで動的にリンクされたモジュールのロード・登録が可能です。
<pre><code class="language-kotlin">val libraries = ServiceLoader.load(Library::class.java)
libraries.forEach { library -&gt;
 register(library)
 library.configure(self)
}
</code></pre>
<a href="https://github.com/plaidev/karte-android-sdk/blob/0e74ddf40b17d253e658ea69b337a5ee1f74f937/core/src/main/java/io/karte/android/KarteApp.kt#L238-L243">ServiceLoaderを使用したモジュールの登録</a>
<h3>開発言語の変更</h3>
iOS / Android共に、メインの実装言語を各プラットフォームのよりモダンな言語に変更しました。iOSは Objective-C から Swiftへ、Androidは JavaからKotlinに変更しています。
言語変更のメリットを次のように考えています。
<ul>
<li>可読性の向上</li>
<li>言語の安全性向上</li>
<li>メンテナンス性の向上</li>
<li>言語背景が（ある程度）似ているため、今までよりもプラットフォーム間の共通点が多い</li>
</ul>
一方デメリットは次の通りです。
<ul>
<li>自由度の低下（安全性とトレードオフ）</li>
<li>バイナリサイズの膨張や呼び出しコスト増大</li>
<li>レガシーな開発環境のアプリでは、余計なものが増えてしまう</li>
</ul>
デメリットはレガシーな開発環境に限定されており、近年では完全にレガシーな環境のアプリは少ないと判断しました。
また、PLAIDではチームやプラットフォームの垣根なくコードを書くことが多いため、言語仕様が（ある程度）近いことによるメリットは大きいと感じています。
<h3>リファレンス自動生成</h3>
v1では、Developer Portal（Karteを利用する開発者向けのドキュメント置き場）のAPIリファレンスを、手動でメンテナンスしていました。
この方式は更新漏れでコードとドキュメントに乖離が生じやすい上に、バージョン毎の対応関係もわからずメンテナンスコストが高い状態でした。
v2からは、ドキュメンテーションコメントをソースコード内に記載し、リファレンスを自動生成することで、コードとドキュメントの乖離が起きにくくしました。iOSは<a href="https://github.com/realm/jazzy">realm/jazzy</a>、Androidは<a href="https://github.com/Kotlin/dokka">Kotlin/dokka</a>でドキュメントを生成しています。
また、バージョン毎にリファレンスが生成されるようになり、対応関係がより明確になりました。リファレンスは<a href="https://github.com/plaidev/karte-sdk-docs">GitHubのリポジトリ</a>にPushして、<a href="https://plaidev.github.io/karte-sdk-docs/ios/latest/KarteCore/">iOS</a> / <a href="https://plaidev.github.io/karte-sdk-docs/android/core/latest/">Android</a>ともにGithub Pagesを利用して公開しています。
v2では、ここで紹介した他にも、<a href="https://developers.karte.io/docs/support-policy-ios-sdk-v2">サポートポリシー</a>の刷新や新機能追加などを多く盛り込みました。興味があるかたは、ぜひ<a href="https://developers.karte.io/docs/release-notes-ios-sdk-v2">リリースノート</a>をご覧ください
<h2>OSS化とv2リリースを同時進行したことによる効果</h2>
v2へのメジャーアップデートとOSS化を同時にリリースしたことで、結果として「OSS化だけでは提供できない価値」である「機能性」「拡張性」「保守性」を付与できました。
これにより「SDK利用者の開発体験」全体を向上させることができインパクトのあるリリースになったのではないかと考えています。
<img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24a49205-2570-45b6-97ae-57a40d569e89/----------2020-04-23-23.38.32.png" alt="">
<h2>おわりに</h2>
簡単にSDKをOSS化した背景、v2アップデートの概要、チームで取り組んだことを紹介しました。
まだまだ、OSS運用のノウハウは溜まっておらず、英語のみでのメンテナンスや、他開発者とのコラボレーション方法の整備に関してもスタート地点であり、その他にも多くの課題が残っています。
引き続き、透明性が高く開発者が安心して使えるSDKを提供するために改善を続けていきたいと思います。

OSSのライセンス、バージョニング、リリースフローの検討と背景、v2メジャーアップデート