Engineer Blog

Anri Nakamura

Kakemu Fujii

Kento Kaseda

Reo Hakuta

Erika Sakurai

erikasakurai

Takaharu Nakamura

Daichi Hachisuka

Louis Avondet

Sota Sato

Taira Ouchi

Yuta Azumi

Takahiro Hayashi

Kairi Ueno

Hiroki Tamiya

Yugo Tsuchiya

TomokiIchikawa

Yoshito Ikeda

Haruki Tazoe

Hajime Shiozawa

Kazuki Katsurada

masashi kobayashi

lapla

Takehiko Okayama

Kotaro Ito

Yuhei Yasuda

naoyashiga

Takumi Ishii

Sojiro Nishimura

Katsumi Kobayashi

Kota Momoki

Calloc

Shohei Shiraki

Takaaki Kanetsuki

Yui Taniyama

Kota Yatagai

Shuhei Kondo

kenshin tanaka

KARTE Team

Security Team

Tomoya Koike

Haruki Tosa

Daiki Sakuma

Takuma Shibuya

plaidinc

Takami Yamada

Blocks Team

Takanori Koga

Takumi Katayama

Yu Nishimura

Takuya Ogawa

akira.kasuga

Kosuke Oya

Yoshiyuki Komazaki

mizchi

Ryosuke Suzuki

koichi tanaka

Arnaud Avondet

kazupon

daigo.isamatsu

Jun Kusahana

Shinnosuke Ozawa

Rei Ishikawa

Hiroto Harada

Kei Tamiya

Nobuhiro Ito

kazushi oohira

Yohei Meguro

Kazuto Kojima

Tomoki Koga

Kenichi Suzuki

Takaaki Nakama

Takahiro Tokunaga

Kohei Kadowaki

kantetsu

Makoto Kataigi

Tatsuya Monoi

Jumpei Ikegami

Masahiro Yamauchi

Shinji Eto

Yuta Nishimura

Hideyuki Okada

Wataru Ikarashi

Naoto Kato

Yuki Makino

Atsushi Fujikawa

Naohiko Takemura

Daikichi Sasamori

Atsushi Kobayashi

Naoki Shibayama

Daiki Matsui

Yohei Noda

3ヶ月の開発インターンで取り組んだタスクや、そこから得た学びについて紹介します。

プレイドインターン体験記：管理画面から配信基盤までを横断した機能開発

<p>こんにちは、 プレイドでソフトウェア開発者をしているtakurintonです。</p>
<p>プレイドは、2025年10月25日(土)に開催された<a href="https://vuefes.jp/2025/">Vue Fes Japan 2025</a>にゴールドスポンサー、学生支援スポンサーとして協賛しました。</p>
<p>当日はブースの出展に加え、プレイドのユニークな技術とインターンの紹介をさせていただきました。</p>
<h2>ブースの紹介</h2>
<p>プレイドは大規模データを扱う会社である一方で、配信を誰でも簡単に行うことができるUIにも力を入れています。</p>
<p>ブースではフロントエンドの以下のトピックに関するアンケートを実施しました。</p>
<ul>
<li>型、どうしてる？</li>
<li>CSSは何派？</li>
<li>1番重要視するのは？</li>
<li>UI状態管理は？</li>
<li>ビルド&amp;Dev環境を教えて！</li>
<li>推しパッケージマネージャーは？</li>
</ul>
<p>プロダクトの歴史的背景や、場合によっては意思決定者の好みが出る話題で、さまざまなバックグラウンドの方の話や事情を聞くことができ、大変学びになりました。</p>
<p>また、併せて今回のVue Fes Japan 2025に向けて作成した冊子や、プレイドのリアルタイム解析基盤や内製OLAP DBについて技術評論社様と作成した冊子などを配布しました。</p>
<p><img src="https://ik.imagekit.io/plaid/e93f049b-91b9-4a6b-9360-97552fc1f36c/IMG_2541.jpg" alt="Vue Fes Japan 2025の株式会社プレイドのブースの様子。パンフレットやモニター、アンケートボードが並べられている。"></p>
<h2>セッションの感想</h2>
<p>同じ学生支援スポンサーで登壇されていたお二方のセッションの感想を書いていきたいと思います。</p>
<p>お二方とも大変ユニークで面白く、それぞれの抱えている課題について端的に発表されていることが印象的でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/lycorp"><strong>LINE公式アカウントの技術スタックと開発の裏側</strong></a></h3>
<p>LINEヤフー株式会社の佐野友亮さんの発表です。</p>
<p>LINE公式アカウントのプラットフォームを題材に、デザインシステムの取り組みについてお話しされていました。<br>
デザインシステムの中核部分はWeb Componentsで実装されており、それをReactやVue.jsなど複数のライブラリへ適用できる仕組みになっているとのことでした。具体的には、CEMというツールを用いて中間表現を生成し、ReactやVue.js向けのコンポーネントはその生成物を配布する形を取ることで、メンテナンス対象をWeb Components部分に集約している構成が紹介されていました。</p>
<p>Web Componentsを本番環境で活用している事例は個人的に初めてで、以前から関心を持っていたテーマだったこともあり、とても学びの多い内容でした。</p>
<h3><a href="https://vuefes.jp/2025/sponsors/studio"><strong>Vue.jsを8年間使ってきた会社が今考えていること</strong></a></h3>
<p>Studio株式会社の齊藤広野さんの発表です。</p>
<p>Vue.jsを1系の頃から8年間にわたって活用されており、その間にコード量は7年間で13倍に増加していたそうです。発表では、大規模アプリケーションにおけるStore設計の重要性を、単一責任の原則や依存性逆転の原則を題材に、具体的なサンプルコードを交えて丁寧に解説されていました。</p>
<p>また、プロジェクトのデータ構造がボトルネックとなり、パフォーマンスが大きく低下していたアプリケーションをマイグレーションする難しさや、その過程で発生した不具合から得た知見をもとに改善へとつなげていく姿勢が印象的でした。実践的かつ学びの多い内容だったと思います。</p>
<h2>スポンサーセッション</h2>
<p><a href="https://vuefes.jp/2025/sponsors/plaid">プレイドのユニークな技術とインターンのリアル</a></p>
<p>弊社のスポンサーセッションでは、プレイドが提供するKARTEの紹介をはじめ、開発文化やユニークな技術についての紹介を行いました。また、途中では<a href="https://blocks.karte.io/">KARTE Blocks</a>のデモを挟みながら、実際の画面や配信についても触れました。</p>
<p>フロントエンドという領域から離れてしまいましたが、リアルタイム解析基盤や内製しているOLAP DBについての紹介も行いました。</p>
<p>セッション後にブースに立ち寄ってくださった方々からは技術面の面白さを感想としてお伝えいただいたり、時には議論に発展したりと、大変学びになる時間になりました。</p>
<p>よろしければ登壇資料もご覧ください。</p>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="プレイドのユニークな技術とインターンのリアル" src="https://speakerdeck.com/player/0ee327d57ec64e71b058a9a777c71d51" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<h2>おわりに</h2>
<p>Vue Fes Japan 2025では主にフロントエンドの分野に深い知見をお持ちの方が多く参加されており、自分自身その領域への知見や経験が足りないと感じていたのでさまざまなお話を聞くことができ大変有意義な時間になりました。</p>
<p>最後になりますが、素晴らしいカンファレンスを主催・運営してくださった皆様、本当にありがとうございました！また、ブースの出展に携わった皆様、登壇者・参加者の皆様も本当にお疲れ様でした！</p>
<p>来年のVue Fes Japanも楽しみです。</p>


プレイドはVue Fes Japan 2025にゴールドスポンサー、学生支援スポンサーとして参加しました。セッションの感想やブースの運営についてレポートとして紹介します。

Vue Fes Japan 2025レポート | 現地で感じた技術の熱とつながり

<p>こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。</p>
<p>振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。</p>
<p>この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。</p>
<h2>導入</h2>
<h3>インターン参加の経緯</h3>
<p>最初のきっかけは、プレイドで働く友人から、仕事がとても充実していると聞いたことでした。<br>
面談や面接でお話を伺う中で、カルチャーなどに加えて、技術的に難易度の高い大規模データを扱う挑戦に魅力を感じました。<br>
「自分もこの環境に飛び込み、挑戦したい」と強く感じ、このインターンシップに参加しました。</p>
<h3>Journeyとは？</h3>
<p>プレイドが提供するプロダクト「KARTE」において、ユーザーの辿る行動に応じて、異なる施策を実行することができる機能です。例えば、ECサイトで「カートに商品を入れたまま迷っているユーザーに、2時間後にクーポンの通知を送る」といった、ユーザーの状況に応じたシナリオを自動で実行してくれます。</p>
<p>参考：<a href="https://karte.io/product/journey/">KARTE Journey</a></p>
<p>現在、Journeyチームでは配信基盤周りの改善を行なっています。その中核としてユーザーのイベントが発火した瞬間に処理を行う「イベント処理基盤」と、指定時間の経過や条件の評価などをバッチ処理で行う「定期実行基盤」を開発しています。<br>
今回は「定期実行基盤」にまつわるタスクを行いました。</p>
<h2>業務内容紹介</h2>
<h3>時間経過の判定の処理のリアーキテクチャ</h3>
<p>Journeyにおいてシナリオは、ユーザーの行動や通知の配信などといった1つ1つのステップに分けられます。その中には、「指定時間までユーザーを待つ」といったものもあります。そこでは、「2時間後」「毎週金曜の18:00」「月末の12:00」など、様々な条件でユーザーが留まる時間を指定することができます。</p>
<p><img src="https://ik.imagekit.io/plaid/7bd172a8-fccb-4f88-b8c7-932f98ea5b8c/blog_image_1.png" alt="blog_image_1.png"></p>
<p>定期実行基盤の主要な部分として、各ステップの遷移対象となるユーザーを抽出するコンポーネントと、遷移対象のユーザーを実際にデータベースに書き込んで次のステップへ移すコンポーネントがあります。</p>
<p>従来の実装では、データ更新を担うコンポーネント（下図右側）が、ユーザーを待つ処理がある時には「ユーザーの待ち時間の終了時刻を計算する」という処理も行なっていました。本来書き込みに専念すべき場所に、時刻計算のビジネスロジックが混在して責務が曖昧になり、全体の見通しの悪さが課題となっていました。</p>
<p><img src="https://ik.imagekit.io/plaid/d14465ef-2fd8-43d2-9d4b-02e3d39884e8/blog_image_2.png" alt="blog_image_2.png"></p>
<p>そこで、遷移を実行するコンポーネントで書き込み処理に専念できるよう、遷移対象を抽出する段階で動的にSQLを生成するように実装を変更しました。*1<br>
具体的には、TypeScript側で「現時点でいつの時刻まで流入してきた人が遷移対象となるべきか」を計算し、それを用いてクエリを書くといった実装でした。</p>
<p>*1: BigQueryのUDF(User defined function)も検討しましたが、行数を少なく実装できる一方で可読性やメンテナンス性が低かったため見送りました。</p>
<p><img src="https://ik.imagekit.io/plaid/72d50f67-2cbf-4a7a-9682-c6fb7d3d5a83/blog_image_3.png" alt="blog_image_3.png"></p>
<p>大変だったことは、網羅すべきパターンが多く、単純な計算なのにも関わらずコード量が膨大になったことです。初めはパターンごとにクエリを実装していましたが、SQLの構造が2つのパターンに集約できるのを見抜いて、計算部分を切り出しました。まだまだSQLの動的生成の可読性は課題ではあるものの、コードの見通しはある程度良い状態で実装ができました。</p>
<p>実装の細部にまで目を配ってレビューしていただき、非常に勉強になりました。例えば、待ち時間のパターンに対して Discriminated Union の導入を提案いただいたことで、より型安全に整理できました。このように、今まで知らなかった技術を活かして実践的なコード改善に繋げるという貴重な体験は、自身の成長に大きくつながりました。</p>
<h3>定期実行基盤の負荷検証</h3>
<p>次に、クラウドインフラのリソースを増やすことによって定期実行基盤が本番トラフィックを処理可能か、そのスケーラビリティを検証するための負荷テストを行いました。</p>
<p>目標実行時間を2分半以内と設定し、大量の検証用データを投入してテストを開始したのですが、現実は甘くありませんでした。実行時間は常に目標を大幅に上回り、ボトルネック探しの調査が始まったのです。</p>
<p>以下の流れで負荷検証を行いました。</p>
<ol>
<li>データ大量投入スクリプトの準備</li>
<li>検証</li>
<li>デプロイ設定の変更(複数回)</li>
<li>Datadogメトリクスの導入</li>
</ol>
<p><strong>仮説1：ユーザー抽出時のリソース不足</strong></p>
<p>まず疑ったのは、コンピューティングリソースの不足です。</p>
<p>実際に、テストの初期段階ではcpu使用率が頭打ちしていて、メモリにも余裕がない状況でした。GKEのpod数を10程度まで増やしてリソースを潤沢に確保しました。しかし、CPU使用率は安定したものの、実行時間は依然として5分を超過したままでした。</p>
<p><img src="https://ik.imagekit.io/plaid/fd0a8e70-2268-408f-b9f2-a133f8398704/blog_image_4.png" alt="blog_image_4.png"></p>
<p><strong>仮説2：データベース処理の遅延</strong></p>
<p>次に目を向けたのは、データベース、特にBigQuery(BQ)の処理です。Temporalのワークフローの実行記録(上の画像)から、BQでの一時テーブル作成やSpannerへのエクスポートの処理に時間がかかっている可能性が浮かび上がりました。</p>
<p>これを検証するため、Datadogで各BQクエリの実行時間を計測可能にしました。その結果、クエリの実行時間は最長で10秒程度であることがわかりました。5分以上の実行時間を説明するには不十分でした。</p>
<p><img src="https://ik.imagekit.io/plaid/39f98e76-7cac-4acf-bb7a-1911ff967d40/blog_image_5.png" alt="blog_image_5.png"></p>
<p><strong>真相：直列実行の罠</strong></p>
<p>八方塞がりかと思われた中で、GKEのログを見てみたところ、驚くべき事実が判明しました。<br>
調査の結果、検証環境では本来並列で実行されるべき多数のタスクが、なぜか直列に一つずつ処理されていたのです。すなわち、BQやSpannerのIO待ちが積み重なっていたということです。<br>
今回のボトルネックの正体は、「デプロイされた環境における並列処理の不具合」だったのです。<br>
最終的に問題を完全に修正するところまで至りませんでしたが、この調査プロセスは非常に大きな学びとなりました。<br>
「仮説を立て、データを用いてそれを検証し、次の打ち手を考える」というサイクルを高速で回すことの重要性を肌で感じました。巨大なシステムにおける問題解決のリアルな一端に触れられた、非常に価値のある経験でした。</p>
<h2>インターン生活について</h2>
<h3>プレイドでの働く環境</h3>
<p>全体的にオープンな雰囲気で、誰にでも気軽に質問や相談ができました。特に印象的だったのは、タスクに関する何気ない相談が、次第にプロダクトの設計といった、より深い議論に発展していく光景でした。1人の思考がチームとしての思考に拡張されてゆくような、新鮮な体験でした。<br>
また、ランチの時間には他のチームの方とも交流することができ、毎日楽しく過ごすことができました。インターン生同士や新卒の方などとの繋がりもできてよかったです。</p>
<h3>インターンを通しての学び</h3>
<p>この1ヶ月で、エンジニアとして多方面にわたり大きく成長できたと感じています。<br>
実装における細かい技術的な側面から、プロダクトの提供する価値といったビジネス的な側面まで、幅広い視点でインプットできました。<br>
その中でも特に、データを大量に投入してパフォーマンスを観察するといったことは、自分一人ではできない新たな経験でした。大規模なデータを処理するアプリケーションのインフラの一端を覗くことができ、非常に勉強になりました。</p>
<h2>最後に</h2>
<p>この1ヶ月は、手厚いサポートを受けながらも手応えのあるタスクに没頭することができ、非常に充実した時間でした。改めて、Journeyチームの皆様には心から感謝しています。<br>
このインターンは、刺さる人には深く刺さるものだと感じています。「手応えのあることに挑戦したい」「新しい技術に触れてみたい」といった方には最高の環境です。<br>
そのワクワクするような経験を、ぜひ次はご自身で体験してみてください。</p>


こんにちは、藤井駆陸です。普段は化石について研究している大学院生です。9月の間、プレイドのJourneyチームにてインターンに参加しておりました。  振り返れば一瞬に感じられた1ヶ月でした。頭を抱えながら巨大なアーキテクチャの概要を掴み、タイムゾーンとSQLに苦戦しながら多くの実装をし、検証用環境を追い込んで問題点を洗い出す。そんな目まぐるしい日々でした。  この記事では、実際に関わったタスクや、インターンの率直な感想についてお伝えできればと思います。

プレイドインターン体験記：大規模システムのリアーキテクチャと負荷検証

<p>KARTE for Appチームのエンジニアの悴田です。</p>
<p>プレイドは、2025年9月19日〜21日に開催された <a href="https://iosdc.jp/2025/">iOSDC Japan 2025</a> にゴールドスポンサーとして協賛し、ブース出展も行いました。<br>
本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。</p>
<h2>ブースのご紹介</h2>
<p>プレイドでは、モバイルアプリ向けのSDKを開発・提供しています。</p>
<p>現在は、モバイルアプリのエンゲージメント向上を目的とする「<a href="https://karte.io/package/app/">KARTE for App</a>」と、Native UIの開発生産性向上を目的とした新規プロダクト (本記事公開時点ではクローズドベータ)、の2つを提供しています。<br>
今回のブース企画・運営は、これら2チームの開発メンバーを中心に行いました。</p>
<p>ブースでは、「<strong>アプリグロースの課題に関するパネルアンケート</strong>」と「<strong>マーケティングSDKの利用状況に関するWebアンケート</strong>」の2つを実施しました。</p>
<p><img src="https://ik.imagekit.io/plaid/b4be8f0a-852a-4130-8084-919d5678507c/IMG_0075.jpg" alt="IMG_0075.jpg"></p>
<p>アンケートにご協力いただいた方々には、弊社のノベルティグッズをプレゼントしました。<br>
ノベルティグッズとして「ラムネ」「歯磨きセット」「携帯式のコップ」「米 (2合)」を用意し、特に「米」は物珍しさもあって好評でした。</p>
<p>また、Webアンケートは弊社の「KARTE」を用いて作成し、アンケートの回答後にはくじを引けるようにしました。<br>
見事当たりを引いた方には、弊社のエンジニアが厳選した技術書の中から、お好きな一冊をプレゼントさせていただきました。</p>
<p><img src="https://ik.imagekit.io/plaid/740576ff-fc73-4bc2-ab3b-544df4b54c73/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%882025-09-2915.02.17.png" alt="スクリーンショット2025-09-2915.02.17.png"><br>
当選者の方々 (ブログ掲載許諾取得済み)</p>
<h2>印象に残ったセッション</h2>
<p>テストやビルドといったMobile SDK開発にも関係するセッションや、個人的に興味のある低レイヤー寄りのセッションを聴講しました。</p>
<h3>1. 半自動E2Eで手っ取り早くリグレッションテストを効率化しよう</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="半自動E2Eで手っ取り早くリグレッションテストを効率化しよう" src="https://speakerdeck.com/player/b2991526951744758463d4663866c514" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>タイミー社での、E2Eテストの効率化に向けた現実的なアプローチが紹介されました。</p>
<p>当初、同社ではCI/CDとSaaSを活用した全自動のE2Eテストを目指していましたが、SaaSを使いこなす難しさや、SMS認証・QRコード読み取りといった実機特有のテスト項目が障壁となり、1年以上かけても安定運用には至らなかったそうです。</p>
<p>そこで、全自動化を諦め、以下のような「<strong>簡単にできる部分だけ自動化する</strong>」という半自動の方針に切り替えました。</p>
<ul>
<li>ローカルPCでアプリをビルドし、実機にインストールしてテストを実行する。</li>
<li>テスト自動化ツールとして、Railsで使い慣れている「Ruby」で記述できるAppiumを使用する。</li>
<li>自動化できない処理は、手動で操作する。スクリプト内にsleepメソッドを入れ、一時停止中に手動で操作する。手動操作のタイミングは、音を鳴らす仕組みで伝える。</li>
<li>うまく検出できないUI要素は、OCRを利用した画面タップで対応する。</li>
</ul>
<p>このアプローチにより、<strong>わずか1ヶ月で運用を軌道に乗せることに成功</strong>したそうです。</p>
<hr>
<p>私たちのチームにおいても、Mobile SDKのテスト自動化は重要な課題の一つです。<br>
本セッションで語られている、完璧を求めず、最小の労力で最大の成果を得ることを目指すアプローチを取り入れたいと思いました。</p>
<hr>
<h3>2. Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム" src="https://speakerdeck.com/player/89fc533243314e52a7bca2e17d6a4c23" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>XcodeならびにSwift Package Manager (SPM) において、Swiftコードがビルドされる流れと、その際に利用される各種ツール (`xcodebuild`, `swiftc`, `llbuild`など) の役割が紹介されています。</p>
<p>Xcodeでのビルドの場合、まずはXcodeが*.xcodeprojから「<strong>llbuildマニフェスト</strong>」を作成します。llbuildマニフェストとは、<strong>ビルドに必要なタスク一覧とそれらの依存関係を記述したファイル</strong>です。<br>
続いて、llbuildマニフェストは「llbuild」に渡され、実際のビルド処理をコンパイラ (swiftc/clang) やリンカ (ld) を用いて実行します。</p>
<p>一方、SPMでのビルドの場合には、SPMがPackage.swiftからllbuildマニフェストを生成し、llbuildに渡します。<br>
このような、<strong>llbuildマニフェストを生成するツールの違いが、XcodeとSPMの機能差の一因</strong>となっています。</p>
<p>その前提知識を踏まえた上で、最近新たに登場した「Swift Build」の立ち位置と可能性について解説されています。<br>
<strong>Swift Buildは、XcodeおよびSPMの両方において「llbuildマニフェストの生成」を行えるツール</strong>です。これにより、機能差の軽減や新たな機能追加が見込まれています。</p>
<hr>
<p>Swiftのビルドシステムの仕組みを、馴染みのない人でも難なく理解できるよう、丁寧に解説されています。<br>
このテーマがここまで分かりやすく解説されるのは希少だと思いますので、ぜひアーカイブが公開されたら視聴をお勧めしたいです。</p>
<hr>
<h3>3. Embedded Swiftで解き明かすコンピューターの仕組み</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.2903%;"><iframe title="Embedded Swiftで解き明かすコンピューターの仕組み | ドクセル" src="https://www.docswell.com/slide/5QX77N/embed" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen></iframe></div>
<p>このセッションは、<strong>Embedded Swift</strong>と<strong>MMIO (メモリマップドI/O)</strong> を使い、OSのないベアメタル環境でコンピューターをゼロから動かす仕組みを紹介しています。</p>
<p>コンピューターの中心には<strong>CPU</strong>があり、機械語で書かれた命令を実行して動作します。<br>
このCPUが実行できる命令セット (ISA) は、画面表示やネットワーク通信といった複雑な機能を直接含んでいる訳ではありません。</p>
<p>画面表示やネットワーク通信といった、周辺機器 (GPUやストレージなど) の制御に使われるのが、<strong>MMIO (メモリマップドI/O)</strong> です。<br>
MMIOは、GPUなどの周辺機器をメモリ上の一領域とみなし、特定アドレスへデータの読み書きを介して、周辺機器をコントロールする技術です。</p>
<p><strong>Embedded Swift</strong>を使用することで、特定のメモリアドレスを直接操作できる、すなわちMMIOが可能となります。Embedded SwiftによるMMIOの実演として、Raspberry Piの画面を操作して、Swiftのロゴを画面に表示するデモが行われました。</p>
<hr>
<p>コンピュータの動作原理の核心に迫る内容で、個人的に非常に面白かったセッションです。<br>
説明が丁寧、かつ実演もあり、低レイヤに詳しくない人でも知的好奇心を満たされる内容かと思います。</p>
<hr>
<h3>4. アセンブリで学ぶCPUアーキテクチャ</h3>
<div style="left: 0; width: 100%; height: 0; position: relative; padding-bottom: 56.1972%;"><iframe title="Learn CPU architecture with Assembly" src="https://speakerdeck.com/player/6220b9f1e63846039dad83abc0dfcba8" style="top: 0; left: 0; width: 100%; height: 100%; position: absolute; border: 0;" allowfullscreen scrolling="no"></iframe></div>
<p>Intel Macのサポート終了が発表され、Apple Siliconへの完全移行という転換点を迎えた今、<strong>アセンブリ言語を通じて、CPUアーキテクチャの仕組みを学ぼう</strong>というセッションです。</p>
<p>まず、これまでのMacにおけるCPUの歴史を振り返っています。<br>
Macはこれまで、<strong>Motorola 68k (CISC)</strong> → <strong>PowerPC (RISC)</strong> → <strong>Intel x86 (CISC)</strong> → <strong>Apple Silicon (RISC)</strong> のように、命令セット (ISA) が複雑な<strong>CISCアーキテクチャ</strong>と、命令が単純な<strong>RISCアーキテクチャ</strong>の間を行き来してきました。このアーキテクチャ移行を裏で支えてきたのが、Rosettaのようなエミュレーション技術です。</p>
<p>続いて、アセンブリ言語の基礎が解説されています。アセンブリとは、機械語と1対1で対応する低レベルなプログラミング言語です。<br>
このセッションでは、<strong>「Hello, World!」の出力をアセンブリで行うことで、CPUの動作原理を解説</strong>しています。同じ処理でも、 CISC と RISC でアセンブリの記述が変わることも示されました。</p>
<p>最後に、実務的な応用例として、アプリがクラッシュした際のスタックトレースを読む際に、アセンブリの知識がどのように役立つかが紹介されました。</p>
<hr>
<p>3.のセッション (Embedded Swiftで解き明かすコンピューターの仕組み) と同様、コンピュータの動作原理を解説した内容ですが、異なるレイヤーにフォーカスした解説となっています。<br>
両方のセッションを聴講したことで、コンピュータの動作原理をより立体的に理解できました。</p>
<p>アプリ開発をしていると、時たま「あるライブラリがApple Siliconでは動かない」など、CPUアーキテクチャを意識せざるを得ない場面に遭遇するかと思います。そういった場面に備えて、低レイヤーの理解を深める上で良いセッションかと思います。</p>
<hr>
<h2>おわりに</h2>
<p>iOSDC Japan 2025の3日間、弊社ブースへ多くの方々にお立ち寄りいただきました。<br>
アプリのグロースに関する課題感から、KARTEのご紹介まで、皆さんと直接お話しできたことは、私たち開発チームにとって大変有意義でした。</p>
<p>本記事でご紹介したセッションは、私の個人的な興味から低レイヤー寄りの内容が多くなりました。<br>
私と同じくコンピュータサイエンスの探求が好きなモバイルエンジニアの方がいらっしゃいましたら、ぜひカジュアル面談でお話ししましょう！</p>
<p>プレイドでは、以下のポジションで<strong>モバイルエンジニアを積極的に採用</strong>しています。<br>
ご興味のある方は、ぜひリンク先の募集要項をご覧ください。</p>
<ul>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/102069">Mobile App SDK Engineer</a></li>
<li><a href="https://open.talentio.com/r/1/c/plaid/pages/106290">アプリエンジニア（新規プロダクト開発）</a></li>
</ul>
<p>最後に、この素晴らしいカンファレンスを企画・運営してくださったスタッフの皆様、そして私たちのブースに足を運んでくださった全ての参加者の皆様に、心より感謝申し上げます。</p>


プレイドは、2025年9月19日〜21日に開催された iOSDC Japan 2025 にゴールドスポンサーとして協賛し、ブース出展も行いました。 本記事では、当日のブースの様子と、聴講した中で特に印象的だった4つのセッションについてご紹介します。

iOSDC Japan 2025参加レポート｜ブース出展の裏側と印象に残ったセッション4選

巨大モノレポ環境でのDeveloper Experience改善に挑戦したプレイドのサマーインターン体験記。CI効率化や社内ESLintプラグイン開発、pnpm catalog移行など技術的成果と、柔軟な労働・開発環境のリアルな様子を詳しく紹介します。

プレイドインターン体験記：巨大モノレポとDeveloper Experienceの改善

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

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

@end

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


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

KARTE for App SDKのOSS化によるDeveloper Experience向上への取り組み

BigQueryのリソース配分最適化のため、プロジェクトへのコミットメントの割り当てパターンや、スロット消費の多いクエリの見つけ方などについて調査した結果をまとめてみました

6,000スロットを使うBigQueryのリソース配分最適化への挑戦

GitHub Actions を使って継続的ローカライゼーションをスクラッチから構築した話 | PLAID engineer blog

GitHub Actions を使って継続的ローカライゼーションをスクラッチから構築した話

npmのprivate registryからGitHub Packages Registryに移行する

Dockerfile効率化のベストプラクティスを、リードタイム(CI/CDの実行時間)を短縮し開発生産性を向上させる為に行うべき事という観点でまとめました。
1.Docker Daemonへの転送ファイル削減
2.Docker Imageのサイズ削減
3.cacheの有効活用

Docker Buildにおけるリードタイム短縮のための3つの改善ポイント | PLAID engineer blog

Docker Buildにおけるリードタイム短縮のための3つの改善ポイント

2019年10月から2020年2月まで開発チームで取り組んだアンケートフォーム(β版)のリリースまでのリアルな道のりを記しています。エンジニア、デザイナー、プロダクトマネージャーにはぜひ読んで欲しい内容です。

KARTEのアンケートフォーム(β版)公開までの道のり

<p>こんにちは、エンジニアの <a href="https://twitter.com/kargo113">@kargo</a> @nichimu です。KARTEのDatahubというプロダクトに携わっており、KARTEのデータ及びお客様のデータを活用したプロダクトの開発を行っています。<br>
今回は、KARTEにおいて活用しているコンテナネイティブのワークフロー基盤であるKubeflow Pipelineの組み込みについての概要をご紹介したいと思います。</p>
<h1>Kubeflow とは</h1>
<p>ここ数年でMLOpsという言葉が浸透するようになり、機械学習の実運用についての具体例がたくさん見受けられるようになりました。<br>
<a href="https://www.kubeflow.org/docs/about/kubeflow/">Kubeflow</a> はそのような機械学習の実運用をスムーズに行うためのオープンソースのプラットフォームです。Kubernetes上で動作することを前提とされているので、GKEやEKS、オンプレミスのKubernetes基盤にデプロイすることができます。直近では最新のv1.0が公開されているようにかなりのスピードで発展してきており、コミュニティも盛んです。<br>
Kubeflowは様々な機能がありますが、今回はその中でも Kubeflow Pipeline というコンテナのワークフロー基盤を活用した事例についてご紹介していきます。<br>
Kubeflow Pipelineの基本的な使い方についてはそれだけで1つのブログが書けるボリュームですので、以下の内容では使い方については触れません。それを前提とした上で、活用方法について述べていきます。基本的な使い方は<a href="https://www.kubeflow.org/docs/about/kubeflow/">ドキュメント</a>がわかりやすいので是非ともご参考にして頂ければと思います。</p>
<h1>Components について</h1>
<p>弊社では、KARTEに蓄積されたデータを用いて、クラスタリング・需要予測・レコメンデーション・購買予測・不正検知など様々な取り組みを行っています。<br>
Kubeflow Pipelineで動かすPipelineは大きく分けて</p>
<ul>
<li>学習用パイプライン</li>
<li>推論用パイプライン</li>
</ul>
<p>の2つがあります。これらを各タスクごとに管理しています。</p>
<p>各タスクごとにコンポーネントはなるべく共通化したく、<a href="https://www.tensorflow.org/tfx">TFX</a> の概念を大いに参考にさせて頂きました。TFXは機械学習タスクに必要なコンポーネントが丁寧に抽象化されており、今回は以下の図のようなコンポーネントを参考にしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/2149e535-f318-4b6a-ba94-70c8adc5bb2d/tfx.svg" alt=""></p>
<p>実際に学習用パイプラインで構築したコンポーネントは</p>
<ul>
<li>ExampleGen</li>
<li>SchemaGen</li>
<li>Transform</li>
<li>Trainer</li>
<li>Evaluator</li>
<li>Pusher</li>
</ul>
<p>の6つです。</p>
<p>ExampleGenでは、BQにある膨大なデータからクエリによりデータを抽出<br>
SchemaGenでは、抽出したデータのスキーマを自動で判定<br>
Transformでは、LabelEncorder等により前処理を実行<br>
Trainerでは、GridSearch等を用いて最適なモデルの学習<br>
Evaluatorでは、学習済モデルの評価を行い、モデルの妥当性を検証<br>
Pusherでは、評価されたモデルをデプロイする<br>
といった実装になっています。<br>
これらをPipelineとして単純に直列に以下の図のように繋いでいます。<br>
各コンポーネントでのデータの受け渡しはGCSを用いており、データのPATHを受け渡すようにしています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/5ae769ac-5242-4cba-a50c-a349015431de/kubeflow-1.svg" alt=""></p>
<p>推論パイプラインでは、<br>
ExampleGen, SchemaGen, Transformerまでは同様で、これにデプロイしたモデルを用いたPredictorというコンポーネントを直列に繋いで推論を行っています。</p>
<p>また、直列で繋いでいる理由として大量のリソースを消費するものに関しては、各コンポーネント内で外部にジョブを投げているからです。</p>
<p>例えば、ExampleGenにおいてはApache Beam SDKを用いて実装しているので、大規模分散処理に関してはDafaflow上で実行することが可能です。さらに、Trainerにおいても、学習ジョブはAI Platform Trainingで実行しているため、こちらも大規模並列学習が可能になっています。<br>
つまり、Kubeflow Pipelineをデプロイしているクラスタのリソースは最小で、必要に応じて外部のマネージメントサービスを活用することで、簡単なタスクから複雑なタスクまで幅広く対応できるようになっています。</p>
<h1>Pipelines SDK の活用</h1>
<p>Kubeflow Pipeline には <a href="https://www.kubeflow.org/docs/pipelines/sdk/sdk-overview/">Pipeline SDK</a> と呼ばれるものも用意されており、外部からでも簡単にパイプラインの実行や管理ができるようになっています。これを活用しフロントエンドと連携をしています。<br>
例えば、</p>
<pre><code>client = kfp.Client(
    host=&quot;YOUR_KUBEFLOW_HOST&quot;, 
    client_id=&quot;OAUTH_CLIENT_ID&quot;
)
res = client.run_pipeline(
    experiment_id=&quot;YOUR_EXPERIMENT_ID&quot;,
    job_name=&quot;JOB_NAME&quot;,
    pipeline_id=&quot;PIPELINE_ID&quot;,
    params=&quot;ARGUMENTS&quot;,
)

</code></pre>
<p>といったように指定したパイプラインの実行ができます。<br>
paramsに任意の引数を渡すことで柔軟にパイプラインの実行が可能です。</p>
<p>wait_for_run_completionやget_runメソッドも用意されているので、パイプラインの実行状況を確認することも容易です。</p>
<p>補足ですが、私たちの環境ではCloudIAP認証を用いているため、client_idが必要です。また、実行するサービスアカウントにIAP で保護されたウェブアプリ ユーザーという権限を付与する必要がある点にも注意が必要です。</p>
<h1>フロント画面との連携</h1>
<p>KARTEの管理画面で使用している技術を簡単に述べると、フロント: Vue.js、バックエンド: Node.js、DB: MongoDBで構成されています。<br>
管理画面から任意のパラメータを入力し、Kubeflow Pipelineのパイプライン処理を実行をさせた上で、モデルの結果はいつでも管理画面から取得できる状態にしたいというのが今回の要件です。</p>
<p>現状、Pipeline SDKにはpythonのものしかなく、バックエンドがNode.jsであるKARTEで使おうと思うと、Node.jsにあるPython-shellを使用するかFlask等を使ってRESTの口をつくるかの2通りありました。<br>
その中で、我々は、新たにPythonベースのコンテナをGKEに立てて、Node.jsベースのコンテナとkubeflow clusterの橋渡しとなるようなinternalなAPIとして用いる方針をとりました。<br>
PythonベースのコンテナでPipeline SDKを使えるようにすることで、KARTE管理画面からKubeflow Pipelineを実行できるようにしました。</p>
<p>また、PipelineのジョブパラメータはMongoDBに保存しておくことで、いつでもKARTE管理画面からジョブの実行結果を確認できるようにしました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/f84d0fa8-a21d-4fd4-8975-c8d3c24297d7/backend.png" alt=""></p>
<p>このようにKARTEの管理画面からも簡単に任意のパラメーターでパイプラインを実行し、結果を取得することが可能です。</p>
<p>こういったSDKもきちんと用意されており、連携も簡単にできる点も素晴らしいですね。</p>
<h1>今後の課題</h1>
<h4>サービスアカウント問題</h4>
<p>現状のKubeflow Pipelineの仕組みではパイプラインをKubeflowにデプロイする段階でSecretをコードで指定する仕組みになっています</p>
<pre><code>dsl.ContainerOp(
    name=&quot;NAME&quot;,
    image=&quot;IMAGE&quot;,
    command=[&quot;COMMAND&quot;],
    arguments=[&quot;ARGUMENTS&quot;],
)
.apply(gcp.use_gcp_secret(&quot;user-gcp-sa&quot;))

</code></pre>
<p>そのため、実行するパイプラインごとに引数等でサービスアカウントを指定することができません。こちらも柔軟に変更できた方が権限管理は非常に便利になるのですが、現状は未対応なので場合によっては裏側で色々と権限管理を頑張る必要性が出てきます。</p>
<h4>Kubeflow? TFX? AIPlatform?</h4>
<p>少し余談にはなりますが、このあたりきちんと使い分けられている方は少ないのではないでしょうか。<br>
Kubeflowはドキュメントにしたがってデプロイするとやや大きめなMachineTypeでNodePoolが作成され、GPU Node Poolも作成されます。つまり、このクラスタ内のリソースを使うのだろうと思っていたのですが、exampleを見ると Data Proc や AI Platform にジョブを投げているものもあります。さらに、TFXではTensoflow Transformerというものがあり、これはDataFlowにジョブを投げるものとなっています。こうなってくるとかなりややこしく、結局どういう構成がベストプラクティスなのかが見えづらい状況です。<br>
あくまで私たちの仕組みでは、Kubeflow Pipeline自体のリソースは最小限に、コンポーネントの各ジョブは外部リソースを使ってスケールさせるという選択肢をとったに過ぎないので、この内容がみなさまの実際のケースに沿って最適な選択の一助となれば幸いです。</p>


KARTEにおけるフロントエンドと連携させたKubeflow Pipelineの活用方法について解説します

KARTEにおけるKubeflow Pipelineの活用 | PLAID engineer blog

KARTEにおけるKubeflow Pipelineの活用

2019年以降、Slack APIがどのように変化し何に注意すべきかについてご紹介します。主にBlock Kit、Modal、Home tabなどSlack上での新しい表現や、Granular permissionsと呼ばれる新しい権限モデルへの対応方法について詳しく説明しています。

2020年のSlack App開発者が知るべき最新のSlack API仕様 | PLAID engineer blog

2020年のSlack App開発者が知るべき最新のSlack API仕様

<p>こんにちは、エンジニアの <a href="https://github.com/komukomo">@komukomo</a> です。2020/01/30 に行われた <a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">Google Cloud Anthos Day</a> に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。（他の登壇者の方の資料も<a href="https://inthecloud.withgoogle.com/anthos-day-2001/register.html">公式サイト</a>にて公開されています）</p>
<hr>
<p>我々が開発している <a href="https://karte.io/">KARTE</a> ではユーザの行動データを扱っており、その中にはセンシティブなデータも含まれているので KARTE を開発する上ではセキュリティというのは重要なトピックです。ということで今回お話したのはセキュリティに関する内容で、直接プロダクトの KARTE とは関係ないのですが、</p>
<ul>
<li>GKE でのセキュリティに関する考え方</li>
</ul>
<p>と、個別機能の紹介とユーザ目線での注意点や感想ということで</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a></li>
<li><a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a></li>
<li><a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a></li>
</ul>
<p>について発表してきました。内容としては、これからGoogle Kubernetes Engine (GKE) を導入しようとしている方や運用しはじめの方、機能の概要を知りたい方向けのお話となっています。</p>
<p>こちらにスライドとざっくりお話した内容を載せておきます。</p>
<script async class="speakerdeck-embed" data-id="b9e34200315a473fae23b66f07ca4168" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<h1>GKEにおけるセキュリティ対策</h1>
<p>最初のトピックは GKE でのセキュリティ対策の話で、中身を省いて結論のみ書いてしまうと、</p>
<ul>
<li>ユーザの管理範囲と Google の管理範囲を意識しましょう</li>
<li>まずは GKE 公式のドキュメントにそって運用していきましょう</li>
</ul>
<p>ということで基本的すぎる感じになってしまいましたが、それでも重要なことだとは思うので、ここにも当日紹介したドキュメントのリンクを貼っておきます。</p>
<p>GKE の記事:</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/security-overview">Security overview</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster">Hardening your cluster's security</a></li>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/security-bulletins">Security bulletins</a></li>
</ul>
<p>こちらは GKE に限らず、Kuberentes の記事:</p>
<ul>
<li><a href="https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/">9 Kubernetes Security Best Practices Everyone Must Follow</a></li>
<li><a href="https://kubernetes.io/blog/2016/08/security-best-practices-kubernetes-deployment/">Security Best Practices for Kubernetes Deployment</a></li>
</ul>
<p>以降は個別の GKE の機能のお話です。</p>
<h1>GKE Sandbox</h1>
<p><a href="https://cloud.google.com/kubernetes-engine/sandbox/">GKE Sandbox</a> は、信頼できないワークロードをクラスタで動かすようなケースで有用な機能です。<br>
内部では <a href="https://gvisor.dev/">gVisor</a> が使われていますが、この仕組みは使う前にざっくりとでも中身を知っておくとといろいろと判断する上で役に立ちます。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/69ebe27d-0498-4443-96bb-bc1888ce20d6/Screen-Shot-2020-01-31-at-13.11.04.png" alt="Screen-Shot-2020-01-31-at-13.11.04"></p>
<p>gVisor では kernel の System Call をインターセプトして、kernel の機能を emulation するようなレイヤを実装しています。（さらっと書きましたが、なかなか凄まじい実装です。コードは<a href="https://github.com/google/gvisor">こちら</a>。）<br>
このようなレイヤを実装することで、コンテナは System Call を直接実行できなくなり、Host はセキュリティを考慮して制限された System Call のみ処理するようになるので、kernel の脆弱性を悪用するような攻撃から Host を守ることができます。</p>
<p>この gVisor をGKE上で使えるようになっているのが、 GKE Sandbox です。</p>
<h2>注意点</h2>
<p>使用する上で気をつけておくとよさそうと感じたのは、互換性、パフォーマンス、gVisor の責任範囲についてです。</p>
<h3>互換性</h3>
<p>kernel の機能を emulation している部分があるので、そもそも使いたい機能が使えるかはまず確認しておくとよいかと思います。GKE Sandbox にも gVisor にも互換性に関するドキュメントがあるので両方読んでおくと確実かと思います。</p>
<ul>
<li><a href="https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods?hl=en#limitations-incompatible">(GKE Sandbox) Incompatible features</a></li>
<li><a href="https://gvisor.dev/docs/user_guide/compatibility/">(gVisor) Compatibility</a></li>
</ul>
<p>自分は GKE Sandbox を最初試したとき <a href="https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/">Port Forward</a> が使えないということを知らずにデバッグしようとしていて、無駄に調査に時間をかけてしまいました😅</p>
<h3>パフォーマンス</h3>
<p>こちらもgVisorがSystem Callをemulationしているため gVisor を使うとそのワークロードのパフォーマンスが劣化する可能性があります。逆にいうと、System Call を激しく使わない数値計算のようなワークロードはそれほど影響はないと考えられます。<br>
実際に GKE Sandbox を使う場合にはもちろんその時に計測するかと思いますが <a href="https://gvisor.dev/docs/architecture_guide/performance/">gVisor のPerformance Guide</a> もあるのでこちらも参考になるかと思います。</p>
<h3>gVisorの責任範囲</h3>
<p>仕組みをしっていれば当たり前の話かもしれませんが、gVisor を使えばサンドボックス化は完璧、というものではありません。例えば Pod 間通信の制御をするなら別途設定が必要です。自社でサンドボックスのような基盤が必要なサービスを運用する場合は、gVisor の挙動を把握した上で適宜必要なレイヤーの制限をかけていく必要があります。<br>
gVisor がどのような目的で作られ、どのような脅威を軽減するのかについては <a href="https://gvisor.dev/docs/architecture_guide/security/">Security Model</a> に詳しく書かれています。</p>
<h1>Binary Authorization</h1>
<p>次の話は<a href="https://cloud.google.com/binary-authorization/">Binary Authorization</a>。こちらは信頼できるイメージのみがデプロイされることを保証できる機能です。クラスタでBinary Authorization を有効にすると、Pod 作成の前に Policy のチェックが入ります。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/66682698-9e64-4edf-8df2-0d15a91021ce/Screen-Shot-2020-01-31-at-13.35.02.png" alt="Screen-Shot-2020-01-31-at-13.35.02"></p>
<p>Policy の設定としては image の Path のホワイトリストの他、 <a href="https://cloud.google.com/binary-authorization/docs/making-attestations">attestation</a> という概念があるので、信頼できる検証者によって検証されたイメージのみ許可、といった設定が可能です。（※発表スライド内では&quot;署名&quot;と書いてしまっていますが、英語では attest なので多分&quot;証明&quot;、&quot;検証&quot;という訳の方が正しいですね。）</p>
<p>設定可能な <a href="https://cloud.google.com/binary-authorization/docs/policy-yaml-reference">Policyの仕様</a> はとてもシンプルなので、ざっと<a href="https://cloud.google.com/binary-authorization/docs/example-policies">設定例</a> と合わせて読めばすぐに把握できるかと思います。</p>
<p>運用時は、いろいろと例外的な状況も発生するかと思いますが、Dry Run（Policyチェックしてログは出すが制限しない）や、Break Glass（ Policy を無視してデプロイできるようにするannotation）という機能もあり、こういった運用時の考慮もされています。</p>
<h2>注意点・感想</h2>
<p>Binary Authorization の注意点としては、PolicyはGCPのプロジェクトごとで、クラスタごとの設定はある程度できるのですが Namespaceごとの細かい設定はできません。そのため、大きなクラスタで複数チームを Namespace で管理している場合は Policy 設定が難しいかもしれません。</p>
<p>ちなみに Mercari さんではGKEのBinary Authorizationではなく、その内部で使われている<a href="https://github.com/grafeas/kritis">kritis</a> を<a href="https://tech.mercari.com/entry/2019/12/23/084839">自社でフォークして使用している</a>とのことです。</p>
<p>また、「何かを強制する」機能全般に言えることですが、Dry Run や Break Glass の機能があるとはいえ、管理するProjectが大きくなればなるほど導入が大変になるものです。（有効化したものの全対応が難しくいつまでたっても dryrun 状態...のように）<br>
導入するつもりなら早めに、迷っているなら修正が難しくなる前に判断するのがよいかと思います。</p>
<h1>Anthos Config Management</h1>
<p>最後に<a href="https://cloud.google.com/anthos/config-management/">Anthos Config Management</a> （以下、ACM）。こちらは、セキュリティというよりは運用の話ですが、Namespace や RoleBinding など様々な設定を管理するための機能です。</p>
<p>ACMはいわゆる <a href="https://www.weave.works/blog/what-is-gitops-really">GitOps</a> で クラスタの設定管理をするツールで、クラスタに ACM のオペレータを入れておくと、そのオペレータが指定した Git Repository と同期し設定をクラスタに反映してくれます。（ちなみに、とくに管理可能なオブジェクトの制限は今の所ないようで Namespace や RoleBinding だけでなく、Deployment や Service でも同期してくれます。そのため ACM でアプリケーションのようなものもデプロイ可能ですが、反映の順序は考慮されないそうなのであくまでも設定系のオブジェクトのみにしておいた方が良さそうです。）</p>
<p>単一クラスタ、単一 Namespace しか扱っていない場合はさほどありがたみはないかもしれませんが、複数クラスタ、Namespace を運用していて、似たようなポリシーを全体に適用したいケースなどに有用かと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/24dbe497-853a-4a1a-8f86-e14c60707833/Screen-Shot-2020-01-31-at-13.35.41.png" alt="Screen-Shot-2020-01-31-at-13.35.41"></p>
<p>Git Repository との同期だけであればその他の <a href="https://fluxcd.io/">flux</a> や <a href="https://argoproj.github.io/">argo</a> などでも可能かとは思いますが、ディレクトリの階層構造でNamespace に階層構造のようなものを持たせられる、という点は特徴的です。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/13096746-712c-4544-b2bb-5a1dcdd9754b/Screen-Shot-2020-01-31-at-13.35.49.png" alt="Screen-Shot-2020-01-31-at-13.35.49"></p>
<p>例えば ACM で管理するポリシーの Repository を上の図のようなディレクトリ構成（緑は何らかのk8sオブジェクトのyaml、オレンジは Namespace の yaml とします）にした場合、Namespace が3つ (audit, service-a, service-b) 作成され、<code>all-policy</code> は全てのNamespace に反映、<code>app-policy</code>は <code>service-a</code>と<code>service-b</code>の Namespace にのみ反映、といった挙動になります。</p>
<p>ちなみに ACM の他にも、こういった階層構造を使うというアイデアはあるようです。<br>
https://github.com/kubernetes-sigs/multi-tenancy</p>
<h2>感想</h2>
<p>ACM は仕組みも動作もシンプルなので、Anthos を使っていてクラスタ、Namespace が複数あるような環境ならば入れておいて特に損はなさそうかなと感じました。ACM の導入についても、既に多くのクラスタにいろいろな設定をいれて管理していたとしても、ACM 管理用の repository に対象のyamlを入れてそのオブジェクトが管理対象になる（ <code>configmanagement.gke.io/managed: enabled</code> という annotation がつきます）のを待つだけなのでそこまで大変ではなさそうです。</p>
<h2>Policy Controller</h2>
<p>ACM の基本的な機能は以上なのですが、追加オプションとして、 <a href="https://cloud.google.com/anthos-config-management/docs/concepts/policy-controller">Policy Controller</a> という機能もついており、こちらは <a href="https://github.com/open-policy-agent/gatekeeper">Gatekeeper</a> を使ったポリシーの Enforcer です。（ACM の機能とは全く別機能のような気がしますが、現状 ACM の中の機能として提供されていたのでおまけとして紹介しています。）</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/0099943d-6ac9-4d92-aa5f-74580eafe43e/Screen-Shot-2020-01-31-at-14.49.23.png" alt="Screen-Shot-2020-01-31-at-14.49.23"></p>
<p>例えば <a href="https://kubernetes.io/docs/concepts/policy/pod-security-policy/">PodSecurityPolicy</a> の場合は、「特権コンテナ禁止」といった特定の条件の制限ができるかと思いますが、こちらは任意の Kind の field をチェックできるため柔軟に設定をすることが可能です。公式の例では、Ingress の domain に重複がないか、Namespace に特定の prefix がついているか、などをチェックするサンプルがありました。</p>
<p>何をどう制限するか、というのは <a href="https://www.openpolicyagent.org/docs/latest/policy-reference/">Rego</a> という言語で書くことになるのですが、<a href="https://cloud.google.com/anthos-config-management/docs/how-to/creating-constraints-and-templates">よく使うテンプレートは予め用意されている</a>ので Rego を知らなくてもある程度使うことができます。</p>
<h1>最後に</h1>
<p>Google Cloud Anthos Dayで話したGKEのセキュリティとその周りの機能の紹介でした。Kuberentes も GKE でも次々と新機能がでてくるので追っていくのは大変ですが、全てのユースケースで必要なものではないものも多いので、しっかりそれぞれの機能を把握した上で適切に運用していきたいですね。</p>
<hr>
<h1>おまけ</h1>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/c94b1c36-a2d1-45ee-ae26-2b5bd16a8c2f/anthosday-plaid.jpg" alt="anthosday-plaid"><br>
<a href="https://github.com/MasayaAoyama">@amsy810</a> さんに撮っていただいた写真。ありがとうございます👍</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/aab76dea-068f-413c-832b-cfdbaa6baac5/20200130A_L260.jpg" alt="20200130A_L260"><br>
こちらは Google Cloud Anthos Day 後の懇親会。Googler、登壇者、スポンサー、様々なAnthos/k8sな人たちと話しました。これからのさらなる盛り上がりを感じたとともに、我々もどんどんアップデートしていかないとと感じました！...ということで、スピード感を持って一緒に開発していく仲間は常に募集しているので、興味のある方は<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または <a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a> からお気軽にご連絡ください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>


2020/01/30 に行われた Google Cloud Anthos Day に 「GKEにおけるセキュリティ対策と運用」というタイトルで登壇させていただいので、こちらのブログでもその内容を簡単にまとめておきます。

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました | PLAID engineer blog

Google Cloud Anthos DayでGKEのセキュリティ対策と運用について話してきました

<p>こんにちは。プレイドで2019年8月から現在までDevインターンとして働いている大矢です。2020年4月からは正社員として働く予定です。<br>
この記事では、プレイドのインターンでどんなことをしたか、何を学んだか、そして入社を決めた理由について書いていきたいと思います。</p>
<h1>はじめに</h1>
<p>簡単に自己紹介をします。僕は大学では情報工学を専攻していて、自然言語処理の研究をしています。<br>
2019年の8月からプレイドでインターンを始めて、週4日程度で通い、今月で約半年になります。<br>
プレイドでインターンをする以前にも、他社のインターンでWebアプリの開発をしたり、自然言語処理の技術を使った開発をする機会は何度かありました。研究が落ち着いた頃、開発経験を積みたいと思いインターンを探していました。</p>
<h1>インターンを始めるまで</h1>
<p>プレイドのインターンの求人（ <a href="https://www.wantedly.com/projects/387546">https://www.wantedly.com/projects/387546</a> ）には</p>
<ul>
<li>求められるレベルが非常に高い</li>
<li>圧倒的に成長できる</li>
<li>社員と同じチームで働くことができる</li>
</ul>
<p>というように書いてあり、求められるレベルが非常に高いことにビビりつつも、ちょっと背伸びした環境にいたほうが成長できるということはなんとなく知っていたので、面接を受けてみることにしました。面接では、プレイドのインターンの制度について聞いたのが印象に残っています。<br>
プレイドに参加したインターン生は、インターン担当の社員、メンターと数ヶ月おきに面談を行います。面談までの期間の成果や働き方をみて、継続が難しいと判断された場合には契約の更新が行われない場合がある、というものです。<br>
最初は戸惑いましたが、この制度はとても良いものだと思いました。まず、求人に書いてあった「求められるレベルが非常に高い」「圧倒的に成長できる」に対する説得力が格段に上がりました。求人にこのようなことを書いてある会社は他にもありますが、この会社で働けば確実に成長できるなと感じました。<br>
また、自分にとっても良い刺激になるなと考えました。3ヶ月おきに評価があるため、それまで気が緩むことなく常に全力で働ける。そして契約の更新が行われた場合には、一定の自信になりますし、更新が行われなかった場合にも、学生なので生活に困るということはないし、挫折を味わうことで成長につながるのではないかと思いました。<br>
つまり、インターン生にとってもこの制度はプラスだと思い、インターンに参加することを決めました。</p>
<h1>インターンでやった仕事</h1>
<p>プレイドでは、エンジニアのチームは1チーム1〜5人程度に分かれ、そのチームで2〜3ヶ月の期間（フォーカスと呼びます）目標を立てて開発をしていきます。僕は、入社してから1ヶ月間はAPIチームというチームで働いていたのですが、フォーカスの区切りのタイミングで基盤チームというところを希望し、行かせてもらうことができました。<br>
それぞれのチームでやった仕事について紹介したいと思います。</p>
<h3>APIチームでの仕事</h3>
<p>インターンに参加して初めに与えられたタスクは、KARTEが提供する、開発者向けのAPIを開発するというものです。社員が取り組むような実践的で非常にやりがいのある仕事であると同時に、このタスクに関してはほとんど仕様が決まっていなかったので、僕にとってはチャレンジングな仕事でした。また、Node.js や Mongo DB についても全く経験がなかったため、技術的にも初めての状態でした。<br>
実際に取り組み始めてみると、そもそもKARTEのことをもっと知らないと、仕様を決めることもできないと感じました。以前に参加したインターンでは、仕様が決まったタスクが渡されることがほとんどだったので、そのプロダクトについて詳しくなくても、ある程度はできてしまうものでした。<br>
KARTEについて学ぶには、KARTE Dojo という、わかりやすい動画が用意されています。僕はその動画を見て、KARTEとはどんなもので、どういう機能がよく使われているのかということを理解しました。とは言っても、実際のユーザがどのように使っているか、APIにどのようなニーズがあるかまではわからないので、社員と相談しながら仕様を決めていきました。<br>
結果的に、無事に1つのAPIの実装を終えることができました。</p>
<h3>基盤チームでの仕事</h3>
<p>ちょうどフォーカスの区切りの頃、モノリシックなKARTEのシステムをマイクロサービス化するということを主に行なっているチーム（基盤チーム）があり、僕はとても興味を惹かれたので、9月からは基盤チームにジョインすることになりました。基盤チームでは他にも、開発環境をよくするための取り組みや、既存のサービスのパフォーマンスを改善するための取り組みを色々と行なっています。<br>
僕はチームとしてこのような仕事に打ち込めることが非常に有意義だと思いました。なぜなら、APIの開発をしていた時に、テストの不便さや、開発環境のパフォーマンスの悪さを感じつつも、目の前の仕事を早くこなさなければという気持ちが優先してしまい、具体的な改善作業をするには至らなかったからです。<br>
基盤チームでは、いろいろな事をしましたが、今は主にテストの改善をしています。まずは、不安定なテストを計測する仕組みを導入しました。 具体的には、github に push するたびにCircle CI で実行されるテストの結果を、Google BigQuery に送り、Google Data Portal で可視化しました。この可視化により、e2e（エンドツーエンド）テストの不安定なシナリオを特定できるようになったり、「不安定な気がする」ではなく「何%の確率で落ちているから不安定だ」と数値で示せるようになりました。<br>
また、不安定なテストにはある程度共通の原因があることもわかりました。改善については、テストケースに一つ一つ修正を入れていくというよりかは、今あるテストを壊して、不安定になる原因を排除しつつ作り直すというような方針で進めています。<br>
不安定なテストは開発スピードに大きく影響するため、非常にやりがいがあり責任のある仕事だと感じています。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/23177920-367c-4182-a4ee-8db534cf03f7/photo1.jpg" alt="photo1"></p>
<h1>インターンで感じたこと、学んだこと</h1>
<h3>仕事の進め方について</h3>
<p>インターンでも社員と同様に信頼して仕事を任せてもらえているという実感がありました。<br>
APIチームで開発をしているときに、プレイドで初めての仕事だったため、わからないことはどんどん質問するようにしていました。これまでのインターンやアルバイトなどで、そのように指導されていたからです。とにかく早く成果物を完成させるということに、重きを置きすぎていました。しかし、プレイドで仕事を始めて1〜2週間ほど経った時、メンターから「遠回りしても、自分一人で解ける範囲を増やすためにもっと時間を使って良いよ」という言葉をいただきました。<br>
実際にこのことを意識しながら仕事をしてみると、より解ける範囲が増えていくことに気づきました。問題に直面したとしても、次に何をするべきか考え、手を動かすことができました。<br>
こうして、自分が解ける範囲がどんどん増えて行くことを実感し、仕事が楽しく感じましたし、自信にもなりました。<br>
この時に、メンターが、インターン生が作る成果物だけでなく、インターン生の成長にも大きな価値があるという風に意識しているのだと感じました。</p>
<h3>APIについて</h3>
<p>APIチームでは、仕様を考えていく際に色々なことを学びました。<br>
APIはKARTEでできないことを外でしてもらうためのサービスなので、既存の管理画面からGUIで操作が可能なことを提供しても意味がありません。自分なりに、KARTEのユーザだったらどうするか、ということを意識しました。また、サービスの内部で使っているAPIは、仕様を変更した時の影響範囲が把握できるため、変更が難しくありません。しかし、外部のAPIの場合には多数のユーザがそのAPIをすでに利用している可能性があるため、破壊的な変更をすることが困難になります。そのため、APIにどのような機能を持たせるかは非常に慎重に検討する必要があり、必要最低限の機能を備えるのが良いということを学びました。</p>
<h3>基盤（テスト）について</h3>
<p>基盤チームでは、主にテストの改善をしていて、技術的に学ぶことが非常に多かったです。<br>
テストにも何種類かあり、ユニットテスト、システムテスト、e2eテストなどがあります。僕は初め、e2eテストをたくさん作れば、コスパよく網羅的にシステムのテストができるとなんとなく思っていました。<br>
しかし実際には、e2eテストはもろく、不安定になりやすいもので、テスト対象のシステムのソースコードが同じでも、成功するときもあれば失敗するときもあるといったものでした。そのため、外部の環境になるべく依存しないテストを多く作り、e2eテストはシステムのコアな部分を守る必要最小限のものにするのが理想的であるということを学びました。</p>
<h1>プレイドへの新卒入社を決めた理由</h1>
<p>入社を決めた理由はいくつかありますが、プレイドの文化には特に良い印象を持ちました。<br>
例えばプレイドには「承認より謝罪」という文化があります。<br>
これは、「自分で考えてやるべきと思ったことは、誰かの承認を得なくても、とりあえずやってみて良い」というようなものです。他にも色々な文化があるのですが、多くの文化に共通する考えがあると思っています。それは、「なるべくポジティブに考えたり、人のポジティブな側面を信じる方が、トータルで得られるメリットが大きい」というような考えです。<br>
「承認より謝罪」の文化の話でいうと、承認を得るために余計なことを考える必要がなかったり、失敗したとしてもそこから得られる学びがあって、それと比較したら失敗することによるデメリットは（多くの場合は）小さい、といった考え方になると思います。<br>
実際にプレイドに来て、このような考え方がプラスだと実感できた場面はいくつもありました。APIチームでメンターから「遠回りしても良いよ」という風に言われて実践してみたときもそうでした。このような文化のある会社で働けることは、自分の人生にとってプラスだと思いました。<br>
正直、僕はプレイドから内定をいただいたときに、こんな優秀な人たちの中でやっていけるのだろうかと考えました。僕にはすぐに人と比較してしまったり、自信をなくしてしまったりしてしまう癖がありました。でも、最近はそんなこと考えても時間の無駄だなと思っています。優秀なメンバーと一緒に働けることは自分の成長に大きなプラスになりますし、たまに自信をなくすくらいがちょうど良いと考えています。<br>
入社してからは今以上に多くの困難があると思いますが、成長の機会と捉えて、前向きに働いていきたいと思います。</p>
<h1>最後に</h1>
<p>CX（顧客体験）プラットフォーム「<a href="https://karte.io/">KARTE</a>」を運営するプレイドでは、KARTEを使ってこんなアプリケーションが作りたい！ KARTE自体の開発に興味がある！というエンジニア（インターンも！）を募集しています。<br>
詳しくは<a href="https://meet.plaid.co.jp/">弊社採用ページ</a>または<a href="https://www.wantedly.com/companies/plaid/projects">Wantedly</a>をご覧ください。 もしくはお気軽に、下記の「話を聞きに行きたい」ボタンを押してください！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/76095c7b-50a0-4ae7-af87-8b346f0d0c69/photo2.jpg" alt="photo2"></p>


プレイドのインターンで学んだことと、入社を決めた理由  | PLAID engineer blog

プレイドのインターンで学んだことと、入社を決めた理由

Engineer Blog

Recent Article