はじめに こんにちは。Platform チームの飯迫 ( @minato128 ) です。 2021 年 7 月 1 日に CADDi で初めての Tech 組織横断チームとして、山田( @kei711_ ) と一緒に Platform チームを立ち上げ、約 1 年 3 ヶ月が経過しました。今回は、我々が立ち上げからこれまで取り組んできたことや Platform チームのアップデートなどを紹介したいと思います。 CADDi の Platform チームとは 立ち上げからこれまで 課題と今後 CADDi の Platform チームとは 前提として 前回紹介した組織体制 に大きな変更はありませんが、現在は、各開発チームにひとり以上 Embedded SRE Role をアサインしています。Role の定義は下記のようになっています。 Embedded SRE はシステムの信頼性を高めるために、インフラや非機能要件、可観測性の向上に責任を持つ役割です。 システムの信頼性を高めることで、開発チームのアウトプットの質を高めます。 - 開発チームが非機能要件や可観測性の向上に取り組むことに対して責任を持ちます - システムの信頼性向上に関する課題に率先して取り組みます - 課題解決が困難な場合はプラットフォームチームと共同で問題解決を行います - プラットフォームチームから提供される部門共通のポリシーやガイドラインを理解し、開発チーム内の理解を高めます ※ Embedded SRE が全ての実現に取り組むのではなく、プロダクトの運用責任を持つ 「開発チーム」 で取り組むことが前提です。 ※抽象化した図なのでチーム数やプロダクト数は実際とは異なります 開発チーム それぞれのプロダクトの開発運用に責任をもつ Embedded SRE が、チーム内のプロダクトの Reliability の責務を持つ Embedded SRE は、 Role のひとつであり、専任の SRE ではない Platform チーム 全社共通プロダクトの開発運用に責任をもつ 開発チームと協調して、プロダクトに閉じない課題を解決する CADDi の Platform チームの役割 現時点でのチームの役割は下記のようになっています。また、こちらには記載できませんが、社内向けにはより細かい責務分割ラインを定義して運用しています。 Platform チームの基本的な役割の考え方は、 チームトポロジー の定義と同じです Stream aligned team が自律的に仕事を届けられるようにするのが目的です Platform チームは、開発チームが管理しているプロダクトの Reliability の責務は持ちません Embeded SRE が、プロダクトごとの Reliability の責務を持ち、特定ドメインの運用課題は開発チーム内で解決します Platform チームは、 横断的な技術課題の解決に重点を置いています 課題を解決するためなら、手段は問いません インフラという領域にとらわれず、 既存機能開発や新規アプリケーション開発も必要なら実施します SRE も Software Engineer ですが、Platform チームでは課題解決のためにより深い実装力を求められます 具体的な How のひとつとして、 SRE プラクティスを組織横断で適用する場面は多々あります CADDi のミッションは「モノづくり産業のポテンシャルを解放する」ことです。製造業のバリューチェーンは長く、データだけでなく実際のモノを扱っています。課題を解決するためなら、クラウドインフラだけでなく IoT デバイスやオンプレミスを扱わないといけない場面も出てくるかもしれません。そのあたりも Web 完結型ではない事業をやっている CADDi の Platform エンジニアならではのおもしろさだと考えています。 CADDi の Platform チームの MVV チーム立ち上げ時点 では行動指針を定義していましたが、チームで話し合って決めた MVV はこのようになりました。 Mission 開発組織のポテンシャルを解放する Vision 開発チームが自律的にユーザーへの価値提供に集中できる状態 Value More proactive 不確実性を先回りして解決し、開発体験を最大化する Observability driven 観測可能にしておくことを大前提とし、観測結果にもとづいて施策決定と効果判定を繰り返す Leveraging standardization for further growth 仕組み化でレバレッジを効かせて、よりスケールさせる Learning and Unlearning 必要ならなんでも学ぶ 過去の成功体験、固定観念に縛られない 状況は常に変化するため、再現性があるか、今やることに価値があるかを見極める Have Backbone; Disagree and Commit 信念を持ち、正しいと考えていることを言い続ける 決まったことにはコミットする 立ち上げからこれまで サマリー 時系列でチームの変化の概要をまとめるとこんな感じです。 やってきたことの紹介 すべては書けないのでかなり端折っての紹介になりますが、雰囲気だけでも伝わればと幸いです。 2021/07~09 2 人で課題を洗い出し優先度を決めて進めていましたが、同時に大きな新プロダクトの立ち上げも始まり、なかなか大きなタスクに着手できず、とにかく手が足りないという状況でした。最初にチームの方向性をしっかり定義・認識合わせできていたことは今振り返ってもよかったと感じています。 チームとして 目的を整理して社内に共有 今後スケールしていくための言語化 優先順位を下げていた目前の課題に着手 各種申請フロー整備 共通で管理したほうがよいものを巻取り ArgoCD への CD 移行 新しいプロダクトでうまくいっていたので、既存プロダクトに横展開 コスト管理 GCP など 社内ドキュメントサーバー構築、標準化 チーム/プロダクト間で API 連携が増えてきていたため CADDi DRAWER の立ち上げ インフラ構築 ISMS 対応 2021/10~12 Tech 組織の大幅なスケールに備え、開発に必要なツールやクラウドインフラ・セキュリティのガイドラインを明文化しました。また、それまで性善説で運用されていた開発者の Google Cloud IAM を見直し、あるべき姿を設計・移行しました。 標準化、ドキュメント整備 開発に使うツールや運用資料を明文化、Indexing Google Cloud の運用ガイドライン整備 開発者の Google Cloud IAM 移行 セキュリティガイドラインの定義 インシデント対応フロー整備 その他 社内向けプロダクト用 GKE のキャパシティ見直し Redash を SaaS から Self-Host へ移行 認可基盤の管理画面構築 2022/01~03 Tech 組織や新規プロダクトがさらに増え、積み上げてきた Platform の運用コストも上がってきていたので、再度チーム内で取り組み方について話し合い明文化しました。また、AI Lab 発案で Embedded SRE Role の運用が始まりました。定例会では、Platform チームから Embedded SRE にナレッジシェアをしたり、Embedded SRE に Platform チームの施策をレビューしてもらったり、Embedded SRE から Platform チームに開発チーム内の課題共有をすることで、より全体最適化を進めやすくなりました。 標準化、ドキュメント整備 すべての Terraform Version を Upgrade し、 tflint / tfsec / tfcmt を導入 Terraform や Provider の最新に追従できるようになり、定期的に最新化を実施 Production Readiness Checklist を整備 Embedded SRE Role の誕生 各開発チームにひとり以上アサイン 隔週で Embedded SRE 定例を実施し、施策や課題の共有 Platform チーム内運用のルール化 Platform チームへの相談依頼を日次当番化 新規プロダクトが多く、レビュー・壁打ちが多かったため 相談依頼によるコンテクストスイッチでベロシティが下がっていた 通常タスクと運用タスクの割合を 8:2 とすることを明文化 運用タスクが劣後しがちになっていた CADDi DRAWER 一部機能の設計・実装・運用整備 2022/04~06 人数が 6 人に増えチーム運営が安定してきたので、これまでよりも大きな技術的投資ができるようになりました。また、メンバーの多様性が増したことで、技術的課題を解くための How もさらに広がってきました。 技術的投資 社外向けプロダクト用 GKE への ServiceMesh/OpenTelemetry 導入 Sentry の運用設計と展開 プロダクトの安定運用のための土台作り SLI/SLO の導入 監視基盤のベストプラクティス明文化と啓蒙 Log Format, Tracing, バックアップ方式の標準化 2022/07~10 引き続き技術的投資や標準化を推進しつつ、中期的に今後どうなっていくべきかを自分たちで定義しました。 チーム 中期チーム構成や施策の検討 技術的投資 新認証認可基盤の設計 社内向けプロダクト用 GKE への ServiceMesh/OpenTelemetry 導入 標準化、自動化 全 SaaS 開発者アカウントの IaC 化・自動化 Google Cloud サービスアカウントの IAM Policy 標準化 Google Cloud への一時的な権限付与のためのアプリケーション構築 常にやっていること 構築した（提供中の）プラットフォームの運用 ドキュメント 標準化、運用ガイドラインなど ミドルウェアやツールのアップグレード(Renovate) ArgoCD, ESO, Datadog, ASM など 提供しているインフラやアプリケーション、SaaS、共通モジュール チーム内の働き方の明文化やそのブラッシュアップ Working Agreement オンボーディング資料 運用系の定期イベント CADDi DRAWER の支援 非機能要件や技術的な支援 将来的には開発チーム内で完結する想定だが、事業優先度が高いかつ人が足りていないため 課題と今後 現状の課題 現状このような課題があります。 Platform チームでカバーしている範囲が広いため、認知負荷がそれなりに高い 求められるスキルの範囲もそれなりに広い 強制力がない標準化施策に関しては、開発チームへの導入速度は緩やか Embedded SRE Role を持つ人も開発チームメンバーも基本的に協力的なので徐々には浸透している 専任で取り組む人はいないため、スピードは出ない これらを解決するため、また、中期チーム構成の過程として、次の四半期から Platform チームを分割し、Enabling と Platform の 2 つのチーム体制にする予定です。 Enabling チームは、 チームトポロジー の定義通り、特定のテクニカルドメインスペシャリストで構成され、複数の Stream aligned team の能力ギャップを埋めるのを助けます Enabling チームは、開発チームへの標準化施策の導入責務を持ち、その速度を加速させます 現在の Platform チームは、課題の解決に重点を置いているため、場合によっては開発チームへの標準化施策の導入サポートを行っていますが、それをスコープアウトします 分割後の Platform チームは、開発チームへの標準化施策の導入サポートを Enabling チームに任せることで、高度化や技術的投資に集中します 3 年後の妄想 現在、開発組織は約 70 名に対して、Platform チームは 6 名です。3 年後、開発組織が今の何倍になっていたとしても Platform チームの人数比率的には今と同じくらいが（個人的には）理想だと考えています。ただし、その過程ではもっと人を増やして、よりレバレッジの効く施策を積み上げていくことが前提です。そして最終的には、Platform チームから開発チームへ Embedded SRE や開発メンバーとして異動して、また必要最低限の人数でさらに成長して増えたプロダクト群を Platform で支えていくことができればよいと思います。同じことばかりやっていると飽きてしまうし、成長機会も減ってしまうので、本人の Will が一致すれば、再び Platform チームにも戻れたり、全く違う目的をもった新しいチームを作ったりできるとより楽しそうです。 3 年後の Platform チームは、Platform グループになり、仮に 30 名だったとしましょう。グループの中には、複数のチームが存在し、チームのミッションもそれぞれ異なります。役割もチームごとに分割され、認知負荷が減り、特定分野に特化したスペシャリストも活躍しやすくなっています。モノを扱いやすくするための IoT デバイスや物流拠点で利用するオンプレミスのシステムが必要になっていて、それを設計したり維持管理したりするチームもあるかもしれません。グループ全体では、より安定的で強固な Platform を提供しながら、さらに大きな課題や技術投資にチャレンジします。 また、現在の CADDi では組織拡大だけでなくグローバル化も進んでいます。開発組織向けの資料は、すでに英語を併記し始めていますが、まだ Platform チームに英語話者はいません。3 年以内なのか以降なのかはわかりませんが、Platform チームも英語話者を受け入れていくことになるでしょう。英語話者だけのチームやタイムゾーンの異なる国外のチームとも一緒に働くことになり、コミュニケーションの課題が全くなくなるということはないかもしれませんが、対チームや対開発組織でのプロセスは型化され、大きな問題はなく業務が遂行できるようになっていることでしょう。 この妄想を現実に変えるために、例えばこんな人に来てほしいです。 会社のグローバル化とともに、徐々に英語を習得しながら働きたい人 プロダクトの Platform を支え、技術的課題を解決し続けることで大きなミッションを達成したい人 人や組織面を中心にグループを支える Engineering Manager 一緒に未来を描ける Technical Product Manager ソフトウェア開発ライフサイクルを改善し続けて、グループのアウトカムを最大化できる Scrum Master より強固な Platform を設計したい Security Engineer より安定的な Platform を設計したい Site Reliability Engineer 標準化や自動化や高度化が好きな Cloud Platform Engineer 手段にこだわらないが軸がぶれない Software Architect 認証認可基盤などの組織横断プロダクトを開発したい Software Engineer おわりに 最後まで読んでいただきありがとうございました。少しでも CADDi の Platform チームが、どんなチームで何をやってきたか伝わっていたら嬉しいです。もし興味を持っていただけたら、気軽にお声がけいただければと思います！ CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひ こちら より面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについてはSNSで随時発信しておりますので、 Twitter のフォローや、 connpass のメンバー登録をぜひよろしくお願いします。

OpenSearch で実現する画像検索とテスト追加で目指す安定運用 こんにちは、CADDi AI Lab MLEの志水です。 8/19に10X,M3の両社と検索運用の勉強会 #Search_C10Xm3 を開催いたしました。 おかげさまで当日までの 登録者が254名 、当日の参加者は最大137名までお越しいただき大盛況でした。 勉強会中何度か紹介された ペンギン本 が Amazonで売り切れる ような反響もあったようです。 その中から、 キャディ発表分 を抜粋したイベントレポートをいたします！ - 10Xさんの発表資料はこちらから - M3さんの発表資料はこちらから AI Labでは図面管理 SaaS CADDi DRAWER の検索サービスを開発／運用してきており、その経験から OpenSearch で実現する画像検索とテスト追加で目指す安定運用についてお話ししました。 目次 opensearch で knn を用いた画像検索 前半では、 OpenSearch でkNNを用いた画像検索がなぜ必要だったかと、それを実現した方法について説明していきます。 CADDi DRAWER CADDi DRAWER は今年7月にリリースした図面管理 SaaS です。 AI Labではこの中で類似画面の検索に用いられている 検索エンジン を開発しています。 サービスの詳細や開発に至った経緯については リリース時のブログ や Tech Lead や PDM によるイベントレポート をご覧ください。 図面って何？ 図面は製造業において作る対象のレシピのようなものです。 図面内の情報の読み取りは、 アルゴリズム 、 OCR 、オペレーションの合わせ技になっています。 特に右下の枠内のテーブル情報には、図面のkeyとなる図番や部品名などが入っており、読み取ることがかなり重要です。 図面にまつわる pain なぜあえてこれを管理する SaaS を作る必要があるか、そこには図面特有のペインや辛さがあるからです。 業務都合上、縮尺違いや勝手違い（左右反転）した図面を扱うことは多く、「この形に似た図面を探したい」と思う場面が多くあります。そのため図面内の情報の検索や形状をベースにした類似が求められますが、ここにもう１つ難しさがあります。 図面は元々は設計の部署でCADなどで書かれますが、部署を跨いだり（設計→調達）会社を跨いだり（発注会社→加工会社) するときにPDFに変換されます。なので多くの情報をPDFから読み取ることも必要になります。 検索システムの アーキテクチャ 一般的な検索システム ペンギン本 の説明が的をえていてとてもおすすめの本です。 こちらの17ページから引用したもので、一般的な検索システムの構成としてUIと 検索エンジン の間にあるクエリプロセッサが検索のやりとりを行い、ドキュメントDBとインデクサが 検索エンジン へのデータの挿入を行っていることがわかります。 DRAWER の検索システム (Kaleido) DRAWERの検索システム (Kaleido) も同じような構成になっています。 UIがクエリを発行し、 Python で書かれたクエリ プリプロセッサ が OpenSearch が理解できる形にクエリを変換し、検索します。 検索結果を Python のクエリポストプロセッサがフロントエンドが理解できる形に変換して返します。 データのインデックスに関しては、図面に紐づく メタデータ 等は直接 OpenSearch にインデックスされます。 画像特徴のベクトルは、PyTorchのモデルを通して計算され、 OpenSearch にインデキシングされます。 DRAWER チームと AI Lab チームの 責任分界点 DRAWERチーム フロントエンド、バックエンド、インフラ含めた全体を開発／運用している 検索システムの中ではUI、データ、インデクサの部分 AI Lab AI LabはKaleidoという水色の部分を開発／運用している Query Processor OpenSearch PyTorchのモデル Kaleidoとの接点は API コールで行われる /search : 検索 /preprocess : 図面の素材等のデータのインデキシング /feature_extract_and_save : Deepモデルへの推論と、 OpenSearch へのインデクシング OpenSearch ではこの 検索エンジン の OpenSearch について少し説明していきます。 OpenSearch とは OpenSearch はElasticsearchからforkしたプロジェクトです。 詳細はリンク先に譲りますが、ライセンス戦略等に発した AWS とElastic社の仲違いから発生したものです。 https://www.elastic.co/blog/why-license-change-aws So why the change? AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will? https://aws.amazon.com/OpenSearch-service/the-elk-stack/what-is-OpenSearch/ On January 21, 2021, Elastic NV announced that they would change their software licensing strategy not release new versions of Elasticsearch and Kibana under the permissive Apache License, Version 2.0 (ALv2). https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/ Choosing to fork a project is not a decision to be taken lightly, but can be the right path forward when the needs of a community diverge—as they have here. https://www.elastic.co/blog/elastic-and-amazon-reach-agreement-on-trademark-infringement-lawsuit We’re pleased to share that Elastic and Amazon have resolved the trademark infringement lawsuit related to the term Elasticsearch. Tipsとして、 OpenSearch はElasticsearchに比べて歴史が浅いため検索でヒットしずらいです. エラーメッセージ等もElasticsearchで検索し、その結果をそのまま OpenSearch に適用することが多いです。 なぜ OpenSearch を採用したか 技術選定時点(2021年)ではkNN+filterを実現できる、ANNが使える、ということから OpenSearch を採用しました。 ANNの アルゴリズム の１つである HNSWの解説動画 は面白くておすすめです 現在ではどちらもElasticsearchに導入されているため、今から画像検索を始める場合はElasticsearchでも十分可能です！ OpenSearch の運用 当初はmanagedを採用せず、現在は k8s 上で運用していますが、少しずつつらみも出てきているため、ElasticCloud on GCP をはじめとしてmanagedの採用も検討しています。 モデル 画像検索が可能なのは、 Deep Learning モデルが優秀な特徴量を作成してくれるからです。 モデルの詳細については 竹原さんの発表 をご参照ください 1280次元の特徴量を使っていますが、現実的な時間内で検索が可能です テスト追加で目指す安定運用 後半では開発した検索システムを安定して運用するために、どのようにテストを追加したかや、監視の具体について説明していきます。 全体像 CI/CD内でカバーするunit test、Integration Testの話と、アプリケーションがデプロイされた後のUIテストや監視の全てが大事な要素です。 unit test Functionやモジュールごとのテストのをするのがunit testになります。 類似検索パッケージの中ではcode coverageは100％近くあり、PRのたびにテストがあるかを互いにチェックしています。 工夫ポイント クエリプロセッサは複雑なので、複数パターンの入力→複数パターンの出力をテストしています Deep推論部分は変数が多いため、Configをクラス化するなど型づけを厳密にしています endpointはOpenSearchClientを使っているので、テストではclientをmockしています # PostProcessor コードの一部 class PostProcessor: """map the opensearch results to format in kvs (snake_case to camelCase) """ @staticmethod @postprocessor_exception def search_postprocess(hits) -> list[SearchOut]: def _reformat(data) -> SearchOut: return SearchOut( id=data["_source"]["source_id"], score=data["_score"], index=data["_index"], foo=data["_source"]["foo"], bar=data["_source"]["bar"], ) return [_reformat(x) for x in hits] # PostProcessorのテストコードの一部 class TestPostprocessor(unittest.TestCase): def test_search_postprocess(self): hits = [ { "_score": 0.1, "_index": "index_1", "_source": { "source_id": "id_1", "foo": "foo_1", "bar": "bar_1", }, } ] expected = [ SearchOut( id="id_1", score=0.1, index="index_1", foo="foo_1", bar="bar_1", ) ] actual = PostProcessor.search_postprocess(hits) self.assertEqual(expected, actual) Integration test unit testだけではカバーしきれない部分はIntegration testを書いていきます。(実際に OpenSearch と通信する部分など) CI上ではdocker-compose.ymlを用いて検索の API と OpenSearch を起動しています。 # docker-compose.yml services: opensearch: build: context: ./ dockerfile: ./docker/OpensearchForLocalDockerfile ports: - ... api: build: context: ./ dockerfile: ./docker/ApiDockerfile ports: - ... batch: build: context: ./ dockerfile: ./docker/BatchDockerfile Makefile にテストコマンドを用意することで、ローカルでもCI上でもテストをキックしやすくしています。 # Makefile ## run test search test-search: docker compose -f ../docker-compose.yml exec batch poetry run python -m src.pipeline.test_search_pipeline IO indexの作成→データ挿入→検索までをintegration testを書くことで、DRAWERという外部サービスに対してのcontractに なっています コード例 データ挿入 from itertools import cycle, islice def post_bulk_preprocess_endpoint(data_length=10, index="example-tenant"): """apiのbulk preprocess endpointに対しsampleデータが投入出来ることを確認する""" # create test data foos = list(islice(cycle(['foo_1', 'foo_2']), data_length)) bars = list(islice(cycle(['bar_1', 'bar_2', 'bar_3']), data_length)) data = [] for i in range(data_length): data.append( { "id": f"{index}-{i}", "index": index, "foo": foos[i], "bar": bars[i], } ) response = requests.post("http://api:80/preprocess/bulk", data=json.dumps(data)) response = response.json() assert response["message"] == "success bulk index", f"{response}" assert response["indexedDataCount"] == data_length, f"{response}" assert response["data"]["bulk_count"] == 1, f"{response}" requests.get("http://opensearch:9200/_refresh") logger.info("bulk preprocess endpoint [OK]") 検索して結果を確認する def _post_can_find(source_id: str, index: str, polling_time: int, sleep_time: int): # filter is successful in finding the correct item data = { "source_id": source_id, "index": index, "limit": 2, "filters": [{"field": "foo", "boolean_operator": "AND", "keywords": ["1"]}], } response = post_with_timeout( "http://api:80/search", data=json.dumps(data), timeout=polling_time, sleep_time=sleep_time ).json() assert type(response) == list, f"{response}" assert len(response) > 0 actual = {res["foo"] for res in response} expected = {"foo_1"} assert actual == expected, f"{expected=}, {actual=}" snapshot 上記のテストだけでは意図せず壊すことがあります。暫定的な対応をした後に、今後同じようなミスを起こさないように対策をします。 この例では、 dict の要素に対して [] でアクセスしたため、データ マイグレーション をしていなかった環境では検索が落ちました. 暫定対応ののち、再発防止のためにSnapshotをとっておき、Snapshotで検索ができることをCIで保証しました。 コード例 snapshotを復元する def restore_opensearch_snapshot(): """opensearchのsnapshotからデータを復元する""" # add settings headers = {"content-type": "application/json"} data = {"type": "fs", "settings": {"location": "/snapshot"}} requests.put("http://opensearch:9200/_snapshot/snapshot", data=json.dumps(data), headers=headers) # restore index "snapshot", version "1" response = requests.post("http://opensearch:9200/_snapshot/snapshot/1/_restore") logger.info(f"restore snapshot: {response.json()}") response = requests.get("http://opensearch:9200/snapshot-tenant/_refresh") logger.info(f"refresh: {response.json()}") logger.info("restore opensearch snapshot [OK]") 検索が動くことを保証する def post_search_with_snapshot(polling_time: int, sleep_time: int): """ index mappingsが変更された場合等、text diffでは確認出来ない破壊的変更のための回帰テスト """ index = "snapshot-tenant" source_id = "snapshot-0" data = {"source_id": source_id, "index": index, "limit": 1} response = post_with_timeout( "http://api:80/search", data=json.dumps(data), timeout=polling_time, sleep_time=sleep_time ).json() assert type(response) == list, f"{response}" assert len(response) == 1, f"{response}" assert response[0]["source_id"] == "snapshot-1", f"{response}" assert response[0]["score"] > 0.0, f"{response}" logger.info(f"search snapshot tenant={tenant}, item_id={item_id} [OK]") checkerboard features - UIテストでのバグ発生から、テストを追加して再発を防止した例です - kNN search + filterのあと、kNNの結果が反映されていないとUIテストからフィードバックがありました - 事象が判明した時点でPdMから全体に周知されています - 正しくは score=replace をクエリに追加する必要がありました - 直した後、ポストモーテムで全員に根本原因と対策が記録、周知されます - テストデータのkNNベクトルを乱数ではなく、検索の結果に意味があるものに変更してテスト可能にしました コード例 checkerboard（互い違い）の特徴量を作成する def checkerboard_array(i: int, length: int = 1280) -> list[float]: """A checkerboard feature to test similarities e.g., 0: 0, 1, 0, 1, ... 1: 1, 0, 1, 0, ... 2: 0, 1, 0, 1, ... Args: i: the index of the data length: length of the feature Returns: a list of `length` floats """ np.random.seed(i) a = np.random.normal(loc=0.9, size=length) a = np.clip(a, 0.5, 1) b = np.zeros(length) # [num, 0, num, ...] for even, [0, num, 0, ...] for odd if i % 2 == 0: ab = (a, b) else: ab = (b, a) c = [] for element in zip(*ab): c.extend(element) c = c[0:length] return c 奇数番目のデータは奇数番目のデータが類似することを確認し( odd_comes_first ),かつfilterが機能していることを確認する def _find_one_on_amount(data_length: int, index: str, polling_time: int, sleep_time: int): data = { "source_id": f"{index}-3", "index": index, "limit": data_length, "filters": [{"field": "bar", "value": "3"}], } response = post_with_timeout( "http://api:80/search", data=json.dumps(data), timeout=polling_time, sleep_time=sleep_time ).json() assert type(response) == list, f"{type(response)=}" assert len(response) > 0, f"{len(response)=}" assert {r['bar'] for r in response} == {"bar_3"} # check that even comes first (because of checkerboard features) assert odd_comes_first(response) def odd_comes_first(response) -> bool: ids = [int(r["id"].split("-")[-1]) for r in response] # [2, 4, 6, 3, 1, ...] still_true = True for num in ids: if num % 2 == 1: if still_true: continue else: return False else: still_true = False continue return True pruning tests 基本的にテストはどんどん増えていきます 不要なテストを削除したり、依存するものを解消したりすることも時に必要です(diffが大きくなりますが！　) 適切なものに絞ることで開発者経験をよく保ちます 監視 上記のようにテストを追加していても、UIテストでバグが発覚したりアプリケーション上ではエラーが起きたりします。 監視をして、適切に対応したりチーム全体にアラートしたりすることが重要です。 KaleidoではDatadogにログをためて、 ダッシュ ボードでレスポンスタイムやリク エス ト数を見ています. またエラーはSentryで記録していて、監視用のSlackチャネル( #tech-kaleido-alerts )に通知来るようにしています。 エラーが上がったら開発しているチームで障害対応をしています。 精度問題 精度問題は必ずどこかで出てきます 仕組みで対応するために、改善要望リストを作成し、 定量 評価デー タセット を用意しています Kaleidoでは 定量 評価デー タセット をPdM2名MLE2名で作成しています 運用の移譲 - DRAWERもリリースし顧客からの改善要望が増えるにつれ、AI LabではなくDRAWERチームで運用できる体制に移行しようとしています - 運用の移譲のために、技術の整理やロードマップの整理をしています もっと他のお話が聞きたい方へ 9/15にAI Labの中村さんがMLOpsのお話をしてくれます！　(Datadogの運用やSLOの設定をしてくれたのは中村さんでした。) CADDi Tech Chat 〜MLOpsエンジニアの働き方紹介〜 中村さんは最近はMLモデルをデプロイするための基盤を作ってくれていたり、MLモデルのデモの基盤を作ってくれていたりと、MLエンジニアがより成果を出しやすくするための取り組みを色々やってくれています。面白い話になると思いますのでみなさんぜひ！ We are hiring! キャディでは一緒に働いてくれる 仲間を募集 しています。 最近のAI Labでは2D/3Dのデータに対するモデルや、 API 基盤を作ったり、デモ基盤を作ったり、 アノテーション 基盤を作ったり、モデルだけでなくそれらの周辺技術を自分達で整備していく仕事もしています。 今後もDRAWERの進化のための機能開発や、より広く製造業全体の進化のための製造拠点のデータを活用したプロダクトなどを作っていきたいと思っています。 AI Labやキャディでの仕事に少しでも興味をもたれた場合は、ぜひ面接や カジュアル面談 を申し込んでいただければ幸いです。 また、 Tech Blogや勉強会等のイベントについては SNS で随時発信しておりますので、 Twitter のフォローや connpass のメンバー登録をぜひよろしくお願いします。

はじめに 河合セッション AIプロジェクトでありがちな技術的負債負債 CADDi AI Labにおける技術的負債 CADDi AI Labにおける対策 パネルディスカッション おわりに はじめに こんにちは、最近オーディオミキサーを買い換えたら「リモート MTG の音質が良くなった」と褒められ MTG したがりなAI Labの河合です。 先日、YUMEMI様が主催するSELECK LIVE!にて、「スタートアップと技術的負債」というイベントに登壇させて頂きました。 登壇者は、株式会社カミナシCTOのトリさん（ @toricls ）、atama plus株式会社の深澤さん( @qluto )。 モデレータは、株式会社ゆめみ取締役の工藤元気さん（ @Genki910biz ）でした。 非常に豪華なメンバーでエンジニアリングにおける負債と事業についてディスカッションする事ができました。ありがたい限りです。 本記事は、イベントの中でCADDiから発表した内容を補足しつつ、パネルディスカッションを振り返る形で、イベントレポートとさせて頂ければと思います。 イベントURL： https://yumemi.connpass.com/event/255925/ 河合セッション 他2人の登壇者のテーマと少し違いを出すため、私のセッションでは主に「 機械学習 」をテーマにした技術的負債のお話をしました。 AIプロジェクトでありがちな技術的負債 そもそも、AI、 機械学習 の分野には「 機械学習 は高利のクレジットカードである」という言説があります。 これは、2014年のNIPS(現在のNeuralIPS、 機械学習 業界における著名な学会)にて Google より発表された論文から来ています。 タイトルはそのまま『Machine Learning: The High-Interest Credit Card of Technical Debt(*1)』です。 2022年においても、 機械学習 や統計モデルの技術活用はさらに進む裏側で激しい技術的負債化と戦っているのがAI業界であるとも言えます。 私のセッションの入りとして、私がよくあると感じる 機械学習 の負債についていくつか例をお話しました。 時間が経つと再現不可能になるモデル、データ、バージョン管理 機械学習 のライブラリは扱っている問題が複雑故にwrapにwrapを重ね難度化しています 機械学習 モデルの進捗も早く、画像認識分野などでは1年前のモデルは古いと言われたりします "厳密"にあらゆるバージョンを管理する事が本来求められますが、非常に早い業界スピードの中では劣後されがちです モデル推論、学習に関連するテストコードが書きにくい事をいいことに前処理や API 実装に書かれないテスト 複数の機能がwrapされた便利な 機械学習 ライブラリを使う事が多い反面、method単位のtestが書きにくくなっています そういった背景から、モデルの周辺コードのテストがサボられるケースがあります テストのないコードはそれだけで負債と言えます データドリフトが考慮されない、監視されないデータ分布 機械学習 プロジェクトの最も難しい点の1つに、入力データの分布への対応があります 分かりやすくTo Cで言えば、数ヶ月前とユーザの購買行動が変わってしまうシーン等がそれに当たります これらに対応するには本来分布を監視すべきなのですが、一定以上のシステムが必要故劣後されがちです 最初は精度が良いモデルでも半年後に負債となって襲いかかってくる事がよくあります PDCA を回さない プロダクトマネジメント から来る長期間のメンテナンス放置 機械学習 モデルの良い点として、データを集めて再学習する事で精度を上げられる点があります PdMが 機械学習 に疎い場合など、より目先の別の価値のために PDCA を放置される事があります 固く成果が出せる部分でもありますし、先のデータ分布の変化にも対応出来るので本来は進んでやるべきです トリさん、深澤さんが、より広い技術的負債のお話をしてくれると考え、AI文脈に絞っています。そうあって欲しくないのですが、結構身近なあるあるの課題です。 *1 At: SE4ML: Software Engineering for Machine Learning (NIPS 2014 Workshop) D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young (Google, Inc) https://research.google/pubs/pub43146/ CADDi AI Labにおける技術的負債 CADDi AI Labは、昨年12月に設立し9ヶ月のチームですが、素早い開発速度を求める反面でいくつかの負債も抱えています。 これらは、「プロダクトの変化」や「データ分布の変化」に 機械学習 のシステムが追従出来なかった結果として起こった後発的な負債と言えます。 イベント中、トリさんが良い事を仰っていたのですが、「プロダクトに導入された技術は時間と共に必ず負債化」します。 機械学習 は効力も大きい分、その反動も多くなるので時間の経過を考慮した開発が必要になってくるなと私も痛感しています。 スライドにもある通り、技術的負債はまさに「負債」です。 ネガティブな印象はなく、金銭感覚があれば借りても良いし返却もできます。 本質的には、負債額の把握、返却への 皮算用 、未来に向けた負債対策、返却の体制作りなどの継続が大事になると認識しています。 CADDi AI Labにおける対策 CADDi AI Labでは、技術的な負債を借りるため、後々負債にならないよう、いくつかの施策を打っています。 小チーム制とチーム内PdM、Tech Lead PJが大きくなり人が増えれば複雑性が増し負債が発生する可能性は高まるのでチームは小さく保っています 小チーム内の事はメンバー同士の手が届く状態にしています チーム間での「負債を許容するか」「返却するか」はTech PdM / Tech Leadが判断しています 判断にはビジネス上の意義や他チームの状態など様々な要因が絡むためです ドキュメントの記載 機械学習 エンジニアもDesign Docや実験ドキュメント、Model Cardを書いています Design Docには以下の内容を必ず記載しています Goals Non-goals User Stories Success Metrics Biggest Hypothesis Functional Requirements Results 実験ドキュメントは GitHub 上で管理し、lexicoを使って社内から閲覧できる状態にしています lexicoは全社共通のドキュメントサーバとして利用しており Google アカウントによる認証が付いています 基本的にフリーフォーマットですが実験を他者に引き継げる状態を期待しています Model Cardはproductionにdeployされるモデルについて以下のような内容を必ず記載しています 概要 開発者 入力 出力 学習デー タセット 、方法 評価方法、評価結果 想定 ユースケース 性能に関する要素 これらはレビューにより負債化を防止したりもしています プロジェクトが進んでも方向がブレにくくなるだけでなく、チームとして技術的負債をそもそも生みにくくする体制、知識共有の役割を果たしています Working Agreement ローカル実験から本番まで「成果」となるラインをAgreementとして共有 Test群においてもチーム内で定義 必須の項目は「時間を掛けてやる」ことを明言しています イベント内では実際のWorking Agreementの スクリーンショット 等も共有してます。 「バージョン管理の行われていない」「Productionに出るにも関わらずTestのない」状態は成果と呼ばない事を明言しています。 また、それらを守るために「改修を2回劣後させたら報告すること」をルールとし、時間を作る事もWorking Agreementの取り組みの一環として実施しています。 イベント中には言っていませんでしたが、今もまさにWorking Agreement追従のためにスプリントを丸々使って改修を行っているメンバーが居ます。 パネルディスカッション イベント後半では、登壇者によるパネルディスカッションを実施しました。 ビジネス職であるCEO等に技術的負債の返却をどう説明するかという議論から始まり、事業貢献として金額に換算する話や良いエンジニアを採用し確保し続けるために必要であるという話をしました。 トリさんから「（立場上言いづらいと明言した上で）やっぱり汚い環境で仕事したくないじゃないですか」といった本音 トーク も出てきて、非常にエモーショナルな会になったなと思います。 私も基本的には「事業が成功するために技術的な負債を借りるべき」と考えていますが、それによって起こるやり辛い環境を解消したいというエンジニアの性のような部分も大事にすべきだといつも思っています。 また、「ドキュメント化は一種の筋力」という言葉も非常に刺さりました。 CADDiにおいてもまだまだ未熟ではありますが、未来の技術的負債を減らすためにベースを強くしていきたい所です。 既にある技術的負債の解消を進める取り組みとして、CADDi AI Labが実施しているSmall Winシートも共有しました。 技術的負債というものは、返しても目先は事業的には前に進んでいないため会社から評価されにくいものですが、技術者からは確実に大きく評価される事だと思いますし、その事を忘れずしっかり評価者に伝えるためにもお互い書くようにしています。 こういった仕事の評価をどう上げていくか、登壇者皆さん頭を回している事が良く分かり非常に良いディスカッションとなりました。 おわりに 本記事では、「スタートアップと技術的負債」というイベントのレポートとその補足を行いました。 ここまでお読みいただきありがとうございました。 CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひ こちら より面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについては SNS で随時発信しておりますので、 Twitter のフォローや、 connpass のメンバー登録をぜひよろしくお願いします。

こんにちは。 Platformチームの前多( @kencharos )です。 2022年8月9日に開催した社内勉強会で、eBPFベースのネットワークミドルウェア、 Cilium(スリィアム) について発表しました。 この記事は発表の内容をベースに内容を補足したものです。 この記事を読むにあたり、Kubernetesをある程度触ったことがないと用語などが分かりづらいかもしれません。 サービスメッシュや Istio については、構成や導入目的について簡単に次節に記載しています。 より詳しく知りたい方は Istioのサービスメッシュの説明 を見てもらえると、Ciliumとの対比がわかりやすくなるでしょう。 またサービスメッシュを触ったことがある、あるいは運用している方であれば、Ciliumの魅力がより伝わると思います。 eBPFの知識は必要ありません。またeBPFについて同僚も社内勉強会で発表していますので、eBPFについて詳しく知りたい方は以下の記事を見てください。 eBPFに3日で入門した話 はじめに 私はこれまでに3度サービスメッシュをプロダクトに導入した経験があります。 サービスメッシュを導入する目的はプロダクトに応じて様々ですが、私の中では観測性(Observability)を基盤側で提供することを主な目的としています。 例えば、Kubernetesクラスタにサービスメッシュを導入すると、クラスタ内の各PodのHTTPレベルのメトリクスやアクセスログの取得をアプリケーションの改修なしで実現できます。 GCPのCloud RunやApp EngineといったPaaSでも自分でデプロイしたアプリケーションの外側で、アクセスログやメトリクスの取得ができ、ダッシュボードなどの可視化の仕組みが提供されています。 それと同様の仕組みをKubernetesでもサービスメッシュを用いて実現できます。 こういった機能は従来のサービスメッシュでは各アプリケーションにプロキシとして挿入されるサイドカーと、サイドカーの管理を行うコントロールプレーンといったコンポーネントで実現されるのが普通です。 代表的なものが Istio ですね。また、サイドカーとして挿入されるプロキシは Envoy が使われることが大半です。 実際私がこれまでに携わってた3度の経験でも、全て同様の構成でした。 サイドカーによるサービスメッシュは強力な方法ではあるものの、やはり結構複雑です。 透過的にサイドカーが挿入されるのはソースコードを変えることなく導入できて便利ですが、一方でその原理を理解しておかないと、なんとなく不安に思われたり通信障害の原因として真っ先に疑われがちだったりします。 また、サービスメッシュを導入しない場合と比較してパフォーマンスへの影響も気になるところですが、それはアプリケーションの性能要件と比較して妥協可能かどうかを判断すると良いでしょう。よほどクリティカルな状況でなければ問題になるほどの影響はないはずです。 といったようなサービスメッシュ導入あるあるをこなしていた時に、たまたま Cilium のことを見かけました。 eBPFがベースのネットワークライブラリであり、2022年8月時点の最新版の 1.12 では サイドカーフリーのサービスメッシュ機能がGAになったとの内容 を見て、Istioなどと比較してどこまでの機能が実現できるのかがとても気になりました。 なお、私は eBPFやネットワークレイヤーに関する知識はあまりありません。そのため知識不足により見当違いのことを書いている場合があるかもしれませんので、その場合はコメントいただけると幸いです。 Ciliumとは Cilium は主にIsovalent社によってメンテナンスされているOSSのネットワークライブラリです。 OSSとして無償利用するほか、同社による有償サポートもあります。 Ciliumの主な機能は、eBPFを使用してカーネル内で行われるパケット処理に観測性・セキュリティ・高度な通信制御を付与することです。 オンプレミスやDockerネットワークに対して動かすことも可能なようですが、主な対象はKubernetesだと思います。 KubernetesにCiliumを導入すると、透過的にPod間の通信制御やHTTPメトリクスの取得といったサービスメッシュで実現してきた機能の一部がCiliumで実現できます。 また、Ingress Controllerも1.12から実装されました。 eBPFでKubernetesのネットワーク課題を解決する Kubernetes ネットワークの課題とeBPFによる解消方法を簡単にまとめます。 KubernetesのPodネットワークの制御は主にiptableによって行われていますが、iptableはL3/L4に対するネットワーク制御のツールであり、多数のプロセスが動的・短期的にIP・Portを変えていくような Podネットワークでは大量のルール変更が必要で、そのオーバヘッドはPodが増えるほど無視できないものになります。 eBPFによりiptableを置換し、より効率的なパケット処理であったり、ユーザ空間からKubernetesのPodの情報を持ち込むことで、IP・PortしかないパケットにどのPod宛の通信であるかやL7レベルの情報を与えることができ、観測性の付与やセキュリティの向上を果たすことができます。 今回はCiliumを実際に試すことが目標だったので、あまり深掘りはできていません。より詳細な内容は 以下の資料を見ていただくのが良いでしょう。 CNI Benchmark: Understanding Cilium Network Performance Replacing iptables with eBPF in Kubernetes with Cilium Ciliumをインストールする さて実際にCiliumをインストールして動作を試していきます。 Ciliumのinstall手順 によれば、主要なパブリッククラウドのKubernetesサービスのほか、ローカルの環境でも試すことができます。 今回私がCiliumを試した環境は以下の通りです。 Cilium 1.12 Minikube 1.26.0 on M1 macbook pro Ciliumのコンポーネントの概要は 公式ドキュメント を参照してください。 主要なコンポーネントは次の通りです。 Cilium Agent: DaemonSet として動く Ciliumの基本機能を提供するコンポーネント CNI-plugin: Pod ネットワークの情報と連携する機能。通常KubernetesクラスタにはデフォルトのCNI pluginがあるためそれを無効化して インストールします Hubble: Ciliumネットワークを可視化し、Prometheusメトリクスを提供するツール これらのコンポーネントがインストーラによってクラスタに導入されます。 インストーラはCilium CLI を使用するかHelm chartを使用します。 実際には CLIからのインストールもHelm経由です。 今回はHubbleのHTTPメトリクスを サービスごとにグループ分けをしたかったので、以下のような helm オプションを設定して Cilium, Hubble をインストールしました。 # Prometheusメトリクスを有効化してインストール cilium install --helm-set prometheus.enabled=true --helm-set operator.prometheus.enabled=true # Hubble のメトリクスに pod, namespace をタグ付けするように設定してインストール cilium hubble enable --ui --helm-set hubble.metrics.enabled="{dns,drop:destinationContext=pod-short|namespace,tcp:destinationContext=pod-short|namespace,flow:destinationContext=pod-short|namespace,icmp:destinationContext=pod-short|namespace,http:destinationContext=pod-short|namespace}" サンプルアプリケーションの実行 今回は front, backend, backend2という 3つのnginxコンテナを用意してCilium上でアプリケーションを実行します。 proxy_passで後続のサービスを指定することで、 front->backend1->backend2 というように数珠繋ぎでpodを接続します。 # nginx.conf 抜粋 server { listen 80; # front -> backend location /api/ { proxy_pass http://backend:80; } # front->backend->backend2 location /api2/ { proxy_pass http://backend:80; } Ciliumはネットワークレイヤに対して動くツールなので、単にKubernetesにPodをデプロイするだけなら特にマニフェストを修正する必要はありません。 この時点で何度か pod にリクエストを送信し、可視化コンポーネントの hubble の UI を開くと次のような接続状態の可視化が得られます。 何もしなくても Pod間の接続状態が可視化ができてしまいました。 また、UIの下部にはパケットキャプチャのようなTCP接続のステータスが並んでいます。 どれか一つに注目してみると、パケットのIP・Portの他に宛先podやラベル情報が見て取れます。 これが eBPFによって持ち込まれたPodのContextで、これらの情報をパケット処理で扱えるようになります。 L7 Protocol visibility を設定する サイドカーがなくてもPod間接続が可視化できるだけでも私としてはだいぶ驚いたのですが、どうせならもっとHubbleで可視化できる情報を増やしたいところです。 eBPFでL7 Protocolを動的に判定するような高度な処理ができるわけではありませんが、Kubernetesのマニフェストでヒントを与えることができます。 L7 Protocol Visibilityのドキュメント によれば、PodのアノテーションやCiliumNetworkPolicyといったリソースでPodの通信プロトコルを明示することができます。 ただし現時点では、HTTP,DNS,Kafka(beta)のみが指定可能です。 まずは、各Podのmanifestに次のように io.cilium.proxy-visibility アノテーションを設定してみます。 通信の入出力のポートで、TCP/UDPおよびL7プロトコル名を設定します。 apiVersion: apps/v1 kind: Deployment metadata: name: front spec: replicas: 1 selector: matchLabels: app: front template: metadata: labels: app: front annotations: "io.cilium.proxy-visibility": "<Egress/53/UDP/DNS>,<Egress/80/TCP/HTTP>,<Ingress/80/TCP/HTTP>" これらのマニフェストを適用して再びHubble UIを表示すると、可視化される内容にHTTPのURLなどの情報が付加されていることがわかります。素晴らしい。 CiliumNetworkPolicy 続いて、CiliumNetworkPolicyリソースを設定してみます。 例えば次の例は front->backend の通信でPOSTメソッドしか受け付けないという定義です。 apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "front2backend" spec: description: "Only POST" endpointSelector: matchLabels: app: backend ingress: - fromEndpoints: - matchLabels: app: front toPorts: - ports: - port: "80" protocol: TCP rules: http: - method: POST このリソースを適用すると今までのGETリクエストは通らなくなります。 % curl -i http://localhost:8083/api2/hello HTTP/1.1 403 Forbidden Server: nginx/1.23.1 Date: Mon, 29 Aug 2022 10:38:07 GMT Content-Type: text/plain Content-Length: 15 Connection: keep-alive x-envoy-upstream-service-time: 0 Access denied Hubble UIでもパケットのドロップが記録されます。 メトリクスを取得する HubbleにはPrometheus用のメトリクスを提供する機能もあります。 こちら にある通り、メトリクスのタグにはPodの情報を付与できます。 ただし前述した通り、この内容はインストール時に明示的に設定する必要がありました。 コンテキストオプションを指定した場合、次のようにpod, http ステータスごとのメトリクスを得ることができます。 # HELP hubble_http_responses_total Count of HTTP responses # TYPE hubble_http_responses_total counter hubble_http_responses_total{destination="default/backend",method="GET",status="200"} 13 hubble_http_responses_total{destination="default/backend",method="GET",status="500"} 12 hubble_http_responses_total{destination="default/front",method="GET",status="200"} 13 hubble_http_responses_total{destination="default/front",method="GET",status="500"} 7 個人的にはサービスメッシュ導入の主目的であるメトリクスの取得が、これだけで実現できてしまって驚きました。 弊社ではモニタリングでDatadogを使用していて、CiliumとのIntegrationもありました。 Monitor Cilium-managed infrastructure with Datadog Datadog Cilium Integration 現時点ではCilium AgentのメトリクスのみのようでHubbleのメトリクスはまだサポートされていないようですが、将来に期待して良いのではと思っています。 sidecar free service mesh Cilium 1.12の目玉であるサービスメッシュの機能については、 Cilium 1.12のリリース記事 や サービスメッシュのブログ に内容がまとまっています。 Ciliumはネットワークコンポーネントなので、Istioのようなサイドカーベースのサービスメッシュと組み合わせて動かすこともできます。 1.12 ではそれに加えて、Ingress ControllerおよびCilium Agent と協調して動いているEnvoyへ、eBPFだけではできないネットワーク制御を適用する方法を、sidecar free　のサービスメッシュというふうに表現しています。 Cilium AgentはサブプロセスとしてEnvoyもノード単位で動かしています。 eBPF (IngressController, TLS終端, L7 load balancing, リトライなど)をEnvoyに移譲するようになっていて、Envoyへの設定を適用するCRDが追加されています。 IstioなどではPodごとにサイドカーとしてEnvoyが必要ですが、 Ciliumの場合ノード単位で一つEnvoyがあれば良いので通信パフォーマンスが大幅に向上すると サービスメッシュのブログ には書かれています。 また、 ロードマップ でも今後さらなる機能追加が予定されています。 では、実際にいくつかのサービスメッシュのサンプルを試してみます。 サービスメッシュのサンプル1-サービス振り分け 最初は複数サービスを割合に応じて接続先を振り分けるというものです。 これまでのサンプルプリケーションにもう一つ、 backend3 というPodを追加し、次のような CiliumEnvoyConfig リソースを適用します。 apiVersion: cilium.io/v2 kind: CiliumEnvoyConfig metadata: name: envoy-backend-listener spec: services: # backend2,および backend3への接続がまとめられる。 - name: backend2 namespace: default - name: backend3 namespace: default resources: - "@type": type.googleapis.com/envoy.config.listener.v3.Listener name: envoy-backend-listener filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: envoy-backend-listener rds: route_config_name: lb_route http_filters: - name: envoy.filters.http.router - "@type": type.googleapis.com/envoy.config.route.v3.RouteConfiguration name: lb_route virtual_hosts: - name: "lb_route" domains: [ "*" ] routes: - match: prefix: "/" route: #接続を 50:50 で振り分ける weighted_clusters: clusters: - name: "default/backend2" weight: 50 - name: "default/backend3" weight: 50 retry_policy: retry_on: 5xx num_retries: 3 per_try_timeout: 1s - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: "default/backend2" connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: "default/backend3" connect_timeout: 3s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 CiliumEnvoyConfigリソースはCilium Agentの Envoyに対して設定をするためのリソースで、ここでは backend2, backend3への接続に対してEnvoy Listenerを起動して接続をプロキシするようになります。 その後、weighted_clustersの設定で接続を割合で振り分けるようになります。 backend Podのnginxにはproxy_passとして backend2 しか記述がないにもかかわらず、暗黙的に接続がenvoy経由になり、50:50で backend3にも繋がるようになります。 % curl localhost:8083/api2/hello {"message":"fom-backend2"} % curl localhost:8083/api2/hello {"message":"fom-backend3"} % curl localhost:8083/api2/hello {"message":"fom-backend3"} % curl localhost:8083/api2/hello {"message":"fom-backend2"} サービスメッシュのサンプル2-外部認証リクエスト(ExtAuthz) 前述のCiliumEnvoyConfigリソースのサンプルを見て、わかる人にはわかると思いますがリソースの記述内容は、ほとんどEnvoyのListenerとClusterの設定そのままです。 とはいえ、 CiliumEnvoyConfig の説明 をみると、 記載が可能なフィルターの内容はある程度限定されています。 Istioでは可能なアクセスログ出力,JWT検証, Fault Injectionなどは現時点では設定できないようです。 ですが、外部リクエスト認証を行うための ext_authz フィルターは設定可能なようなので、これを使用して 特定のリクエストヘッダがなければアクセスを拒否するように設定してみます。 外部リクエスト認証を行うサービスとして、 Istioの認証サンプル を使用します。 これは リクエストヘッダに x-ext-authz: allow という値があるかどうかをチェックするものです。 このサンプルをext-authz Podとして デプロイし、次のCiliumEnvoyConfigリソース を適用します。 apiVersion: cilium.io/v2 kind: CiliumEnvoyConfig metadata: name: envoy-front-authz-listener spec: #front podへの接続を envoyでプロキシする services: - name: front namespace: default # 接続をproxyしないが、envoyから接続するサービスは backendServiceとして記述する backendServices: - name: ext-authz namespace: default number: ["8000", "9000"] resources: - "@type": type.googleapis.com/envoy.config.listener.v3.Listener name: envoy-front-authz-listener filter_chains: - filters: - name: envoy.filters.network.http_connection_manager typed_config: "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: envoy-front-authz-listener rds: route_config_name: front_lb_route http_filters: # ext_authzフィルターを追加。 全てのリクエストを ext_authz　podへ転送して認証チェック - name: envoy.filters.http.ext_authz typed_config: "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz stat_prefix: ext_authz transport_api_version: V3 http_service: server_uri: uri: "http://ext-authz.default.svc.cluster.local:8000" cluster: "default/ext-authz:8000" timeout: 1s path_prefix: / authorization_request: allowed_headers: patterns: - contains: authz failure_mode_allow: false include_peer_certificate: true - name: envoy.filters.http.router - "@type": type.googleapis.com/envoy.config.route.v3.RouteConfiguration name: front_lb_route virtual_hosts: - name: "front_lb_route" domains: [ "*" ] routes: - match: prefix: "/" route: cluster: "default/front" - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: "default/front" connect_timeout: 5s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: "default/ext-authz:8000" connect_timeout: 3s lb_policy: ROUND_ROBIN type: EDS outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 - "@type": type.googleapis.com/envoy.config.cluster.v3.Cluster name: "default/ext-authz:9000" connect_timeout: 3s lb_policy: ROUND_ROBIN type: EDS typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config: http2_protocol_options: {} outlier_detection: split_external_local_origin_errors: true consecutive_local_origin_failure: 2 front Podへの接続について、ext_authzフィルタを適用して認証チェックを追加します。 ここでのポイントは Envoyでプロキシはしないが、envoyから接続するバックエンドのサービスを backendServices に記載することです。 現時点ではbackendServicesについてはドキュメント化されておらず、ソースを見てやっとその存在がわかりました。 次のように front Podへの通信はまず ext_authz Podへ流れ、そこでOKだと backendへ、NGだと 403ステータスコードがクライアントへ返ります。 リクエストヘッダなしのリクエストは拒否されるようになります。 # curl http://front/api/hello -i HTTP/1.1 403 Forbidden x-ext-authz-additional-header-override: x-ext-authz-check-received: GET front/api/hello, headers: map[Content-Length:[0] X-Envoy-Expected-Rq-Timeout-Ms:[3600000] X-Envoy-Internal:[true] X-Forwarded-For:[172.17.0.1] X-Forwarded-Proto:[http] X-Request-Id:[3200cb72-9786-49d6-a5b5-102907202116]], body: [] x-ext-authz-check-result: denied date: Mon, 29 Aug 2022 11:51:54 GMT content-length: 76 content-type: text/plain; charset=utf-8 x-envoy-upstream-service-time: 3 server: envoy denied by ext_authz for not found header `x-ext-authz: allow` in the request 認証が通るリクエストヘッダ付きのリクエストはOKになります。 # curl http://front/api/hello -i -H "x-ext-authz: allow" HTTP/1.1 200 OK server: envoy date: Mon, 29 Aug 2022 11:53:57 GMT content-type: text/plain content-length: 19 x-envoy-upstream-service-time: 2 {"message":"hello"} これで、sidecar free service meshの機能の一部を試すことができました。 まとめ Ciliumの機能をある程度試すことができました。 Istioなどサイドカー型のサービスメッシュはL4より上のレイヤでサイドカーによって通信をコントロールすることでサービスメッシュを構成するのに対し、 CiliumはeBPFによりセキュアなネットワークを導入することで結果としてシンプルなサービスメッシュを実現しているという印象を受けました。 Ciliumは他にも色々な機能があります。以下は興味はあるものの時間の都合上試せなかったものです。 OpenTelemetry Integration gRPCの複数Podの分散 Multi Cluster mTLS( 参考のブログ記事 ) 個人的な感想では、相当の魅力があるものの現時点ではプロダクトへの導入は以下の内容から、様子を見たいという感じです。 Podレベルのメトリクスがサイドカーなしで取得できるのは非常に良い、というよりもびっくりした。 Datadogなど、外部の監視サービスのサポート状況を注視したい。 Istioでパフォーマンス的に困っていない。 サービスメッシュの機能としてはIstioの方が揃っている アクセスログの取得は現時点でも使用しているが Ciliumにはない Istioの通信機能 と比較すると、FaultInjectionやCircuit Breaker,JWT検証などは現時点ではCiliumでは使用できないか工夫が必要 CiliumEnvoyConfig リソースの書き方があまりにもEnvoyに寄りすぎていて、Envoyの知識が必須になっている とはいえ 2,3年後にはこの状況が変わっていてもおかしくないのではと期待できるプロダクトであることは間違いないです。 これからもCiliumのアップデートには注目していきたいと思います。 また、Ciliumが流行ったとしてもEnvoyはそのまま使われていくと思います。サービスメッシュの主要コンポーネントやプロキシサーバーとしてEnvoyは至るところで使われています。みなさんEnvoy力を鍛えましょう。 ここまでお読みいただきありがとうございました。 CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひ こちら より面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについてはSNSで随時発信しておりますので、 Twitter のフォローや、 connpass のメンバー登録をぜひよろしくお願いします。

はじめに eBPF とはなにか ざっくり概要 「Packet Filter」なのに「Virtual Machine」? eBPFでなにができるか? カーネルイベントのフック ユーザーランドアプリケーションとのやりとり eBPFの主な用途 eBPFが注目される背景 eBPFの仕組み アーキテクチャと処理フロー カーネルモジュールとeBPFの違い eBPFプログラムの作り方 eBPFプログラムを作ってみる 環境の準備 Hello world もう少し複雑なサンプル その他のサンプル HTTPリクエストのダンプ TCP接続先の調査 tcplife dirtop filetop oomkill まとめ eBPFはなにに使えるか 参考サイト はじめに こんにちは、Platformチームの小森です。 eBPF (extended Berkley Packet Filter) について、2022年8月2日に開催された社内勉強会で発表しました。 eBPF はここ数年で注目が集まっている技術で、2021年には eBPF Foundationが設立 され、Facebook、Google、Isovalent、Microsoft、Netflixなどの大手IT企業が参画を進めています。 筆者は概要程度しか把握していなかったので、遅ればせながらキャッチアップのために情報収集しました。すでに多くの情報が出回っているので新規性は少ないですが、引用元を示しつつ、短時間で理解できるようにまとめてみました。 特に次のような方は、eBPFの概要を押さえておくと良いのではないかと思います。 Kubernetesに興味がある、または使っている Linuxの中でもネットワーク周りの基盤技術に興味がある 日々障害調査に追われている iptablesが大好き eBPF とはなにか ざっくり概要 eBPF(extended Berkley Packet Filter)は、Linuxカーネル内でのイベント発生時に動作する処理を、安全・手軽に組み込むための仕組みで、現在ではLinuxカーネルの機能として提供されています。 eBPFは、カーネル空間で動作する仮想マシンです。仮想マシンというと、VMWare、VirtualBox、KVMなど、ハードウェアを含めてエミュレートするハイパーバイザを思い浮かべるかもしれませんが、eBPFは専用の命令セットを持った仮想的なCPUのようなものです。小型のJavaVMのようなものがカーネル内で動作するとイメージすれば良さそうです。 JavaVMと同じように、eBPF専用のバイトコードを渡すと、カーネル内部で検証され、実際に動作するマシンコードにコンパイルされたのちに、カーネルに組み込まれます。 「Packet Filter」なのに「Virtual Machine」? なぜ、eBPFは「Packet Filter」という名称なのに、実体は Virtual Machine なのでしょうか。理由は、その発展の歴史にあります。 eBPFの歴史は意外に古く、約30年前の1992年に、ローレンス・バークレー国立研究所のSteven McCanneとVan Jacobsonが公開した論文「 The BSD Packet Filter: A New Architecture for User-level Packet Capture 」にさかのぼります。 当初はその名のとおり、パケットキャプチャやフィルタリングを効率化するための技術でした。 現在でも、障害調査などで特定の宛先やポートで通信されるパケットを取得したいことはよくあります。 ネットワークでやりとりされるパケットをキャプチャして必要なものだけを抽出(フィルタ)するには、カーネル空間で動作するネットワークドライバはキャプチャしたパケットを、ユーザー空間で動作するアプリケーションに渡し、アプリケーション側でフィルタ処理を行う必要がありました。 [出典] : BPF Overview The BSD Packet Filter: A New Architecture for User-level Packet Capture このような作りでは、カーネル空間とユーザー空間の切替が多く発生し、効率がよくありません。 そこで、カーネル空間で動作する仮想マシンを用意し、その上でパケットをフィルタリングするアプリケーションを実行できるようにすれば、多くの処理がカーネル空間で完結するのでパフォーマンスが向上するというのが基本的なアイデアです。 [出典] : BPF Overview The BSD Packet Filter: A New Architecture for User-level Packet Capture BPFは当初BSDに実装されたのち、 1997年にLinuxカーネル2.1.75に移植されました 。 BPFを利用したパケットキャプチャとフィルタリング機能はlibpcapというライブラリとして実装され、現在でもよく使われているパケットキャプチャツール、 tcpdump で利用されています。 そしてしばらく時がたち、2013年、対象をネットワークパケットだけに限らず、より汎用化した仕組みとして「eBPF」が提案されました。2014年、eBPFがLinuxカーネル3.17に組み込まれて拡張が続き、今にいたります。 eBPFと対比して、当初のBPFを「cBPF (classic BPF)」と呼ぶこともあります。なお、現在ではeBPFは 「 which is no longer an acronym for anything (何の略称でもない)」とされています。 [出典] eBPF - 入門概要 編 - BPFの歴史 BPF – in-kernel virtual machine eBPFでなにができるか? カーネルイベントのフック eBPFでは、ネットワークだけではなく、さまざまなカーネル内のイベントをフックし、さまざまな処理を実行することができます。 フックできるカーネルイベントは「 Program Types 」として定義されています。 いくつかの記事を参考にして大別すると、以下のようになります。Program Typeの説明は、原文のほうが分かりやすいので、翻訳せずに出典からそのまま引用しました。 ソケット操作 - パケットフィルタリングや、コネクション確立/タイムアウトなどのソケット属性変更、パケットのリダイレクトなどのイベント BPF_PROG_TYPE_SOCKET_FILTER : a network packet filter BPF_PROG_TYPE_SOCK_OPS : a program for setting socket parameters BPF_PROG_TYPE_SK_SKB : a network packet filter for forwarding packets between sockets トンネリング - ネットワークスタック内のパケットカプセル化フレームワークに関するイベント BPF_PROG_TYPE_LWT_* : a network packet filter for lightweight tunnels 帯域制御 - 帯域制御を実現するためのイベント BPF_PROG_TYPE_SCHED_CLS : a network traffic-control classifier BPF_PROG_TYPE_SCHED_ACT : a network traffic-control action XDP(Xpress Data Path) - NICから受け取ったパケットデータを直接操作するためのイベント BPF_PROG_TYPE_XDP : a network packet filter run from the device-driver receive path トレーシング - カーネル関数呼び出し、カーネル関数内のイベント発生、パフォーマンスカウンタなどのイベント BPF_PROG_TYPE_PERF_EVENT : determine whether a perf event handler should fire or not BPF_PROG_TYPE_KPROBE : determine whether a kprobe should fire or not BPF_PROG_TYPE_TRACEPOINT : determine whether a tracepoint should fire or not Cgroups - Cgroup(プロセスをグループ化してリソース割り当てを制御する機構)におけるイベント BPF_PROG_TYPE_CGROUP_SKB : a network packet filter for control groups BPF_PROG_TYPE_CGROUP_SOCK : a network packet filter for control groups that is allowed to modify socket options BPF_PROG_CGROUP_DEVICE : determine if a device operation should be permitted or not 当初のBPF(いわゆるcBPF)で実現されていたのは、ネットワーク処理の部分だけでしたが、eBPFではさまざまなフックポイントが追加されていることがわかります。 [出典] A thorough introduction to eBPF (上記Program Typeの説明は、本記事より引用) BPF: A Tour of Program Types @IT - Berkeley Packet Filter（BPF）入門（4） - LinuxのBPFで何ができるのか？　BPFの「プログラムタイプ」とは eBPF - 入門概要 編 「おいしくてつよくなる」eBPFのはじめかた ユーザーランドアプリケーションとのやりとり eBPFプログラムは、Program Typesでフックしたイベントによって動作し、処理結果をユーザー空間で実行するアプリケーションと受け渡しすることができます。 具体的には、 Maps という機構が提供されており、ハッシュテーブルや配列、LRU、リングバッファなどの各種データ構造が使えます。 eBPFの主な用途 eBPFが使われているプロダクトは、 こちら のサイトで紹介されていますが、いくつかを簡単に紹介します。 ネットワーク制御 Cilium コンテナ間通信に対してパケット処理に可観測性・セキュリティ・高度な通信制御を付与するソフトウェア。主にKubernetesでの利用を想定 Katran Facebookが開発する、XDPを活用した高性能L4ロードバランサ Pixie Kubernetesアプリケーションから自動でテレメトリデータを取得してObservability(可観測性)を向上させるツール Cloudflare Magic Firewall プロダクトではないが、Cloudflare のDDoS対策機能として利用されている セキュリティ Falco アプリケーションの異常な動作を検出するアクティビティモニタ Tetragon 透過的にセキュリティや可観測性を適用するためのツール トレーシング bpftrace BPFをラップするDSL(Domain Specific Language)を提供する、汎用的なトレーシングツール このように、eBPFが提供するさまざまなフックポイントを活用したプロダクトが作られています。 eBPFが注目される背景 近年eBPFが注目されている背景には、Kubernetes(以下、k8s)の普及によるアプリケーションのコンテナ化やマイクロサービス化が進んでいることがあると思われます。 k8sでコンテナ間の通信を実現するには、Linuxに古くからある netfilter/iptables が使われています。 netfilter は、BPFと同様にカーネル内のネットワークスタックのさまざまな場所に、コールバック関数を追加できるしくみで、iptablesはそのフロントエンドツールです。 iptablesはnetfilterを使ってパケットのフィルタリングや転送を実現し、Linuxによるファイアウォールやネットワークルータの実現には、古くからiptablesが利用されていました。 さきほど述べたように、k8sにおけるコンテナ間通信にも、netfilter で実現されています。 出典:Netfilter - Wikipedia しかし、k8sクラスタで管理されるコンテナが増えるにしたがって、iptablesの問題点が浮き上がってきました。 iptablesは、ルール順番に処理してマッチしたパケットを処理する仕組みなので、ルールの量(つまり通信するコンテナの数)に比例して遅くなってしまいます。 たとえば、eBPFの機能の1つであるXDP(Express Data Path)を活用することで、NICに近いところでパケットを受け取り、独自に処理して高速なコンテナ間通信を実現しようとしているのが、eBPFを活用したプロダクトでも特に注目を集めている Cilium です。 (Ciliumについては、 前多さんの記事 を参照ください) また、コンテナ環境を活用してシステムのマイクロサービス化が進むと、安定運用のために通信や各種メトリクス、パフォーマンスを把握する必要性が高まり、可観測性やセキュリティもより重要視されます。 このようなニーズにも、冒頭で紹介したeBPFの多彩なフックポイントと、カーネル空間内で高速処理できるという特性がマッチしていると思われます。 [出典] iptablesの後に来るものは何か？： nftables - 赤帽エンジニアブログ eBPFの仕組み アーキテクチャと処理フロー eBPFの概要や背景がわかったところで、その仕組みをもう少し追ってみましょう。 eBPF - 入門概要 編 - eBPFアーキテクチャ概要 で説明されている図が分かりやすかったので、これを参考にアーキテクチャの説明図を書きました。 この図に使って、eBPFの大まかな処理フローを説明します。 eBPFを扱うユーザープログラムは、eBPFソースコードをコンパイルしてバイトコードに変換する システムコールを使用してeBPFバイトコードをカーネルへロードする eBPF Verifierがバイトコードを検証。問題なければコンパイラによって機械語に変換する ユーザープログラムはeBPFプログラムを目的のイベントにアタッチする イベントが発生すると、ExecutorがeBPFプログラムを実行 処理結果を map や ring buffer へ格納 ユーザープログラムが結果を参照 カーネルモジュールとeBPFの違い もともと、Linuxには「 カーネルモジュール 」という仕組みがあり、カーネルモジュールを作成することでカーネル空間で動く処理を追加で組み込めるようになっており、これを使ってカーネルの機能を拡張できるようになってる。 カーネルモジュールの代表例としては、ファイルシステムや、デバイスドライバなどハードウェアを制御するプログラムが挙げられます。 一方で、カーネルモジュールは自由度が高すぎるため、作りが悪いとカーネルをクラッシュさせる危険性があります。また、 modprobe コマンドで明示的にロード/アンロードする必要があります。もともとデバイスドライバやファイルシステムなどの使い方が想定されていたので、頻繁にロード/アンロードすることは想定されておらず、特定のアプリケーション実行時だけカーネルに処理を組み込むといった使い方がしにくいです。 eBPFでは、ユーザー空間で動作するアプリケーションからシステムコールを呼び出すことで、カーネル空間で動作するeBPFプログラムを動的に組み込むことができます。 また、eBPFでは実行されるプログラムに一定の制約をつけ、Verifierによる検証をパスしなければカーネルに組み込めないような仕組みとして安全性を高めています。 Linuxのリポジトリに、検証器ののコード( verifier.c )があります。こちらのコメントを読むと、たとえば最初の段階では、次のようなチェックが行われるようです。 ( 参考1 , 参考2 ) 命令数が一定数以下であること(大きなプログラムはダメ) ループがないこと 到達不可能な命令がないこと 境界の外に出る不正なジャンプがないこと 特に命令数やループなどの制約は、カーネル空間で実行される処理であることから、厳しめになっていることがわかります。 このような仕組みによって、カーネル空間での処理を手軽かつ安全にアドオンできるようになったことがeBPFとカーネルモジュールの違いです。eBPFによってカーネル空間での処理を手軽に作成できるようになったため、従来のようにカーネル空間とユーザー空間の切替を頻繁に行う必要もなくなり、パフォーマンス向上にも寄与できるようになりました。 [参考] Linux カーネルハックを始める前に知っておきたいこと - かーねるさんとか 【図解】初心者向けユーザー空間とカーネル空間,システムコール,MMU/メモリ保護,の仕組み | SEの道標 eBPFプログラムの作り方 eBPFプログラムの実際の作り方を見てみましょう。 eBPFは最終的に専用のバイトコードにしてカーネルに渡す必要があります。いきなりバイトコードを書くわけにもいかない(書くこともできますが)ので、現実的にはなんらかのプログラミング言語を使うことになります。 eBPFのプログラムはC言語で作成します。 BCC(BPF Compiler Collection) というツールチェーンが公開されているので、これを使用してコンパイルします。 一方、eBPFプログラムをカーネルに組み込み、eBPFの処理結果を受け取ってユーザーに機能を提供するアプリケーション)を、eBPFのフロントエンドと呼びます。 eBPFのフロントエンドは、BCCの公式サポート範囲では、C++、Python、Luaで記述することができます。(世の中のサンプルを見渡すと、簡単なツールはPythonで書かれているものが多いようです) また、BCC本体のサポート範囲ではありませんが、RustやGoといった新しい言語でもフロントエンドが作成できるようです。 また、さきほど紹介したbpftraceは、独自の言語(DSL:Domain Specific Language)を提供しており、トレース用途中心ではありますが、C言語を知らなくてもeBPFとして動作する処理を作成することができます。 bpftraceのGitHubリポジトリ には、多数のサンプルが公開されています。 たとえば、次のようなワンライナーでプロセスが開くファイルを表示させることができます。 # Files opened by process bpftrace -e 'tracepoint:syscalls:sys_enter_open { printf("%s %s\n", comm, str(args->filename)); }' このように、コマンドラインからアドホックにeBPF処理を実行できるのがbpftraceの魅力です。 eBPFプログラムを作ってみる ここからは、実際にeBPFのプログラムを作成して理解を深めます。 環境の準備 今回は、 GCP の Computing Engine に CentOS8 の仮想マシンを作り、そこで試しました。 先ほど紹介したbpftraceが標準のパッケージマネージャで提供されているので、コマンド一発でインストールできます。 sudo dnf -y install bpftrace bpftraceをインストールすると、bccも同時にインストールされて使えるようになります。 Hello world BCCの公式リポジトリ にあるサンプルから、もっとも簡単なものを選んで実行してみます。 hello_world.py を少しだけ分かりやすく書き直したものが、以下のコードです。 このサンプルは、Pythonをフロントエンドとして書かれています。 from bcc import BPF bpf_src= """ int kprobe__sys_clone(void *ctx) { bpf_trace_printk("Hello, World! \\ n"); return 0; } """ b = BPF(text=bpf_src) b.trace_print() 上のプログラムの最終行で BPF 関数に渡しているテキストのC言語部分が、eBPFのコードです。 抜き出したものが以下のコードです。 int kprobe__sys_clone ( void *ctx) { bpf_trace_printk ( "Hello, World! \\ n" ); return 0 ; } イベント名__関数名 という命名ルールで、カーネル内の関数にフックできます。(ここでは、 kprobe__sys_clone ) kprobe は、カーネル内の関数呼び出し前のイベントであることを示します。 sys_clone は、Linuxでプロセスがforkされるときに呼び出されるシステムコールです。(この関数はカーネルのバージョンやCPUアーキテクチャによって異なることがあるので注意 (※)) eBPFプログラムの3行目では、 bpf_trace_printk という関数を呼び出しています。これは主にeBPFのデバッグ用途でカーネル空間からユーザー空間へ文字列を渡すためのものです。 Pythonで書いたフロントエンドコードの11行目で BPF 関数を呼び出すことにより、eBPFプログラムをコンパイルされ、カーネルへ組み込まれます。 そして、12行目の trace_print 関数で、 bpf_trace_printk が出力した文字列を受け取って表示しています。 (このあたりの仕組みは eBPF の紹介 - Qiita で詳しく解説されています) このサンプルを実行し、別のターミナルでコマンドを実行すると、そのたびに「Hello, World!」が表示されます。 実用性はありませんが、eBPFプログラムの書き方と組み込み方、結果の受け取りかたがわかりました。 (※) 「この関数はカーネルのバージョンやCPUアーキテクチャによって異なることがあるので注意」・・・BPFのプログラムは、その特性上CPUアーキテクチャやカーネルのバージョンに依存してしまいます。このためBPFを実際に実行するマシン上でコンパイルするのが原則のようです。このあたりのポータビリティを高めるしくみとして、 BPF CO-RE（Compile Once - Run Everywhere） が考案されており、ある環境でコンパイルしたBPFコードを他の環境でも実行できるようにしています。 もう少し複雑なサンプル eBPF側からフロントエンド側に情報を渡す、もう少し実用的なサンプルを動かしてみます。 第690回　BCCでeBPFのコードを書いてみる | gihyo.jp で紹介されているコードを写経しました。 eBPF部分には、少しコメントを追加しました。 #!/usr/bin/python3 from bcc import BPF bpf_text= """ #include <linux/sched.h> /* Information passed from eBPF to frontend */ struct data_t { u32 pid; u32 ppid; char comm[TASK_COMM_LEN]; char fname[128]; }; /* Make ring buffer named `events` */ BPF_PERF_OUTPUT(events); int syscall__execve(struct pt_regs *ctx, const char __user *filename) { struct data_t data = {}; struct task_struct *task; /* Get PID */ data.pid = bpf_get_current_pid_tgid() >> 32; /* Get Parent PID */ task = (struct task_struct *)bpf_get_current_task(); data.ppid = task->real_parent->tgid; /* Get current task program name */ bpf_get_current_comm(&data.comm, sizeof(data.comm)); /* Get execve argument from user space */ bpf_probe_read_user(data.fname, sizeof(data.fname), (void *)filename); /* Stores data in a ring buffer */ events.perf_submit(ctx, &data, sizeof(struct data_t)); return 0; } """ b = BPF(text=bpf_text) b.attach_kprobe(event=b.get_syscall_fnname( "execve" ), fn_name= "syscall__execve" ) print ( "PID PPID COMM FNAME" ) def print_event (cpu, data, size): # Get eBPF data from `event` ring buffer event = b[ "events" ].event(data) print ( "{:<8} {:<8} {:16} {}" .format(event.pid, event.ppid, event.comm.decode(), event.fname.decode())) b[ "events" ].open_perf_buffer(print_event) while True : try : b.perf_buffer_poll() except KeyboardInterrupt : exit() 今度は、eBPF部分が長くなっていますが、関数は syscall__execve の1つです。 execve は、指定したファイルを実行する時に使用するシステムコールです。システムコールの引数をeBPFから取得する場合は、 syscall イベントでアタッチします。 execve システムコールが実行されるときに、その引数をeBPFで取得して data_t 構造体に格納し、リングバッファ経由でユーザー空間で動くフロントエンドへ送ります。 フロントエンド側では、リングバッファからデータを取得して整形して出力しています。 実行例は以下のようになります。プログラムを実行して他のターミナルで ls や cat コマンドを実行すると、そのログが表示されますし、バックグラウンドで実行されているプログラムも検知できています。 その他のサンプル 最初に紹介した、BCCのリポジトリには豊富なサンプルが公開されており、サンプルに留まらず、実用性のあるツールも多数公開されています。多くは数百行程度なので、勉強がてら自分の用途に改造して使うこともできそうです。 ツールとサンプルの一覧はこちらです。 https://github.com/iovisor/bcc#contents 最後に、このなかから実用性がありそうなものを、いくつか選んで紹介します。 HTTPリクエストのダンプ https://github.com/iovisor/bcc/tree/master/examples/networking/http_filter TCP接続先の調査 tcpv4connect_example.txt tcpv4connect.py PID COMM SADDR DADDR DPORT 1479 telnet 127.0.0.1 127.0.0.1 23 1469 curl 10.201.219.236 54.245.105.25 80 1469 curl 10.201.219.236 54.67.101.145 80 tcplife 実行中に開始/終了されたTCPセッションを記録します。 tcplife_example.txt tcplife.py PID COMM LADDR LPORT RADDR RPORT TX_KB RX_KB MS 22597 recordProg 127.0.0.1 46644 127.0.0.1 28527 0 0 0.23 3277 redis-serv 127.0.0.1 28527 127.0.0.1 46644 0 0 0.28 22598 curl 100.66.3.172 61620 52.205.89.26 80 0 1 91.79 22604 curl 100.66.3.172 44400 52.204.43.121 80 0 1 121.38 22624 recordProg 127.0.0.1 46648 127.0.0.1 28527 0 0 0.22 3277 redis-serv 127.0.0.1 28527 127.0.0.1 46648 0 0 0.27 22647 recordProg 127.0.0.1 46650 127.0.0.1 28527 0 0 0.21 3277 redis-serv 127.0.0.1 28527 127.0.0.1 46650 0 0 0.26 [...] dirtop ディレクトリ単位でのread/writeの記録。 dirtop_example.txt dirtop.py # ./dirtop.py -d '/hdfs/uuid/*/yarn' Tracing... Output every 1 secs. Hit Ctrl-C to end 14:28:12 loadavg: 25.00 22.85 21.22 31/2921 66450 READS WRITES R_Kb W_Kb PATH 1030 2852 8 147341 /hdfs/uuid/c11da291-28de-4a77-873e-44bb452d238b/yarn 3308 2459 10980 24893 /hdfs/uuid/bf829d08-1455-45b8-81fa-05c3303e8c45/yarn 2227 7165 6484 11157 /hdfs/uuid/76dc0b77-e2fd-4476-818f-2b5c3c452396/yarn 1985 9576 6431 6616 /hdfs/uuid/99c178d5-a209-4af2-8467-7382c7f03c1b/yarn 1986 398 6474 6486 /hdfs/uuid/7d512fe7-b20d-464c-a75a-dbf8b687ee1c/yarn 764 3685 5 7069 /hdfs/uuid/250b21c8-1714-45fe-8c08-d45d0271c6bd/yarn [...] filetop ファイル単位でのread/writeしたプロセスのトレース filetop_example.txt filetop.py # ./filetop -C Tracing... Output every 1 secs. Hit Ctrl-C to end 08:00:23 loadavg: 0.91 0.33 0.23 3/286 26635 PID COMM READS WRITES R_Kb W_Kb T FILE 26628 ld 161 186 643 152 R built-in.o 26634 cc1 1 0 200 0 R autoconf.h 26618 cc1 1 0 200 0 R autoconf.h 26634 cc1 12 0 192 0 R tracepoint.h 26584 cc1 2 0 143 0 R mm.h 26634 cc1 2 0 143 0 R mm.h 26631 make 34 0 136 0 R auto.conf [...] oomkill OOM killerによるプロセスkillイベントのトレース。 oomkill_example.txt oomkill.py # ./oomkill Tracing oom_kill_process()... Ctrl-C to end. 21:03:39 Triggered by PID 3297 ("ntpd"), OOM kill of PID 22516 ("perl"), 3850642 pages, loadavg: 0.99 0.39 0.30 3/282 22724 21:03:48 Triggered by PID 22517 ("perl"), OOM kill of PID 22517 ("perl"), 3850642 pages, loadavg: 0.99 0.41 0.30 2/282 22932 まとめ eBPF登場の背景と位置づけを確認し、大まかな仕組みとサンプルの実行を通してeBPFプログラムの作り方を確認しました。 発展中の技術であるため、体系的な情報はまだ少ない印象ですが、サンプルが豊富なので試行錯誤しながら習得していくこともできそうです。 一方で使いこなすにはC言語やカーネルのシステムコールなど、比較的低レイヤーの知識が必要になるため、習得には一定の時間がかかりそうです。(おそらく、bpftraceでこのハードルが下がりそうです) eBPFはなにに使えるか 全体としては、採用プロダクト例で挙げたように、特にネットワーク周りの基盤技術や、可観測性(Observability)の強化が主な用途になると思いました。 一般のエンジニアがeBPFのコードをバリバリ書けるようになる必要は、あまり無さそうですが、eBPFの仕組みを理解しておくと、これから登場するeBPFを活用したプロダクトを使いこなす時に理解が進むと思います。 また、bpftraceのようなツールを使いこなせるようになると、障害調査に使える武器として大いに役立ちそうです。 個人的には、システム運用の場面で監査やセキュリティチェックなど、プロダクト独自のニーズが生じたときに、eBPFを活用できるのではないかと期待しています。 ここまでお読みいただきありがとうございました。 CADDiでは、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひ こちら より面談をお申し込みください。 また、Tech Blogや勉強会等のイベントについてはSNSで随時発信しておりますので、 Twitter のフォローや、 connpass のメンバー登録をぜひよろしくお願いします。 参考サイト 記事中でも断片的に示しましたが、eBPFについて体系的に紹介されていて参考になったサイトを紹介します。 ＠IT連載 > Berkeley Packet Filter（BPF）入門 全10回の連載でかなりボリュームがありますが、Web上の日本語での説明が一番よくまとまっています。著者はbpftraceのコミッタでもあります。 （1） : パケットフィルターでトレーシング？　Linuxで活用が進む「Berkeley Packet Filter（BPF）」とは何か （2） : BPFのアーキテクチャ、命令セット、cBPFとeBPFの違い （3） : BPFプログラムの作成方法、BPFの検証器、JITコンパイル機能 （4） : LinuxのBPFで何ができるのか？　BPFの「プログラムタイプ」とは （5） : BPFによるパケットトレース――C言語によるBPFプログラムの作り方、使い方 （6） : BCC（BPF Compiler Collection）によるBPFプログラムの作成 （7） : Linux 5.5におけるBPF（Berkeley Packet Filter）の新機能 （8） : BPFを使ったLinuxにおけるトレーシングの基礎知識 （9） : BPFによるトレーシングが簡単にできる「bpftrace」の使い方 （10） : 単なるデバッグ情報だけではない「BPF Type Format」（BTF）の使い道 「eBPF - 入門」 必要な要素がコンパクトにまとまっています。私もこの記事を取っ掛かりとしました。 eBPF - 入門概要 編 eBPF - 仮想マシン 編 eBPF - BCCチュートリアル 編 eBPF - bpftraceチュートリアル 編 eBPF - XDP概要 編

エンジニア採用担当の浜田です。 キャディでは note 、 Wantedly 、 Tech blog 、 twitter 、 podcast 、 オンラインイベント など様々なメディアを通じて情報発信をしています。 多種多様なキャディのコンテンツに対し、エンジニアのみなさんが効率よく情報を獲得できるよう、キュレーション記事があると良いと考え、本記事を執筆しています。 以下のような方に読んでいただけると嬉しいです！ ・キャディの Tech 組織に興味がある方 ・キャディのビジネスに興味があるエンジニアの方 ・キャディのエンジニアになってみたい方 [toc] さくっとライトに知りたい方へ エンジニア職、ビジネス職も一丸で課題解決に向き合っているキャディにおいて、ぜひ目を通して頂きたいのが下記3点です。 キャディを取り巻く環境をテキストだけでなく、画像や動画からも感じ取って頂けると思います。 会社概要資料 カルチャーブック ブランドムービー https://www.youtube.com/watch?v=9IogFRU9AkE Tech組織やプロダクトを知りたい方へ エンジニア向けのCompany Overview（採用ピッチ資料）です。会社概要資料と似ていますが、プロダクトや技術スタック、エンジニアが働く環境について記載しています。 2021年末にはAI-Labを立ち上げ、業界トップクラスのエンジニアが続々と集結しています。 キャディのエンジニアは何を開発しているの？を知りたい方にはこちらがおすすめです。主に受発注プラットフォーム事業について記載しています。 [blogcard url=” https://note.com/ksato9700/n/n366ee2989321 ″] また、キャディは受発注プラットフォーム事業で得たノウハウや知見をもとに、図面データ活用クラウド「CADDi DRAWER」をローンチしました。CADDi DRAWERの開発秘話や、CTO小橋がプロダクトに込めた思いはこちらよりご覧いただけます。 [blogcard url=” https://caddi.tech/archives/3719 ″] エンジニア組織の歩みと今後について綴ったCTO小橋のブログです。 [blogcard url=” https://caddi.tech/archives/2443 ″] 2022年にはグローバル化の第一歩として、ベトナムに拠点を設立しました。日本でも海外出身のエンジニア採用が本格化しており、最近は毎月のように海外出身のエンジニアが入社しています。 そんなTech組織のグローバル化について記載したブログです。 [blogcard url=” https://caddi.tech/archives/3759 ″] 最後に、グローバル１兆円のプラットフォームを目指すキャディが取り組む課題をまとめた特設サイトです。ワクワクする課題が見つかるかもしれません。 [blogcard url=” https://recruiting.caddi.jp/recruit/tech/8challenges ″] しっとりと個人を知りたい方へ エンジニア1人1人の事を見てみると、キャディの事がより立体的に見えてくると思います。 ここではエンジニア一人一人のインタビュー記事やnoteなどを集めてきました。 ご紹介したいエンジニアが沢山いるので、ざっくり役割別に分けてみました。 アプリケーション開発（フロントエンド、バックエンド） [blogcard url=” https://kuwana-kb.hatenablog.com/entry/2019/09/27/194935 ″] [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/169058 ″] [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/169198 ″] [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/192402 ″] [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/202357 ″] [blogcard url=” https://note.com/hasssiii_caddi/n/nacf1a88775be?magazine_key=me62552818b14/ ″] アルゴリズムエンジニア [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/222595 ″] [blogcard url=” https://ngtkana.hatenablog.com/entry/2021/03/17/210830 ″] 機械学習エンジニア [blogcard url=” https://note.com/vaaaaanquish/n/n17b375e70562/ ″] テクニカルプロダクトマネージャー [blogcard url=” https://note.com/srt_taka/n/ncb6dff973779?magazine_key=me62552818b14/ ″] [blogcard url=” https://note.com/imaimai/n/n28e3100a1de7/ ″] エンジニアリングマネージャー [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/309875 ″] [blogcard url=” https://vn.wantedly.com/companies/caddi/post_articles/324651 ″] CTO [blogcard url=” https://www.wantedly.com/hiringeek/interview/rc_ttb10/ ″] [blogcard url=” https://type.jp/et/feature/18514/ ″] キャディのエンジニアメンバーは、個々が専門分野において卓越した技術を持っており、それぞれの専門性を活かして日々業務に取り組んでいます。 また、週次で勉強会をするなどしており、技術や考え方の多様性と向き合う機会を作り合う文化があります（勉強会はCADDiをモジッてSTUDDiと呼ばれています。一部、 Tech Blogでも勉強会の内容を掲載しています ので、よかったらのぞいてみてください！）。 じっくりどっぷり知りたい方へ ここまでの記事を読み終えてしまい、更に深く知りたいという方向けにそっと参考記事を置いておきます。 [blogcard url=” https://note.com/sasaguchisan/n/n65ee9266bc25 ″] [blogcard url=” https://corp.caddi.jp/recruit/issues/ ″] [blogcard url=” https://note.com/ideafruits/n/ndb62b147fc78 ″] [blogcard url=” https://note.com/yushirodesu/n/n412ac5846d2c ″] 最後に この他、不定期で情報発信している twitter もよければフォローしてみてください。なんらかの Give を届けられるように日々試行錯誤しています。 イベントに関する情報は、 キャディのconnpass がありますので、こちらも登録いただけると嬉しいです。 ここまでお読みいただき、キャディのことが気になってきた、と言う方は募集中ポジションについても是非ご覧ください。 [blogcard url=” https://note.com/jirohiraiwa/n/nd24788c801bf ″] まずはカジュアルにもっと話を聞いてみたい！という方は、 こちら より申し込んでいただけますと幸いです。 最後までお読みいただき、ありがとうございました。

半年で製造業向けAIサービスをリリースした開発チームのノウハウ大公開レポート 半年で製造業向けAIサービスをリリースした開発チームのノウハウ大公開レポート はじめに 登壇者 CADDi DRAWERの成り立ち CADDi DRAWERにおけるエンジニアリング Q&A 今後の展望 おわりに はじめに こんにちは。CADDiでエンジニア採用を担当しております上野です。 先日、CADDiから新たに図面の管理、活用を推進するためのサービス『CADDi DRAWER』をリリースしました。 図面は、製造業界では「最重要データ」とも言われており、これらを活用できる状態にする事は必要とされていながらも、長らくソリューションがない状況でした。 「CADDi DRAWER」は、図面の画像検索など、最新の技術をコアにした新しい図面活用プロダクトです。 図面に紐づく様々なデータを活用できる状態にするソリューションを提供しています。 本記事は、約半年で開発されたCADDiの新 SaaS である「CADDi DRAWER」の開発秘話をテーマにしたイベントレポートです。 イベントURL： https://caddi.connpass.com/event/251655/ 登壇者 本イベントでは、CADDi DRAWERの開発をリードするTech LeadやPdMが登壇し、CADDi DRAWERのこれまでの開発とfuture workについてお話しました。 Oniki (Product Manager) Kan (Frontend Engineer) Kawai (AI Lab Tech Lead) CADDi DRAWERの成り立ち 前半は、PdMのOnikiから、CADDi DRAWERにおけるプロダクトの遷移と現在の立ち位置に関する トーク を実施しました。 プロダクト初期の ヒアリ ングとベータ版 従来の図面管理システムでは、作成された図面を承認したり閲覧権限を設定したりと、「管理すること」が目的でした。 「管理すること」は、図面データ活用サイクルではほんの一部にしかすぎません。「CADDi DRAWER」は、本来の図面データ活用サイクルを包括できるシステムを提案しています。 Oniki (Product Manager) CADDi DRAWERは、いきなりの開発は行わず「Problem Solution Fit」をゴールにプロジェクトを進めました。 Problem Solution Fitとは、顧客が抱える問題や課題を解決する製品（プロダクト、サービス）を提供している状態のことです。 顧客の課題を特定し、それを解決しうるソリューションを見いだした後、MVP（Minimum Viable Product, 実用最小限の製品）を製作、リリースして、顧客に受け入れられるかを検証していく。それを繰り返して、製品が顧客の課題を解決している PSF の状態を作っていきました。 Oniki (Product Manager) 実際に、CADDi DRAWERプロジェクトでは、CADDiが培った経験や蓄積されたデータをもとに大きな仮説をたて探索を行うフェーズを長期間実施しています。 この仮説をもとに「もしこれ実現できたらどうなる？」というベータ版を作成しました。 実は、プロジェクト初期は現在の「類似図面を検索機能」ではなく別のソリューションが仮説の軸でした。 数十社の ヒアリ ングを繰り返し、顧客が本当に求めているものを探す中で今の形に落ち着いたと言えます。 Oniki (Product Manager) 例えば、検索結果としてファイル名と図面が並ぶだけでもお客様は驚かれた。エンジニアのぼくらからすると「え？そうなの？」と感じる発見がたくさんあった。 お客様でさえも気が付いていない UX を探り出す、という感覚に近かった。 Oniki (Product Manager) Onikiも言っている通り、長い ヒアリ ングの結果生まれたベータ版をお客様に持って行ってみたところ、その場で得られたのは「これなら使いたい！」と大変ありがたい好感触と「これを自分たちの図面で試したい！」というリク エス トでした。 まさにゴールとしていたProduct Solution Fitが一部実現したような形で、CADDi DRAWERはスタートし今に至っています。 CADDi DRAWERにおけるエンジニアリング 後半では、実際に開発をしているエンジニアから、開発体制や開発の裏話をお話しました。 開発体制 「CADDi DRAWER」開発の体制は大きく2つ「DRAWER Team」と「AI Lab Team」に分かれています。 ベータ版が出て以降は、 システム開発 の側面で様々な課題を乗り越える必要がありました。 数千枚という膨大なデータを実際に動かせることができること 図面データに対してどのような検索ができるのか 発注金額等どのような情報が結果として出たらよいのか さらに「あったらいい機能」は何なのか 実際にこれらを開発すべく、エンジニアチームでも試行錯誤しながらプロジェクトを進めました。 DRAWER Teamでは、お客様の体験を最大限に引き上げるための機能開発を主軸にしています。「CADDi DRAWER」を使うための事前調査や、より使いやすくするためのツール開発などを行っています。 今は DRAWER Teamを分けたり、開発体制を試行錯誤しています。 Kan (Frontend Engineer) 超短期期間のリク エス ト CADDi DRAWERは、ただでさえ図面データというサイズの大きなデータを扱う製品です。 エンジニアチームでは、余裕のある開発期間を想定していましたが、実際のユーザの反響に伴って速度を上げて仕上げる必要がありました。 嬉しいお言葉ですが「お金払うからもうちょっと早く製品を出してほしい」と言われ、開発としてはたいへんでした。「来週お客様が触るの!？」ということもたくさんありました。 Oniki (Product Manager) イベントタイトルにもある通り、半年でのリリースとなり、リリース日程が決まったのは4ヶ月目の頃でした。 より良い機能を小さく提供するために、開発チームでは様々な試行錯誤を実施しました。 Oniki (Product Manager) 「類似って何？」 図面検索を作るAI Labも課題は山積みでした。 「そもそも類似って何？」という状態から課題を解決していきました。 最初の会議で「類似って何ですか？」と聞いたら「わからない」と返ってきた。なので「類似」の定義から始める必要があった。色々模索しましたが、製造業出身の人がいたり、現状のサービスが簡単に利用できたりする CADDiの資産 が大きかったと思います。図面を紙で大量に印刷して、オフィスで並べてどれとどれが似ているのかグルーピングしてIDつけて・・・という泥臭い作業を最初は積み重ねたりもしました。 Kawai (AI Lab Tech Lead) また、システムへの組み込みの設計もDRAWERチームとAI Labが共同で実施しています。 AI Labでは 疎結合 になる を目標としていました。DRAWER Teamから送られてくるデータに対してインデキシングしたり、 Deep Learning を利用して画像抽出のための仕組み作りをしています。 特に「CADDi DRAWER」は「いろんな条件で検索したい」というリク エス トに応える必要があるため、検索のチューニング等に力を入れてきました。 これからは、 Kubernetes と 機械学習 の部分を分離してできるように改善しています。 Kawai (AI Lab Tech Lead) PdMと協力しながら、類似を定義し、システムに落とし込んでいった結果として、半年という短い期間でプロダクト開発に一定の区切りをつけることが出来たとも言えます。 Q&A イベント当日は、チャットにて非常に多くのご質問を頂きました。 登壇者である3人が出来る限り回答し、様々な視点からプロダクト開発を掘り下げるイベントになりました。 Q. AI LabがDRAWER Teamとの関係性で気を付けていることはありますか？ AI Lab では社内受託にならないように非常に気を付けています。「CADDi DRAWER」開発で最もよかったと思うのはPdMからの説明だったと思います。自分たちが今から取り組むのは「CADDi DRAWER」のサイクルのうちどこにつながるのか、を最初の段階でしっかり議論しました。そのためメンバーの意思を高めることにつながったと思います。 Kawai (AI Lab Tech Lead) Q. 製品を説明する際、どのように アルゴリズム を説明しているのでしょうか？ 「CADDi DRAWER」の場合、画像が多いため 定性評価 が必須だと考えています。 機械学習 的な アルゴリズム をそのまま説明するのではなくデモを基にできること、出来ないことを説明しつつAI Labとしては「出来ないこと」を減らすようにしています。 Kawai (AI Lab Tech Lead) Q. お客様の図面に対して類似画像を検索結果として出しているようですがVertex AI Matching Engineを使用しているのでしょうか？ 今回は使用していません。Vertex AI Matching Engineの課題としては、テキストとの混ぜ合わせやフィルター条件での検索などが難しいと考えています。現在のシステムはテキストと ベクター の検索ができるように設計した結果となっています。 Kawai (AI Lab Tech Lead) Q. 図面は一般的なテキストとは性質が異なりますが、どのように 機械学習 のデータとしているのでしょうか？ 機械学習 に直接そのまま入れる、ということはしていません。図面に書かれた類似における必要な情報と、不要な情報があります。例えば図面に書かれている手書きのメモなどをデータとして持つべきなのかというところを考えたうえで画像処理を行った上で入力データとしています。 Kawai (AI Lab Tech Lead) Q. 図面特有の記号は検索できますか？ 現状図面特有の記号を一部を対応しています。穴あけ、溶接などの記号はPoC段階ですが 機械学習 や OCR で対応できるよう設計しています。 Kawai (AI Lab Tech Lead) 今後の展望 イベントでは、最後に「CADDi DRAWER」の今後について、登壇者3人のそれぞれの視点からディスカッションを行いました。 まずは、お客さまが実際に 図面を軸に活用できる ことを実現したいと思っています。その後は、今回の開発でもあったように事前に思い描いているものとはまったく異なるリク エス トなどが出てくる可能性があるので、今まさにリサーチをしているところです。 Oniki (Product Manager) 現状は検索する、というサイクルにフォーカスがあっていますがAI Labとしては 分析する というサイクルに影響を与えていきたいです。 Kawai (AI Lab Tech Lead) 「検索する」というのはほんの一部しか解決していません。「分析する」「行動する」などのサイクルを実現することで、より PDCA を手助けできるCADDiとして拡張していきたいと思います。 Kan (Frontend Engineer) 1つのプロダクトを全員で作っている様子が伝われば幸いです。 おわりに 本記事では、CADDiの新しいサービスである「CADDi DRAWER」の開発秘話イベントのレポートを記しました。 お読みいただきありがとうございました。 CADDiでは、CADDi DRAWER事業以外も含め、現在積極的に採用を行っています。 まずはカジュアルにお話を聞いてみたい！という方は、ぜひ こちら より面談をお申し込みください。 また、 Tech Blogや勉強会等のイベントについては SNS で随時発信しておりますので、 Twitter のフォローや connpass のメンバー登録をぜひよろしくお願いします。

[toc] はじめに はじめまして。CADDiの学生インターンとしてバックエンドエンジニアをしている渡邊です。 このたび、3ヶ月間のインターンを7月末に終えるにあたり、その成果発表として記事を書きたいと思います。 この記事では、私がインターンを始めるまでの経緯、インターンで行った実際の業務内容、そしてインターンを通しての感想、の3項目について書いていきます。 インターンまでの経緯 CADDiのインターンには、2022年3月のイベント 「Rust完全に理解した(嘘)」 を通じて、カジュアル面談・技術試験・面接を経て参加させていただくことになりました。 インターンでやってみたいこととしては以下の2つがありました。 「業務システムの開発」 今までは、個人での開発、地元企業でのアルゴリズム開発、といった小規模な開発に携わっていたため、より大規模なシステムに携わってみたかった。 「仕事でRustを書く」 過去の業務（アルゴリズム開発）ではC++を使っていたが、言語の使い勝手に不満があった。そこで、日頃から愛用しているRustを業務で使うことでどのような開発体験が得られるのかを知りたかった。 インターンの内容 仕事の概要 生産管理プロダクトチーム傘下の Klein-2022 開発チームに配属され、社員の方々と一緒に開発を行いました。 インターンの最初数日で環境構築やプロダクトの説明を受け、その後は他のチームメンバーと同等の扱いでタスクに割り振られて開発に取り組みました。 勤務形態としては、フルリモートで週3日、各8時間（10:00~19:00）の勤務でした。 Klein-2022 とは 社内で稼働している受発注オペレーション管理システム「Klein」の置き換えを目指すプロダクトです。 「お客様に対して見積・受注を行い、サプライパートナー（SP）様へ製造を発注し、製造された製品を検査した上でお客様へ出荷する」という一連の受発注オペレーションを管理します。 単独で動くわけではなく、社内の他システム（SP様との見積・発注のやりとりを行う「SPP」、倉庫拠点オペレーションを管理する「Polaris」など）とデータを連携することもあります。 Klein-2022の構造 Klein-2022は以下の図のような構造になっています。 Klein-2022は フロントエンド （ Next.js ）、 BFF （ NestJS ）、 バックエンド （ Rust ）という3つのモジュールからなります。モジュール間の通信は、フロントエンド↔︎BFFは GraphQL 、BFF↔︎バックエンドは gRPC を使用しています。 なお、バックエンドはモノリシックではなく、受発注オペレーションの段階に合わせて分割されたマイクロサービスとなっています。 現時点では以下の6個のサービスで構成されています。 アカウント: お客様、SP様、案件担当者などの情報を管理 BOM: 製造する製品の情報を管理 見積: 見積を管理 販売: お客様からの受注、およびお客様への製品の出荷を管理 調達: SP様への発注、および製造された製品の入荷を管理 SC: 拠点検査（CADDi拠点における製品の検査）の情報を管理する Klein-2022のより詳しい設計やその背景を知りたい方は、Klein-2022開発チームのメンバーである松田氏の発表資料をご覧ください。 Rust製の業務WebアプリケーションをRustでリプレイス 典型的な開発フロー 新機能を追加する際の典型的なタスクの流れは以下の図のようになっています。 図の内容を説明します。 まず、Design Docを記述します。 Design Docには、その機能がなぜ必要なのか、ユーザ目線でどのような動作が提供されるのか、実装の設計と理由、などを記載します。 記述自体の時間に加えてチームでのレビューも行うためそれなりの時間を要しますが、これを書くことでチーム内で機能に対するイメージがはっきりし、結果的に開発効率がよくなります。 次に、gRPCインタフェースを定義します。 前節のアーキテクチャ図にあるように、Klein-2022ではバックエンド↔︎BFF間の通信をgRPCで行なっています。 従って、gRPCのインタフェースを先に定義しておくことで、この先のタスクを並行して行うことができます。 gRPCが定義できたら、並行して以下の2つのフローでタスクを行います。 Rust: データベースマイグレーション → バックエンド実装 → 統合テスト実装 TypeScript: BFF実装 → フロントエンド実装 ※「統合テスト」は、バックエンドのgRPCを実際に呼び出して、データベース・バックエンド・gRPCが意図通りに動作するかを確認するテストです。 自分はReactやTypeScriptにはあまり明るくなかったので、gRPCの定義をやった後に、TypeScriptのタスクは他メンバーにお任せしてRustのタスクをやることが多かったです。 上のタスクが全て終わったら、最後に他の方に動作確認をお願いします。 問題なく動作すれば、機能開発は完了です。 チーム開発の進め方 前節でタスクの分解方法を説明したので、分解されたタスクの進め方も含めて、チーム開発がどう動いていたかを説明します。 CADDiではスクラム開発を採用しており、スプリント期間は2週間です。 スプリント開始は水曜日で、この日にはスプリントゴールや扱うユーザーストーリーを決めるスプリントプランニングを行います。 スプリントプランニングでは、各ストーリーのDoD（完了の定義）やストーリーポイント（ストーリーの規模を数値化したもの）についてチームで議論します。 議論してみると、当初自分が想定していたよりも実装する内容が多かったり波及範囲が大きかったりすることが他メンバーの指摘によってわかることがあります。 こういったことが開発中に判明すると大変なので、ここで先んじて議論しておくことは開発効率の向上につながります。 スプリントプランニングの中で、ストーリーは前節で説明したようなタスクに分解されます。 タスクの割り当ては、スプリントゴール達成のために必要な優先順位をチームで議論しながら、優先順位やメンバーごとの得意分野を踏まえてタスクを取っていく形で行われます。また、手が空いたら随時未割り当てのタスクを取ることになります。 私はバックエンド側のタスクを取ることが多かったですが、インターン終盤ではBFFのタスクや簡単なUIの修正（文言の修正、GraphQLの修正などReactがあまり絡まないもの）も取るようになりました。 タスク（特にDesign Doc）を進めていくと、ストーリーの必要性や実現したいことがエンジニアにとって明確でないことがあり、その場合はユーザーやPdM（プロダクトマネージャー）に質問することになります。 Klein-2022は社内で使用される製品なのでユーザは社員です。そのため、ユーザ・PdMどちらに対しても質問は社内Slack・Discordで行うことができます。 インターン中に私からPdMに質問をする機会が何度かありました。質問をするには当然ながら機能の深い理解と機能にからむドメインの知識が必要となるので、働く期間の短いインターンにとっては難しい部類の仕事だと思います。ただ、チームメンバーに相談することで理解・知識は補えるので無理な仕事ではなく、また質問のために勉強することで機能やドメインへの理解が深まることになります。 自分のタスクを処理する他に、自分以外のチームメンバーが出すプルリクエスト（PR）のレビューをすることも日常的に行いました。 PRを作成する際には、チームメンバーのランダムな3人（GitHubの機能で選ばれる）にレビューを依頼することになっています。 幸いなことに私はある程度Rustの経験があったので、レビューを通してRustの経験が比較的浅いチームメンバーの手助けをするという貢献ができました。 以上に述べたチームの動き方はインターンだからといって特別ということはなく、一般のチームメンバーと同じものです。 インターンの感想 初めて大規模な業務コードに携わることとなりましたが、コードの構成が整っているおかげで、数万行規模のコードを触るのも苦になりませんでした。また、バックエンドが日頃から愛好しているRustで書かれていることもあり、事前の想定通り楽しんで開発を行うことができました。 インターン用の特別なタスクというものはなく、普通のチームメンバーと同じタスクを扱いました。ドメイン知識が必要で手ごわいタスクもありましたが、チーム内でDiscordを使って気軽に相談・質問できる体制があり、非常に助かりました。 日頃から技術に関しては色々勉強をしていたとはいえチーム開発の経験はなく、自分の能力でチームに貢献できるか不安がありました。しかし業務に関わっていくうちにチームメンバーから「積極的にタスクを取っていく姿勢がよい」「インターンの枠に収まらず戦力として役に立っている」などといった評価をいただくことができ、自分の能力に自信が持てるようになりました。 最後に 暖かいチームと整理されたコードに迎えられ、実りあるインターンをさせていただくことができました。 Klein-2022チームの皆様、CADDiの皆様、3ヶ月間ありがとうございました！ ここまでお読みいただきありがとうございました。キャディにご興味のある方は、お気軽に 求人ページ からカジュアル面談をお申し込みください。また、 各種エンジニア向けイベント も随時開催しています。こちらもぜひご覧ください。

CloudFlare for application 入門 はじめまして、キャディでバックエンドエンジニアをやっている矢野です。 CloudFlareについて、2022年5月24日に開催された社内勉強会で発表させていただきました。 CDNで有名なCloudFlareですが、CDN以外のサービスの展開が最近活発です。 先日サーバレス向けのデータベースD1のプレスリリースが出ていたりと、その背景を含めて最近のCloudFlareの動向についてキャッチアップしました。 [toc] CloudFlareとは CloudFlareのHP によると、以下のように記載されています。 　CloudFlareは、インターネット上で運営されている最大のネットワークの1つです。ユーザーは、Webサイトやサービスのセキュリティとパフォーマンスを向上させる目的でCloudFlareサービスを利用しています。 CloudFlareの特徴 大まかな特徴は以下のようになります。 このうち「CDNサーバによるエッジコンピューティング」を中心に解説していきます。 セキュリティ 信頼性 ゼロトラスト DNS DDoS攻撃対策 CDNネットワーク CDNサーバによるエッジコンピューティング　 ←★今回はココを中心 サーバレス 安価に始められる エッジコンピューティング（Edge Computing）とは 「Edge」とはコンピューティングモデルの1つで、Device Locally、Edge Server、IoTなどユーザーの身近なものにアクセスするイメージです。 反対に、Cloud や Origin Server など物理的に遠い場合は「Edge」とは呼びません。 「Edge」と聞いたら「ユーザーに近い」イメージ CDN Edge server とは Device Locally、Edge Server、IoTなど ユーザーの身近にあるもの からつながっているルータやISPに位置しているCDNのことを「Edge Server」と呼んでいます。 CloudFlare services の変遷 下の画像は、CloudFlareの管理画面のサイドバーにある機能とローンチされた年度の一覧です。 結構ここ数年で次々と新たなサービスが開発されているのがわかります。 CloudFlare workers CloudFlare workersとは エッジサーバで実行されるサーバレス実行環境(FaaS)です。 無料枠では、リクエストあたりのCPU時間に制限があります。 CloudFlare workersの特徴 エッジサーバで実行されるためスケールする Service Worker APIに似たAPIで記述 JS（TS）, Rust, C, C++ etc...が使える ローカル開発環境が充実 Cacheが利用可能 WorkersとPagesの料金設定 | CloudFlare キャッシュ CloudFlare workersで使えるキャッシュは大きく分けて以下の3つがあります。 それぞれ特徴が分かれているので、おさえておきましょう。 後で紹介するデモでは「Workers KV」を使います。 Workers KV 読み取り頻度が高い場合向け 書き込みに関しては、すべてのエッジサーバに伝搬するのに最大で60sかかる アトミックな操作はできない Durable Objects 遅延が少なく、強整合性を持つKV リアルタイム性を要求するアプリケーションでも利用可能(e.g. WebSocket) 有料（$5~） Cache API それぞれのエッジサーバのローカルに保存される ブラウザのCache APIと同じインタフェース Cacheが有効なのはサイトの配下のみ（ワーカのAPIそのものには効かない） CloudFlare R2 Storage Object Storageのことで、データ転送量（下り）が無料という特徴があります。 「R2」という名前のとおり「S3」と対抗している雰囲気があり、R2の特徴は以下になります。 S3のAPIと完全互換性がある Really Requesテーブル（真にリクエスト可能な） Repositioning Records（レコードを再配置する） Ridiculously Reliable（途方もなく信頼できる） Radically Reprogrammable（根本的に再プログラム可能な） 参照： CloudFlare R2ストレージの発表 - 高速で信頼できるオブジェクトストレージ、エグレス料金なし Tools for developer 今回使った開発ツールを紹介します。 Wrangler v2 CloudFlare Workers用のCLI https://github.com/cloudflare/wrangler v2からminiflare(simulator)を内蔵 console.logデバッグができるの便利 hono CloudFlare Workers向けのweb framework https://github.com/honojs/hono ローカル開発はwranglerで完結 実際のコマンドは以下にあるものでほぼすべてになります、非常にシンプルです。 $ yarn add global wrangler $ wrangler login $ wrangler kv:namespace create "SAMPLE_KV" $ wrangler r2 bucket create images $ npx wrangler init XXX $ npm install hono $ wrangler dev # Coding... $ wrangler publish 簡易アプリ作成 やっていることは以下のとおりで、 URL を押下するとかわいい猫が見られます。 R2に保存された画像データを取得 R2から一覧を取得して表示 Workers KVでキャッシュ Get R2 object R2でやっているオブジェクトの取得コードは以下になります。 import { Hono } from "hono"; const app = new Hono(); app.get("/image/:id", async (c) => { const key = c.req.param("id"); const object = await BUCKET.get(key); if (!object) { return c.text("Image Not Found", 404); } const body = await object?.arrayBuffer(); c.header("Content-Type", object.httpMetadata.contentType!); return c.body(body); }); app.fire(); R2やWorkers KVの設定 このうち BUCKET .get には下準備が必要です。 1つ目の準備は、型定義です。 xxx.d.ts declare global { const BUCKET: R2Bucket; const SAMPLE_KV: KVNamespace; } 型定義のあと wrangler.toml に設定を書きます。 wrangler.toml name = "cloudflare-worker-demo" main = "src/index.ts" compatibility_date = "2022-05-23" kv_namespaces = [ { binding = "SAMPLE_KV", id = "xx", preview_id = "yy" } ] [[r2_buckets]] binding = 'BUCKET' bucket_name = 'images' preview_bucket_name = 'images' List view 結果の猫一覧は以下のように書いています。 const imageTag = (img_path: string) => { return `<img src="${img_path}" />`; }; app.get("/", async (c) => { const list = await BUCKET.list(); const keys = list.objects.map((headResult) => headResult.key); return c.html(keys.map((k) => imageTag(`/image/${k}`)).join("")); }); Workers KV キャッシュ キャッシュはこのようになります。 // check cache const kv_cache = await SAMPLE_KV.getWithMetadata<Metadata>(key, { type: "arrayBuffer", }); if (kv_cache.value && kv_cache.metadata) { const body = kv_cache.value; const contentType = kv_cache.metadata.contentType; c.header("Content-Type", contentType); return c.body(body); } const object = await BUCKET.get(key); // ... // save cache c.event.waitUntil( SAMPLE_KV.put(key, body, { metadata: { contentType } }) ); 初回キャッシュ時とそれ以降とではずいぶん落ち着いていることが確認できます。 終わりに CloudFlareを使うと、手軽にAPIやサーバを立てられることを体感できました。 CloudFlareでは、今回使用したWorkers KVしか提供していませんでしたが、最近「CloudFlare D1」分散RDBを出してきました。 競合はSpannerやCockroach DB等と考えられるのですが、サーバレスかつエッジネットワーク上で整合性を保つRDBは結構特徴的な位置付けになりそうです。 コスト面はR2と同じくデータ転送に対する課金はなく、割と安価にサービスを提供されると予想されます。 ここまでお読みいただきありがとうございました。キャディにご興味のある方は、お気軽に 求人ページ からカジュアル面談をお申し込みください。また、 各種エンジニア向けイベント も随時開催しています。こちらもぜひご覧ください。 参考資料 CloudFlare本家 - CloudFlare - Webパフォーマンスとセキュリティを追求する企業 | CloudFlare - エッジコンピューティングとは？ | CloudFlare - D1を発表：当社初のSQLデータベース DevelopersIO - CloudFlareのR2ストレージ | DevelopersIO - [速報] CloudFlare のエッジ環境で使用できる SQL データベース D1 が発表されました！ | DevelopersIO Others - CloudFlare Workers メモ - CloudFlare R2の画像をCache APIでキャッシュして返すメモ - CloudFlare R2もいいぞ！ - ゆーすけべー日記 - Remix on CloudFlare WorkersからCloudFlare R2を使う | DevelopersIO

はじめに 現在の8つの挑戦と未来の8つの挑戦 本記事は、以前公開した CADDi Tech 現在の8つの挑戦と未来の8つの挑戦 というコンテンツをより深くご理解いただくために、キャディのメンバーがそれぞれの挑戦の目的や意図を説明する連載記事となっています。 第一回は 「現在の挑戦 01」として「グローバルカンパニーになるための開発体制のグローバル化と多言語化」をテーマに、ベトナムオフィスでベトナムエンジニアリングチームの立ち上げを行っている佐藤がお届けします。 キャディビジネスのグローバル化 キャディは「モノづくり産業のポテンシャルを解放する」をミッションとして、製造業の変革を行おうとしています。創業からこれまでの間は日本のお客様、日本の製造パートナーの方々と取引をさせていただいていて、「日本」の製造業を変革するスタートアップ企業と思われていたのではないでしょうか。 ですが、我々は元々日本に閉じこもるつもりはなく、世界中の製造業を変革する最初の地として日本でビジネスをしていました。そしてようやく準備が整ってきたので、この春から海外展開の第一歩としてベトナムのホーチミン市に初の海外オフィスを設立しました（ プレスリリース ）。ここを拠点に、ビジネスとテクノロジーの両輪でグローバル化を進めていくのですが、この記事ではテクノロジーのグローバル化についてお話したいと思います。 キャディの技術開発のグローバル化 なぜ開発組織をグローバル化させるのか キャディはビジネスをグローバル化するだけでなく、技術開発もグローバル化しようとしています。その理由は大きく以下の3つになります。 1. 様々な能力を持つ優秀なソフトウェアエンジニアをより多く確保すること。 2. グローバルで活躍できる優秀なソフトウェアエンジニアを確保すること。 3. ビジネスの現場に近い場所に優秀なソフトウェアエンジニアを確保すること。 優秀なソフトウェアエンジニアをより多く確保する 日本のITエンジニアの人口は約120万人と言われています。この数はまだ増加していますが、日本の人口が減少し高齢化が進む中で、キャディの求めるソフトウェア開発のできるエンジニアを日本だけで確保するのは難しくなっています。さらにITエンジニアに対する需要が供給を上回っていて、給与レベルが他の職種と比べて高騰している状況もあります。そのため、エンジニアの採用は簡単ではありません。 一方で、日本の国外に目を転じてみると、全世界でおよそ2,300万人ほどのITエンジニアがいます。その中で、キャディと技術の志向性が合っていてキャディに興味をもっていただける方は限られていると思いますが、日本だけで探すよりは確実に多くの方に出会えると考えています。 グローバルで活躍できるソフトウェアエンジニアの確保 ビジネスがグローバル展開するにしたがって、キャディのビジネスを支える製造業受発注プラットフォームもまたグローバル対応が求められます。それは単純なUIの多言語対応ということだけではなく、長さ重さなどの単位の違いや通貨の違い、さらに各国の商習慣の違いなどによって、システムに対する新たな要求が世界中からやってくるようになります。 その多くは、1つの国だけであれば考慮する必要のない「余計な機能」という風に見えてしまうかも知れません。グローバル化の機能を追加することで、システムの複雑性が増し、テストも大変になり、不具合の可能性も高まります。 ただ、それはビジネスをグローバルに展開しより多くの人たちに我々のソフトウェアを使ってもらうためには必要なことです。そして、その開発に携わるエンジニアには、異なる国や地域の人たちとのコミュニケーションを円滑に進められること、そして異なる要求を理解しできるだけ整合性を保ちながらシステム上で実現していくことが求められます。 もちろん国内にもそういうエンジニアはいますが、日本は内需がそこそこ大きいので国内向けの開発だけをされている方が主流ではないでしょうか。海外には自国外のユーザーのためのソフトウェア開発を中心に行っているエンジニアが多くいて、キャディはそういった方々を積極的に採用していきたいと考えています。 ビジネスの現場に近い場所にソフトウェアエンジニアを確保する キャディのビジネスがグローバル展開することで、「現場」も海外に散らばっていきます。つまり、実際の製造が行われる製造パートナーや調達を行う顧客が海外に存在することになります。そしてその受発注のオペレーションを行うキャディ内部のメンバーも必然的に世界に広がっていくことになります。 上記で述べたように、それぞれの地域で異なる事情があり、システムに対する要件も多岐にわたります。グローバルな感覚を持ったエンジニア集団がそれを集約してシステムに反映させていくということは当然やるのですが、それだけだとどうしてもスピード感が失われることがあります。 それを補うために、開発エンジニアが現場に近いところにいてクイックに開発を進められる体制も同時に作りたいと考えています。実感をもって課題解決に取り組むためには「現場」に出向いて実際に見て聞いて感じる、そして時に質疑応答をして理解を深めていくことが大切です。それをするためには、現場の近くにいて、現地の言葉を話せるエンジニアが必要で、そこで見聞きしたことを即座にシステムに反映させ、PDCAのサイクルを高速にまわしていきたいと考えています。 そのようにして作られたシステムは最初はその地域に特化したようなソリューションかも知れませんが、他の地域でも意外と同じ課題を抱えていたりするので将来的に横展開もしていけます。例えば、ベトナムのチームで開発したソリューションが日本のパートナー工場で使われるようになるという流れもできるかも知れません。これも海外に拠点を構えてエンジニアリングチームを作る理由の1つになります。 グローバル化の2つの軸 キャディの開発組織のグローバル化を考えた時に2つの軸があります。 1つは国内の開発組織に外国出身の方々に入ってきてもらうことです。日本人中心の組織から非日本語話者のメンバーも含めた混成のチームに変わることで日本国内組織のグローバル化を促進します。もう1つは海外に開発拠点を構えてそこでローカルの優秀なエンジニアに入ってきてもらうこと。そしてそれらのメンバーが日本のメンバーとやり取りをしながら組織全体でのグローバル化を促進する。ホーチミン市のオフィスはその第一弾ということになります。 多言語化 この2つの軸で組織のグローバル化を促進した場合に一番問題になるのは言語です。我々は基本となるコミュニケーションの言語は英語と考えています。では流暢に英語が話せなかったら仕事ができなくなるのか、そんなことは無いです。うまく話せないのであれば書けばよいし、うまく書けないのであれば機械翻訳に頼るでも良いと思います。 必要なことは「伝えること」で、複雑な文章を書いたり、込み入った話をする必要はないです。「日本語ならもっとニュアンス含めて伝えられるのに」ということもあると思いますが、込み入った話はだいたい日本語でも伝わっていない。 大切なのは相手に伝わること。読んだり聞いたりする相手の立場でシンプルに必要なことを伝える。相手も日本人同様、英語が必ずしも得意ではない人たちかも知れないので、それを念頭に置いて伝えるということが大切だと思います。 メルカリの方が「やさしいコミュニケーション」という考え方を提唱していますが、まさに、お互いに歩み寄ってコミュニケーションすることが必要です。英語が話せる人はできるだけわかりやすい英語を心がけて、「英語が共通言語なんだからわからない奴が悪い」という雰囲気を作らないようにしなければなりません。 そして「シンプルなコミュニケーション」というと要件だけを伝えるみたいに聞こえてしまうかも知れないですが、自分も相手も、感情のある生身の人間でです。例えば、相手に感謝を伝えること、相手を褒めること、苦労をねぎらうこと、などもコミュニケーションの中で忘れないようにしたいです。 英語習得のトレードオフとコツ 「英語で仕事をすることになると効率が落ちる」と言う方がいます。そしてそれはほとんどの日本人にとっては事実だと思います。また「英語の勉強する時間があったら、技術の習得に時間を使いたい」というエンジニアの方もいらっしゃるでしょう。それはそれで一理あると思います。 ただ、インターネットによって国境を超えて人と人が繋がるようになり、国を超えた人材採用も活発に行われています。我々もその流れで国外の多くの方に応募していただいていますが、本当に思いもしない国々からのお声がけもあります。日本国内でもキャディと同様に外国人の採用を積極的に進めている開発組織の話もよく聞きます。 そんな中で、エンジニアとして「日本語環境」という縛りを持ち続けて技術だけで勝負し続けるのか、海外の人材と一緒に働くあるいは海外で働くという選択肢を持つのか。それを自分のキャリアパスを考える時に意識すべきだと考えていて、それに応じて自分の時間の優先度を判断していくのかなと思います。 なお、「必要に迫られないとなかなか時間を割けない」という方もいます。これもまた事実なのですが、実はこの半分くらいの人は必要に迫られてもなかなかできない。何かと言い訳をして（「効率が落ちる」とか「こちらの優先度が高い」とか）、取り掛かろうとしない。まあ、夏休みの宿題と一緒ですね（笑）。 なので、取り敢えずそういう環境に身を置いて、あとは積極的にやってみるしかないかなと思います。今は昔と比べて便利なツールもたくさんあるわけで、そういうのを使いこなすのもテクニックの1つになるのだと思います。 そして、本当に大切なのは英語を読んだり書いたり話したり聞いたりすることじゃなくて、どうやったら相手に伝えられるのか、どうやったら相手の言いたいことを理解できるのか、そのコツを掴むことなのかなと思います。私もまだ全然できていると思っていません。でも、長い間やってきて、だいぶ遠回りした気もしますが、ある程度蓄積するものができてきて、ようやく伝えたいことをだいぶ伝えられるようになってきたかなと思います。 今後に向けて 組織のグローバル化を一緒に考えて行動する仲間を探しています キャディのグローバル化と多言語化について、現時点での考えを共有させていただきました。冒頭に書いたとおり、キャディのグローバル化は今まだ始まったばかりです。今後、ここで書かれている事が微修正されたり方向転換されたりということも出てくると思います。むしろ、グローバル化の取り組みをしながら積極的にここに知見を追加していきたいと考えています。それを我々と一緒にやっていただけるメンバーを探しています。 エンジニアとして海外メンバーと一緒に働いてみたいという方もいるでしょうし、マネジメント的な立場で組織拡大にチャレンジしてみたいという方もいらっしゃるでしょう。ご興味のある方は、お気軽に 求人ページ からカジュアル面談をお申し込みください。ここでは語りきれない現実の諸々もお話できると思います。または 各種エンジニア向けイベント も随時開催しています。こちらもぜひご覧ください。

はじめに builder マクロを作る（続き） 06-optional-field 目標 実装方針 実装 ガード節で Optional でない型のみエラーを出すようにする Optionでラップされた型はアンラップしてCommandBuilder構造体のフィールドで保持する Optional な型の setter メソッドはラップされた中身の型を引数として受け付けるようにする is_optionとunwrap_optionの実装 is_option関数 unwrap_option関数 AngleBracketed(AngleBracketedGenericArguments) リファクタリング 07-repeated-field 目標 実装方針 実装 Builder 構造体のフィールドではVec型の変数はOptionでラップしない is_vectorとunwrap_vectorの実装 フィールドに付与されたアトリビュートを取得する List Meta(Meta) Lit(Lit) Vec型のフィールドの setter を一括更新用と要素追加用の 2 種類生成する 08-unrecognized-attribute 目標 実装方針 実装 09-redefined-prelude-types 目標 実装方針 実装 まとめ 参考文献 はじめに 前編 では、 setter メソッドによる値の設定や build メソッドによる構造体の生成などの基本的な機能を持った手続き的マクロを実装しました。後編では以下の機能を実装していきます。 Optional な値を構造体のフィールドとして持てるようにする 以下の 2 つの方法で Vec 型のフィールドを更新できるようにする ベクタを与えて一括で更新する ベクタの要素を与えて 1 つずつフィールドに要素を追加する コンパイルエラーが発生した際にわかりやすいメッセージを表示する builder マクロを作る（続き） 06-optional-field 目標 構造体のフィールドとして Optional な値を持てるようにする Optional なフィールドには値が入っていなくても build メソッドで構造体を生成できる Optional でないフィールドは値が入っていないと build メソッドで構造体を生成できない Optional なフィールドは Some でラップせずに中身の値をそのまま使って初期化できる 最後の項目についてですが、たとえば Command 構造体が以下のようになっている場合、 pub struct Command { executable: String , args: Vec < String > , env: Vec < String > , current_dir: Option < String > , } current_dir は以下のように String を渡すだけでよいということです。 let command = Command :: builder () . executable ( "cargo" . to_owned ()) . args ( vec! [ "build" . to_owned (), "--release" . to_owned ()]) . env ( vec! []) . current_dir ( ".." . to_owned ()) . build () . unwrap (); 実装方針 目標とする機能を実現するために実装する必要があるのは以下の項目です。まずはこれらの機能を実装していきましょう。 ガード節で Optional でない型のみエラーを出すようにする Option でラップされた型はアンラップして CommandBuilder 構造体のフィールドで保持する 今は元の型が何であっても Option でラップするようになっています。そのため、Optional な型は Option<Option<_>> のようになります。このままだと扱いづらいので、Optional な型はいったんアンラップして、すべてのフィールドの型が Option<_> になるようにします Optional な型の setter メソッドはラップされた中身の型を引数として受け付けるようにする 実装 実装方針で説明した機能を実装していきます。 ガード節で Optional でない型のみエラーを出すようにする ガード節を生成する部分の実装は以下のようになっています。今はすべてのフィールドに対して None であるかのチェックを生成しています。これを Optional でない型のみガード節を生成するように変更します。 let checks = idents. iter (). map ( | ident | { let err = format! ( "Required field '{}' is missing" , ident. to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()) } } }); Optional でないフィールドのみガード節を生成するためには、各フィールドの型を見て Optional でないフィールドのみをフィルタすれば良さそうです。 types に各フィールドの型が格納されているので、以下のように filter を用いて Optional でないフィールドの識別子についてだけガード節を生成します。 is_option は与えられた型が Optional であるかどうかを判定する何らかの関数です。のちほど実装します。 let checks = idents . iter () . zip ( & types) . filter ( | (_, ty) | ! is_option (ty)) . map ( | (ident, _) | { let err = format! ( "Required field '{}' is missing" , ident. to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()) } } }); Option でラップされた型はアンラップして CommandBuilder 構造体のフィールドで保持する 今の Builder 構造体の定義は以下のようになっています。すべてのフィールドを Option でラップしています。Optional なフィールドについては、あらかじめ Option でラップされた型を取り出しておけば、あとの処理は今までと同じ内容になります。 #vis struct #builder_name { #( #idents : Option < #types > ), * } 実際に実装していきます。 Option の中身の型を取り出すなどの処理が追加されるので、生成された Builder 構造体のフィールドを builder_fields にいったん保持してあとで展開しましょう。 builder_fields の実装は以下のようになります。 unwrap_option 関数で Option にラップされている型を取り出している以外は今までと同じです。 unwrap_option は is_option と同じくのちほど実装します。 let builder_fields = idents. iter (). zip ( & types). map ( | (ident, ty) | { let t = unwrap_option (ty). unwrap_or (ty); quote! { #ident : Option < #t > } }); builder_fields は Builder 構造体の定義を生成する部分で展開します。 #vis struct #builder_name { #( #builder_fields ), * } Builder 構造体の定義が変わったため build 関数も変える必要があります。今は以下のように目的の構造体を生成する際にすべてのフィールドを unwrap していますが、Optional なフィールドは unwrap する必要がないのでそのまま返すようにしましょう。 pub fn build ( &mut self ) -> Result < #ident , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #ident { #( #idents : self . #idents . clone (). unwrap ()), * }) } Optional なフィールドかどうかを判定する処理が追加されるため、 builder_fields と同様に別の変数に格納してのちほど展開します。具体的な実装は以下の通りです。 is_option で Optional なフィールドかどうかを判定して、Optional であれば値をそのまま使用し、Optional でなければ unwrap して得られた値を使用します。 let struct_fields = idents. iter (). zip ( & types). map ( | (ident, ty) | { if is_option (ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); struct_fields は build 関数の中で展開します。 pub fn build ( &mut self ) -> Result < #ident , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #ident { #( #struct_fields ), * }) } Optional な型の setter メソッドはラップされた中身の型を引数として受け付けるようにする 今の setter の実装は以下のようになっています。Optional なフィールドかどうかは関係なく、すべてのフィールドについてそのフィールドの型をそのまま受け付けるようになっています。 impl #builder_name { #( pub fn #idents ( &mut self , #idents : #types ) -> &mut Self { self . #idents = Some ( #idents ); self }) * ... つまり Optional なフィールドについては以下のような setter が生成されます。これでは Builder 構造体のフィールド定義と矛盾します。そのため、Optional なフィールドの setter 関数は引数として Option の中身の型を受け取るようにします。 pub fn current_dir ( &mut self , current_dir: Option < String > ) -> &mut Self { self .current_dir = Some (current_dir); self } 具体的には以下のような setter を作って展開するように書き換えます。Builder 構造体のフィールドと同様、 unwrap_option 関数を使って Option でラップされた中身の型を取り出します。 let setters = idents. iter (). zip ( & types). map ( | (ident, ty) | { let t = unwrap_option (ty). unwrap_or (ty); quote! { pub fn #ident ( &mut self , #ident : #t ) -> &mut Self { self . #ident = Some ( #ident ); self } } }); ... impl #builder_name { #( #setters ) * ... is_option と unwrap_option の実装 is_option と unwrap_option を実装していきます。まずは is_option 関数から実装していきましょう。 is_option 関数 is_option は Type 型を受け取ってそれが Option かどうかを判定する関数なのでシグネチャは以下のようにすれば良さそうです。 fn is_option (ty: & Type) -> bool ty が Option かどうか判定するのに使えそうな Type のメソッドがあるか確認してみましょう。 syn クレートのドキュメント を確認したところ Type は以下の enum のようです。 pub enum Type { Array (TypeArray), BareFn (TypeBareFn), Group (TypeGroup), ImplTrait (TypeImplTrait), Infer (TypeInfer), Macro (TypeMacro), Never (TypeNever), Paren (TypeParen), Path (TypePath), Ptr (TypePtr), Reference (TypeReference), Slice (TypeSlice), TraitObject (TypeTraitObject), Tuple (TypeTuple), Verbatim (TokenStream), // some variants omitted } Option がどのバリアントに分類されるかはまだわかりませんが、とりあえずパターンマッチで処理すれば良さそうです。 fn is_option (ty: & Type) -> bool { match ty { todo! () } } パターンマッチで分類できそうだというところまで方針を立てられましたが、 Option はどのバリアントに分類されるのでしょうか。ドキュメントを一見してもそれらしいものは見当たりませんが、 Option は Type::Path(syn::TypePath) に分類されます。 TypePath は std::iter::Iter のような Path をパースして得られる構造体です。 Type::Path にマッチしないバリアントについてはこの時点で false を返してしまって問題ないでしょう。 fn is_option (ty: & Type) -> bool { match ty { Type :: Path (path) => todo! (), _ => false } } TypePath には Option 以外にも上述の std::iter::Iter のようなものも含まれます。どのように Option かそれ以外かを判定すれば良いでしょうか。 先ほども説明したように、 TypePath は std::iter::Iter のようにコロン 2 つで分割されたセグメントの集合でした。つまり、セグメントの集合の最後の要素が Option であるかどうかを判断すれば良さそうです。 では、どのようにしてセグメントの集合の最後の要素を取得すれば良いのでしょうか。 syn::TypePath は以下のような構造体で、 path に Path の情報を保持しています。 syn::Path は以下のように segments にセグメントの集合を保持しており、 segments.last() で最後の要素にアクセスできます。 pub struct TypePath { pub qself: Option < QSelf > , pub path: Path } pub struct Path { pub leading_colon: Option < Colon2 > , pub segments: Punctuated < PathSegment, Colon2 > , } 上記を踏まえると、現時点での実装は以下のようになります。 fn is_option (ty: & Type) -> bool { match ty { Type :: Path (path) => path.path.segments. last (), _ => false } } 最後に、セグメントの最後の要素の識別子が Option と一致するか比較する必要があります。 segments.last() の戻り値は PathSegment 型 であり、 ident フィールドから識別子にアクセスできます。この識別子が Option かどうかを比較すれば良さそうです。 最終的な is_option 関数の実装は以下のようになります。 fn is_option (ty: & Type) -> bool { match ty { Type :: Path (path) => match path.path.segments. last (). unwrap () { Some (seg) => seg.ident == "Option" , None => false }, _ => false } } unwrap_option 関数 次は unwrap_option 関数を実装してきます。 unwrap_option 関数は与えられた型が Option であれば Some(型) を返し、そうでなければ None を返す関数なので、シグネチャは以下のようにすれば良いでしょう。 fn unwrap_option (ty: & Type) -> Option < & Type > 引数が Option でない場合は None を返します。引数が Option かどうかは先ほど実装した is_option 関数が使えます。 fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } todo! () } 次に Option にラップされた中身の型を取り出す処理を実装します。中身の型はどうやって取り出せば良いでしょうか。 is_option の実装ででてきた PathSegment のフィールドには ident 以外にもう 1 つ arguments というのがありました。これが関係ありそうなので、 PathArguments の定義を見て見ましょう。 pub enum PathArguments { None , AngleBracketed (AngleBracketedGenericArguments), Parenthesized (ParenthesizedGenericArguments), } PathArguments は enum のようです。バリアント名を眺めてみると AngleBracketed というものがあります。これが関係ありそうです。実際、 ドキュメント の AngleBracketed の項目には以下のように記載されており、このバリアントがジェネリック引数の情報を持っていることがわかります。 AngleBracketed(AngleBracketedGenericArguments) The <'a, T> in std::slice::iter<'a, T> . syn::AngleBracketedGenericArgument 型の定義を見てみましょう。 pub struct AngleBracketedGenericArguments { pub colon2_token: Option < Colon2 > , pub lt_token: Lt, pub args: Punctuated < GenericArgument, Comma > , pub gt_token: Gt, } フィールド名を眺めてみるとジェネリック引数の型は args に入っていそうです。 syn::Punctuated なので複数の要素がありそうですが、 Option は引数を 1 つしか取らないので first() で取得すれば良いでしょう。 fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } match ty { Type :: Path (path) => path.path.segments. last (). map ( | seg | { match seg.arguments { PathArguments :: AngleBracketed ( ref args) => args.args. first (), _ => None } }), _ => None } } args.first() の戻り値は Option<GenericArgument> です。 GenericArgument は以下のような enum で、型が含まれる場合は GenericArgument::Type バリアントが使用されるので、 Type バリアントにマッチさせれば良いでしょう。 pub enum GenericArgument { Lifetime (Lifetime), Type (Type), Binding (Binding), Constraint (Constraint), Const (Expr), } 上記を踏まえると、 unwrap_option の最終的な実装は以下のようになります。 fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } match ty { Type :: Path (path) => path.path.segments. last (). map ( | seg | { match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None } }), _ => None } } Path の最後の要素を持ってくる処理はまとめられるので別の関数として外に切り出します。これを用いて is_option と unwrap_option を書き直すと、最終的には以下のようになります。 fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } 最終的な実装は以下のようになります。 use proc_macro :: TokenStream; use quote :: {format_ident, quote}; use syn :: { parse_macro_input, Data, DeriveInput, Fields, GenericArgument, Ident, PathArguments, PathSegment, Type, }; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; let builder_fields = idents. iter (). zip ( & types). map ( | (ident, ty) | { let t = unwrap_option (ty). unwrap_or (ty); quote! { #ident : Option < #t > } }); let checks = idents . iter () . zip ( & types) . filter ( | (_, ty) | ! is_option (ty)) . map ( | (ident, _) | { let err = format! ( "Required field '{}' is missing" , ident. to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()) } } }); let setters = idents. iter (). zip ( & types). map ( | (ident, ty) | { let t = unwrap_option (ty). unwrap_or (ty); quote! { pub fn #ident ( &mut self , #ident : #t ) -> &mut Self { self . #ident = Some ( #ident ); self } } }); let struct_fields = idents. iter (). zip ( & types). map ( | (ident, ty) | { if is_option (ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); let expand = quote! { #vis struct #builder_name { #( #builder_fields ), * } impl #builder_name { #( #setters ) * pub fn build ( &mut self ) -> Result < #ident , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #ident { #( #struct_fields ), * }) } } impl #ident { pub fn builder () -> #builder_name { #builder_name { #( #idents : None ), * } } } }; proc_macro :: TokenStream :: from (expand) } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } リファクタリング derive 関数が肥大化してきたので内部の処理を関数として切り出しました。主な変更点は以下の通りです。 Builder 構造体の定義を生成する部分を関数化（ build_builder_struct ） Builder 構造体の実装（setter 関数、 build 関数）を生成する部分を関数化（ build_builder_impl ） builder 関数を生成する部分を関数化（ build_struct_impl ） これらの関数はすべて戻り値として proc_macro2::TokenStream を返していますが、これは quote マクロが proc_macro2::TokenStream を返すためです。 これらの処理を関数化したのに伴い、もともと以下のようにフィールド名と型を最初に取得していたのを、 let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; 以下のように NamedFields を取得して各関数にわたすように変更しています。 let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "this macro can be applied only to structaa" ), }; リファクタリング後の実装は以下の通りです。 use proc_macro2 :: TokenStream; use quote :: {format_ident, quote}; use syn :: { parse_macro_input, Data, DeriveInput, Fields, FieldsNamed, GenericArgument, Ident, PathArguments, PathSegment, Type, Visibility, }; #[proc_macro_derive(Builder, attributes(builder))] pub fn derive (input: proc_macro :: TokenStream) -> proc_macro :: TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "this macro can be applied only to structaa" ), }; let builder_struct = build_builder_struct ( & fields, & builder_name, & vis); let builder_impl = build_builder_impl ( & fields, & builder_name, & ident); let struct_impl = build_struct_impl ( & fields, & builder_name, & ident); let expand = quote! { #builder_struct #builder_impl #struct_impl }; proc_macro :: TokenStream :: from (expand) } fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let (idents, types): ( Vec < & Ident > , Vec < & Type > ) = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . unzip (); quote! { #visibility struct #builder_name { #( #idents : Option < #types > ), * } } } fn build_builder_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let checks = fields .named . iter () . filter ( | field | ! is_option ( & field.ty)) . map ( | field | { let ident = field.ident. as_ref (); let err = format! ( "Required field '{}' is missing" , ident. unwrap (). to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()); } } }); let setters = fields.named. iter (). map ( | field | { let ident = & field.ident; let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = Some ( #ident ); self } } }); let struct_fields = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); if is_option ( & field.ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); quote! { impl #builder_name { #( #setters ) * pub fn build ( &mut self ) -> Result < #struct_name , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #struct_name { #( #struct_fields ), * }) } } } } fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); quote! { #ident : None } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } 07-repeated-field 目標 以下の 2 つの方法でベクタを値としてもつフィールドを更新できるようにする ベクタを与えて一括で更新する ベクタの要素を 1 つずつ追加する 一括で更新するための関数名はフィールド名と同じにする ベクタの要素を 1 つずつ追加する関数の名前は以下のようにアトリビュートを用いて指定する 1 つずつ追加するための関数名として一括で更新するための関数名と同じ名前が指定された場合は 1 つずつ追加するための関数を優先する #[derive(Builder)] pub struct Command { executable: String , #[builder(each = "arg" )] args: Vec < String > , #[builder(each = "env" )] env: Vec < String > , current_dir: Option < String > , } 実装方針 目標とする機能を実現するために実装する必要があるのは以下の項目です。 フィールドに付与されたアトリビュートを取得する builder アトリビュートを付与できるようにする 要素を 1 つずつ追加する関数名は build アトリビュートの each キーに指定する アトリビュートのキー名（ each ）のバリデーションは次のステップで実装する Vec 型のフィールドの setter を一括更新用と要素追加用の 2 種類生成する また、要素を 1 つずつ追加できるようにするためには以下の機能の実装も必要です。 Builder 構造体のフィールドでは Vec 型の変数は Option でラップしない フィールドの型が Vec かどうか判定できるようにする Vec をアンラップして中身の型を取得できるようにする 実装 Builder 構造体のフィールドでは Vec 型の変数は Option でラップしない Builder 構造体の定義を生成しているのは build_builder_struct 関数です。今の実装では入力の型に関わらず Option でラップしています。これを Vec のみラップしないように変更すれば良さそうです。 fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let (idents, types): ( Vec < & Ident > , Vec < & Type > ) = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . unzip (); quote! { #visibility struct #builder_name { #( #idents : Option < #types > ), * } } } is_vector 関数は is_option と似た関数で、与えられた型が Vec 型かどうかを判定する関数です。実装は後述します。 fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let struct_fields = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . map ( | (ident, ty) | { if is_vector ( & ty) { quote! { #ident : #ty } } else { quote! { #ident : Option < #ty > } } }); quote! { #visibility struct #builder_name { #( #struct_fields ), * } } } Builder 構造体の定義が変わったので、Builder 構造体を返す builder 関数の実装を生成する build_struct_impl 関数も修正が必要です。 Vec 型のフィールドのみ Vec::new() を返すようにすれば良さそうです。 fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); quote! { #ident : None } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } こちらも build_builder_struct 関数と同様、 is_vector 関数を使って条件分岐を記述しています。 fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); let ty = & field.ty; if is_vector ( & ty) { quote! { #ident : Vec :: new () } } else { quote! { #ident : None } } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } また、 Vec 型のフィールドは要素を含まなくても問題ないので、 Vec 型のフィールドについてもガード節を生成しないように変更します。今は Option のみをフィルタしていますが、追加で Vec もフィルタするように変更します。 let checks = fields .named . iter () . filter ( | field | ! is_option ( & field.ty)) . filter ( | field | ! is_vector ( & field.ty)) . map ( | field | { let ident = field.ident. as_ref (); let err = format! ( "Required field '{}' is missing" , ident. unwrap (). to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()); } } }); is_vector と unwrap_vector の実装 ここからは is_vector と unwrap_vector を実装していきます。ここまでの実装では unwrap_vector はでてきませんが、今後使うのでここで実装しておきます。 Vec も Option と同様 Type::Path に分類されるので、以下の項目は 06 で実装した is_option や unwrap_option を流用できます。 fn is_vector (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Vec" , _ => false , } } fn unwrap_vector (ty: & Type) -> Option < & Type > { if ! is_vector (ty) { return None ; } match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } unwrap_vector のパターンマッチの部分は unwrap_option と同様の処理をしているので関数化できそうです。これを unwrap_generic_type という関数にくくり出すと以下のようになります。 fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_vector (ty: & Type) -> Option < & Type > { if ! is_vector (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_generic_type (ty: & Type) -> Option < & Type > { match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } フィールドに付与されたアトリビュートを取得する フィールドに付与されたアトリビュートを取得する処理を実装する前に、まずアトリビュートを付与できるようにする必要があります。 アトリビュートを付与できるようにするためには、以下のように derive 関数に attributes(builder) というアトリビュートを追加します（ 参考 ）。これでフィールドに #[builder(...)] のようなアトリビュートを付与できます。 #[proc_macro_derive(Builder, attributes(builder))] pub fn derive (input: proc_macro :: TokenStream) -> proc_macro :: TokenStream { アトリビュートを付与できるようになったので、それを取得する処理を実装します。 アトリビュートを取得するにはどのデータを処理すれば良いでしょうか。まずは DeriveInput をみてみましょう。 pub struct DeriveInput { pub attrs: Vec < Attribute > , pub vis: Visibility, pub ident: Ident, pub generics: Generics, pub data: Data, } DeriveInput は attrs フィールドを持っていますが、以下の DeriveInput の attrs の説明にあるように、これは構造体自体に付与されたアトリビュートです。（ 引用元 ） Attributes tagged on the whole struct or enum. 構造体のフィールドは data フィールドに格納されているので Data の定義をみてみましょう。 Data の構造を下っていくと最終的に構造体の各フィールドの情報を保持している Field 構造体が得られます。 Data の構造の詳細については 前編 を参考にしてください。この中にある attrs がフィールドに付与されたアトリビュートです。 pub struct Field { pub attrs: Vec < Attribute > , pub vis: Visibility, pub ident: Option < Ident > , pub colon_token: Option < Colon > , pub ty: Type, } 構造体のフィールドは derive 関数の最初の方で取得しているので、これを処理してアトリビュートを取得していきます。 attrs は Attribute のベクタになっていますが、今回は 1 つのアトリビュートしか使わないので first で先頭のアトリビュートだけ取得すれば良いでしょう。 let ident_each_name = field .attrs . first () . map ( | attr | todo! ()); Attribute の parse_meta 関数 でアトリビュートをパースした結果が得られます。 let ident_each_name = field .attrs . first () . map ( | attr | attr. parse_meta ()); parse_meta() 関数の戻り値は Result<Meta> です。 Meta 型は以下のような enum です。 pub enum Meta { Path (Path), List (MetaList), NameValue (MetaNameValue), } Meta の List バリアントの 説明 に List A meta list is like the derive(Copy) in #[derive(Copy)] . とあるように、今回取得したいのは Meta::List なのでパターンマッチで処理します。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (_)) => todo! (), _ => None , }); MetaList は以下のような構造体です。 pub struct MetaList { pub path: Path, pub paren_token: Paren, pub nested: Punctuated < NestedMeta, Comma > , } MetaList 型の path はアトリビュート名（ #[builder(each="foo")] の builder の部分）を、 nested アトリビュートの値（ #[builder(each="foo")] の each="foo" の部分）を保持しています。今必要なのはアトリビュートの値を保持する nested の部分です。 nested はアトリビュート値を複数保持していますが、今回は複数の値をもつことは想定していないので first で先頭を取得すれば良さそうです。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => list.nested. first (), _ => None , }); nested.first() は Option<NestedMeta> を返します。 NestedMeta は以下のような enum です。 pub enum NestedMeta { Meta (Meta), Lit (Lit), } NestedMeta のフィールドに関する 以下の記述 からわかるように、 Lit は Rust のリテラルを保持します。この段階では nested.first() から Some(each="foo") のような形式が返ってくることを期待しているので Lit ではなく Meta にマッチするようにします。 Meta(Meta) A structured meta item, like the Copy in #[derive(Copy)] which would be a nested Meta::Path. Lit(Lit) A Rust literal, like the "new_name" in #[rename("new_name")]. let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta (_)) => todo! (), _ => None , }, _ => None , }); 先ほどはパターンマッチを用いて Meta::List を取得しましたが、上述のように今度は each="foo" のようなキーとバリューのペアが取得されることを期待しているので、 Meta::NameValue(MetaNameValue) をマッチして処理します。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue{}))) => todo! (), _ => None , }, _ => None , }); MetaNameValue は以下のような構造体です。 pub struct MetaNameValue { pub path: Path, pub eq_token: Eq , pub lit: Lit, } each = "foo" を例にとると、 MetaNameValue は path に each を、 lit に "foo" を格納します。今回欲しいのは "foo" の方なので lit だけを取得すれば良さそうです。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue{ path: _, eq_token: _, lit }))) => todo! (), _ => None , }, _ => None , }); Lit は以下のような enum です。 each = "foo" のような形式からもわかるように、文字列リテラル（ Lit::Str ）が得られることを期待しています。 pub enum Lit { Str (LitStr), ByteStr (LitByteStr), Byte (LitByte), Char (LitChar), Int (LitInt), Float (LitFloat), Bool (LitBool), Verbatim (Literal), } リテラルが表す値は value メソッドで取得できるので、 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue{ path: _, eq_token: _, lit: Lit :: Str ( ref s) }))) => { Some (s. value ()) }, _ => None , }, _ => None , }) . flatten (); 以上で各フィールドの要素追加用のメソッド名を取得できました。 Vec 型のフィールドの setter を一括更新用と要素追加用の 2 種類生成する 今まではフィールドの型によらず、単純に以下のように setter を生成していました。 quote! { pub fn #ident ( &mut self , #ident : #t ) -> &mut Self { self . #ident = Some ( #ident ); self } } まずアトリビュートが付与されているかどうかで分岐が発生します。アトリビュートが付与されていると要素追加用のメソッドが必要になります。 match ident_each_name { Some (name) => todo! (), None => todo! (), } まずは要素追加用のメソッドがいらない方を実装します。 Vec 型のフィールドは Option でラップされないので Vec 型かどうかで setter の実装が変わります。 match ident_each_name { Some (name) => todo! (), None => { if is_vector ( & ty) { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = Some ( #ident ); self } } } }, } 次に要素追加用のメソッドが必要なパターンを実装します。こっちは以下の 2 つのパターンで処理が分岐します。 要素追加用のメソッド名がフィールド名と 同じ 要素追加用のメソッドのみ生成する 要素追加用のメソッド名がフィールド名と 異なる 要素追加用のメソッドと一括更新用のメソッドを両方生成する 実装は以下のようになります。実装のポイントは以下の通りです。 要素追加用の関数の引数の型として使用するために unwrap_vector で中身の型を取り出す 要素追加用の関数の名前（ name ）は String なので Ident::new で Ident を生成する Ident::new の第二引数には Span 構造体を指定する必要がある。 Span 構造体はマクロの展開先で識別子が誤って捕捉されないようにするために必要（ 参考 ） match ident_each_name { Some (name) => { let ty_each = unwrap_vector (ty). unwrap (); let ident_each = Ident :: new (name. as_str (), Span :: call_site ()); if ident. unwrap (). to_string () == name { quote! { pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } } None => { (略) }, } 最終的な実装は以下のようになります。 use proc_macro2 :: {Span, TokenStream}; use quote :: {format_ident, quote}; use syn :: { parse_macro_input, Data, DeriveInput, Fields, FieldsNamed, GenericArgument, Ident, Lit, Meta, MetaList, MetaNameValue, NestedMeta, PathArguments, PathSegment, Type, Visibility, }; #[proc_macro_derive(Builder, attributes(builder))] pub fn derive (input: proc_macro :: TokenStream) -> proc_macro :: TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "this macro can be applied only to struct" ), }; let builder_struct = build_builder_struct ( & fields, & builder_name, & vis); let builder_impl = build_builder_impl ( & fields, & builder_name, & ident); let struct_impl = build_struct_impl ( & fields, & builder_name, & ident); let expand = quote! { #builder_struct #builder_impl #struct_impl }; proc_macro :: TokenStream :: from (expand) } fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let struct_fields = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . map ( | (ident, ty) | { if is_vector ( & ty) { quote! { #ident : #ty } } else { quote! { #ident : Option < #ty > } } }); quote! { #visibility struct #builder_name { #( #struct_fields ), * } } } fn build_builder_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let checks = fields .named . iter () . filter ( | field | ! is_option ( & field.ty)) . filter ( | field | ! is_vector ( & field.ty)) . map ( | field | { let ident = field.ident. as_ref (); let err = format! ( "Required field '{}' is missing" , ident. unwrap (). to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()); } } }); let setters = fields.named. iter (). map ( | field | { let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { path: _, eq_token: _, lit: Lit :: Str ( ref str ), }))) => Some ( str . value ()), _ => None , }, _ => None , }) . flatten (); let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); match ident_each_name { Some (name) => { let ty_each = unwrap_vector (ty). unwrap (); let ident_each = Ident :: new (name. as_str (), Span :: call_site ()); if ident. unwrap (). to_string () == name { quote! { pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } } None => { if is_vector ( & ty) { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = Some ( #ident ); self } } } } } }); let struct_fields = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); if is_option ( & field.ty) || is_vector ( & field.ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); quote! { impl #builder_name { #( #setters ) * pub fn build ( &mut self ) -> Result < #struct_name , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #struct_name { #( #struct_fields ), * }) } } } } fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); let ty = & field.ty; if is_vector ( & ty) { quote! { #ident : Vec :: new () } } else { quote! { #ident : None } } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn is_vector (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Vec" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_vector (ty: & Type) -> Option < & Type > { if ! is_vector (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_generic_type (ty: & Type) -> Option < & Type > { match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } 08-unrecognized-attribute 目標 attribute に間違った識別子が与えられた際に適切なコンパイルエラーを表示する 実装方針 アトリビュートのキーとして each 以外のものが与えられた場合にエラーを表示する エラーを発生させたい箇所で syn::Error の to_compile_error メソッドで TokenStream を返すようにする 単純に panic! させるだけよりも詳細なエラーメッセージを表示させられる 実装 アトリビュートのキーが正しいか判定する必要があるので、アトリビュートを処理している以下の箇所を変更します。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { path: _, eq_token: _, lit: Lit :: Str ( ref str ), }))) => Some ( str . value ()), _ => None , }, _ => None , }) . flatten (); アトリビュートのキーは MetadataNameValue の path に格納されています。 path は Path 型なので 06-optional-field で処理したのと同様にして識別子を取得します。 Ident の to_string メソッドで識別子の名前を取得できるので、これが each と一致しなければエラーを返せば良さそうです。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { ref path, eq_token: _, lit: Lit :: Str ( ref str ), }))) => { if let Some (name) = path.segments. first () { if name.ident. to_string () != "each" { todo! () } } Some ( str . value ()) } _ => None , }, _ => None , }) . flatten (); syn::Error は syn::Error::new_spanned() を使って生成します。エラーメッセージ（"expected ..."）はテストケースに記載されたメッセージをそのまま使います。以下のようにしたいところですが、このままでは型が合わないのでコンパイルできません。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { ref path, eq_token: _, lit: Lit :: Str ( ref str ), }))) => { if let Some (name) = path.segments. first () { if name.ident. to_string () != "each" { return Some ( syn :: Error :: new_spanned ( list, "expected `builder(each = \" ... \" )`" , )); } } Some ( str . value ()) } _ => None , }, _ => None , }) . flatten (); そこで、以下のような enum を返すようにして、後でパターンマッチで処理しましょう。 enum LitOrError { Lit ( String ), Error ( syn :: Error), } LitOrError を使って先ほどの箇所を次のように書き換えます。 let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { ref path, eq_token: _, lit: Lit :: Str ( ref str ), }))) => { if let Some (name) = path.segments. first () { if name.ident. to_string () != "each" { return Some ( LitOrError :: Error ( syn :: Error :: new_spanned ( list, "expected `builder(each = \" ... \" )`" , ))); } } Some ( LitOrError :: Lit ( str . value ())) } _ => None , }, _ => None , }) . flatten (); パターンマッチで処理していた部分も enum に合わせて変更します。 LitOrError::Error にマッチする場合はコンパイルエラーを生じさせる必要があるので、 to_compile_error().into() でエラーを返します。 match ident_each_name { Some ( LitOrError :: Lit (name)) => { (略) } Some ( LitOrError :: Error (err)) => err. to_compile_error (). into (), None => { (略) } } 今まで panic! していた場所も syn::Error の to_compile_error メソッドを使って TokenStream を返すように変更しておきます。 let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => { return syn :: Error :: new (ident. span (), "expects named fields" ) . to_compile_error () . into () } }, _ => { return syn :: Error :: new (ident. span (), "expects struct" ) . to_compile_error () . into () } }; 最終的な実装は以下のようになります。 use proc_macro2 :: {Span, TokenStream}; use quote :: {format_ident, quote}; use syn :: { parse_macro_input, Data, DeriveInput, Fields, FieldsNamed, GenericArgument, Ident, Lit, Meta, MetaNameValue, NestedMeta, PathArguments, PathSegment, Type, Visibility, }; enum LitOrError { Lit ( String ), Error ( syn :: Error), } #[proc_macro_derive(Builder, attributes(builder))] pub fn derive (input: proc_macro :: TokenStream) -> proc_macro :: TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => { return syn :: Error :: new (ident. span (), "expects named fields" ) . to_compile_error () . into () } }, _ => { return syn :: Error :: new (ident. span (), "expects struct" ) . to_compile_error () . into () } }; let builder_struct = build_builder_struct ( & fields, & builder_name, & vis); let builder_impl = build_builder_impl ( & fields, & builder_name, & ident); let struct_impl = build_struct_impl ( & fields, & builder_name, & ident); let expand = quote! { #builder_struct #builder_impl #struct_impl }; proc_macro :: TokenStream :: from (expand) } fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let struct_fields = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . map ( | (ident, ty) | { if is_vector ( & ty) { quote! { #ident : #ty } } else { quote! { #ident : Option < #ty > } } }); quote! { #visibility struct #builder_name { #( #struct_fields ), * } } } fn build_builder_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let checks = fields .named . iter () . filter ( | field | ! is_option ( & field.ty)) . filter ( | field | ! is_vector ( & field.ty)) . map ( | field | { let ident = field.ident. as_ref (); let err = format! ( "Required field '{}' is missing" , ident. unwrap (). to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()); } } }); let setters = fields.named. iter (). map ( | field | { let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { ref path, eq_token: _, lit: Lit :: Str ( ref str ), }))) => { if let Some (name) = path.segments. first () { if name.ident. to_string () != "each" { return Some ( LitOrError :: Error ( syn :: Error :: new_spanned ( list, "expected `builder(each = \" ... \" )`" , ))); } } Some ( LitOrError :: Lit ( str . value ())) } _ => None , }, _ => None , }) . flatten (); let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); match ident_each_name { Some ( LitOrError :: Lit (name)) => { let ty_each = unwrap_vector (ty). unwrap (); let ident_each = Ident :: new (name. as_str (), Span :: call_site ()); if ident. unwrap (). to_string () == name { quote! { pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } } Some ( LitOrError :: Error (err)) => err. to_compile_error (). into (), None => { if is_vector ( & ty) { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = Some ( #ident ); self } } } } } }); let struct_fields = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); if is_option ( & field.ty) || is_vector ( & field.ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); quote! { impl #builder_name { #( #setters ) * pub fn build ( &mut self ) -> Result < #struct_name , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #struct_name { #( #struct_fields ), * }) } } } } fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); let ty = & field.ty; if is_vector ( & ty) { quote! { #ident : Vec :: new () } } else { quote! { #ident : None } } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn is_vector (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Vec" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_vector (ty: & Type) -> Option < & Type > { if ! is_vector (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_generic_type (ty: & Type) -> Option < & Type > { match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } 09-redefined-prelude-types 目標 std::prelude でインポートされる型（ Option や Vector ）などがユーザーによって再定義されても正しく使えるようにする 実装方針 Option や Vec などを名前空間を指定して使うようにすればよいです。テストコードでチェックされているのは以下の 5 つなので、今回はこれらの適切な名前空間を指定するように変更します。 変更前 変更後 Option std::option::Option Some std::option::Option::Some None std::option::Option::None Result std::result::Result Box std::boxed::Box 再定義の影響を受けるのはマクロが呼び出されて展開される部分のみなので、直すのは quote マクロの中にある部分だけで十分です。 実装 上述の 5 つの名前空間を正しく指定するだけなので、今回は最終的な結果のみを記載します。最終的な実装は以下のようになります。 use proc_macro2 :: {Span, TokenStream}; use quote :: {format_ident, quote}; use syn :: { parse_macro_input, Data, DeriveInput, Fields, FieldsNamed, GenericArgument, Ident, Lit, Meta, MetaNameValue, NestedMeta, PathArguments, PathSegment, Type, Visibility, }; enum LitOrError { Lit ( String ), Error ( syn :: Error), } #[proc_macro_derive(Builder, attributes(builder))] pub fn derive (input: proc_macro :: TokenStream) -> proc_macro :: TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let fields = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields, _ => { return syn :: Error :: new (ident. span (), "expects named fields" ) . to_compile_error () . into () } }, _ => { return syn :: Error :: new (ident. span (), "expects struct" ) . to_compile_error () . into () } }; let builder_struct = build_builder_struct ( & fields, & builder_name, & vis); let builder_impl = build_builder_impl ( & fields, & builder_name, & ident); let struct_impl = build_struct_impl ( & fields, & builder_name, & ident); let expand = quote! { #builder_struct #builder_impl #struct_impl }; proc_macro :: TokenStream :: from (expand) } fn build_builder_struct ( fields: & FieldsNamed, builder_name: & Ident, visibility: & Visibility, ) -> TokenStream { let struct_fields = fields .named . iter () . map ( | field | { let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); (ident. unwrap (), ty) }) . map ( | (ident, ty) | { if is_vector ( & ty) { quote! { #ident : #ty } } else { quote! { #ident : std :: option :: Option < #ty > } } }); quote! { #visibility struct #builder_name { #( #struct_fields ), * } } } fn build_builder_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let checks = fields .named . iter () . filter ( | field | ! is_option ( & field.ty)) . filter ( | field | ! is_vector ( & field.ty)) . map ( | field | { let ident = field.ident. as_ref (); let err = format! ( "Required field '{}' is missing" , ident. unwrap (). to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()); } } }); let setters = fields.named. iter (). map ( | field | { let ident_each_name = field .attrs . first () . map ( | attr | match attr. parse_meta () { Ok ( Meta :: List (list)) => match list.nested. first () { Some ( NestedMeta :: Meta ( Meta :: NameValue (MetaNameValue { ref path, eq_token: _, lit: Lit :: Str ( ref str ), }))) => { if let Some (name) = path.segments. first () { if name.ident. to_string () != "each" { return Some ( LitOrError :: Error ( syn :: Error :: new_spanned ( list, "expected `builder(each = \" ... \" )`" , ))); } } Some ( LitOrError :: Lit ( str . value ())) } _ => None , }, _ => None , }) . flatten (); let ident = field.ident. as_ref (); let ty = unwrap_option ( & field.ty). unwrap_or ( & field.ty); match ident_each_name { Some ( LitOrError :: Lit (name)) => { let ty_each = unwrap_vector (ty). unwrap (); let ident_each = Ident :: new (name. as_str (), Span :: call_site ()); if ident. unwrap (). to_string () == name { quote! { pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } pub fn #ident_each ( &mut self , #ident_each : #ty_each ) -> &mut Self { self . #ident . push ( #ident_each ); self } } } } Some ( LitOrError :: Error (err)) => err. to_compile_error (). into (), None => { if is_vector ( & ty) { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = #ident ; self } } } else { quote! { pub fn #ident ( &mut self , #ident : #ty ) -> &mut Self { self . #ident = std :: option :: Option :: Some ( #ident ); self } } } } } }); let struct_fields = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); if is_option ( & field.ty) || is_vector ( & field.ty) { quote! { #ident : self . #ident . clone () } } else { quote! { #ident : self . #ident . clone (). unwrap () } } }); quote! { impl #builder_name { #( #setters ) * pub fn build ( &mut self ) -> std :: result :: Result < #struct_name , std :: boxed :: Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #struct_name { #( #struct_fields ), * }) } } } } fn build_struct_impl ( fields: & FieldsNamed, builder_name: & Ident, struct_name: & Ident, ) -> TokenStream { let field_defaults = fields.named. iter (). map ( | field | { let ident = field.ident. as_ref (); let ty = & field.ty; if is_vector ( & ty) { quote! { #ident : std :: vec :: Vec :: new () } } else { quote! { #ident : std :: option :: Option :: None } } }); quote! { impl #struct_name { pub fn builder () -> #builder_name { #builder_name { #( #field_defaults ), * } } } } } fn is_option (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Option" , _ => false , } } fn is_vector (ty: & Type) -> bool { match get_last_path_segment (ty) { Some (seg) => seg.ident == "Vec" , _ => false , } } fn unwrap_option (ty: & Type) -> Option < & Type > { if ! is_option (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_vector (ty: & Type) -> Option < & Type > { if ! is_vector (ty) { return None ; } unwrap_generic_type (ty) } fn unwrap_generic_type (ty: & Type) -> Option < & Type > { match get_last_path_segment (ty) { Some (seg) => match seg.arguments { PathArguments :: AngleBracketed ( ref args) => { args.args. first (). and_then ( | arg | match arg { & GenericArgument :: Type ( ref ty) => Some (ty), _ => None , }) } _ => None , }, None => None , } } fn get_last_path_segment (ty: & Type) -> Option < & PathSegment > { match ty { Type :: Path (path) => path.path.segments. last (), _ => None , } } まとめ builder マクロを題材にして前編と後編に分けて手続き的マクロの実装方法を説明してきました。 今回実装したマクロはフィールドの型が Option<Vec<_>> であるケースや、 Vec 型のフィールド以外に each を付与した場合などを考慮しておらず、実装した機能は十分ではありません。テストも十分なケースを網羅しているとは言えません。 しかし今回の記事で手続き的マクロをどのようにして作るかは一通り理解でき、今後やる時もどこから手をつければよいかだいたい感覚がつかめたかと思います。この記事が今後みなさんがマクロを実装するときの助けになれば幸いです。 参考文献 syn - Docs.rs

注意!! 記事を書いた時点からの更新があります この記事の内容は古くなっています。当時の課題は 2022年12月の Github ActionsのUpdateにより、同一オーナーの private repository のActionsを参照可能になったため、同一オーナー間であればこの記事の手順を実施する必要はなくなりました。 詳しくは以下の記事を参照を参照してください。 GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA ただし、オーナーが異なるprivate repository のactionを再利用したいというケースではこの記事の方法は利用可能です。 Platformチームの前多( @kencharos )です。 私たちのプロダクトは GCP 上に構築されていて、アプリケーションのテストやビルド、デプロイに加えて、 GCP のインフラ構築もほとんどがIaC化されています。 Pull Requestによるコードレビューを経て、CI/CD パイプラインによりアプリケーションのデプロイや GCP リソースの構築が自動化されています。 CI/CDパイプラインは、以前はCircleCIに注力していましたが、現在は GitHub Actionsに注力しています。 新規サービスの開発では GitHub Actions を最初から使用し、既存サービスでも徐々にCircleCIから GitHub Actionsへの移行を進めています。 GitHub Actionsへの移行理由としては以下の2点があります。 GitHub を使用しているため、CI/CDが統合されていると使い勝手が良い OIDCに対応しているため、 GCP のWorkload Identityを使うことによって GCP Service AccountのKey fileをCI/CD側に保存しなくても GCP リソースを扱うことができる 特に 2 のService Account Key fileをCI/CD側に保存する必要がなくなるのは重要でした。 CADDiでは GCP プロジェクトの数が多く、複数のKey fileを扱うのはメンテナンスコストや漏洩リスクが高かったためです。 なお、現在ではCircleCIもOIDCに対応していますが、検討開始当初では GitHub Actionsのみが対応していました。 actionを共 通化 するための課題 GitHub Actionsでは 再利用可能な処理をactionとして定義して、workflowから呼び出すことができます。 例えば、次のような .github/actions/sample/action.yaml があるとします。 #.github/actions/sample/action.yaml name: sample description: sample runs: using: "composite" steps: - name: echo id: echo shell: bash run: | echo "sample" 同一 リポジトリ 内のactionは次のように uses を使ってworkflowから呼び出すことができます。 #.github/workflows/sample_workflow.yaml name: workflow sample on: pull_request: jobs: sample_job: runs-on: ubuntu-latest steps: # 同一リポジトリの場合 ./ を先頭につける - uses: ./.github/actions/sample このようにaction 共通処理をまとめることができると便利です。 CircleCIでも私たちは Orb という仕組みを使って共通処理をまとめていました。 しかし、検討を進めていくと、別のprivate actionにある共通actionを利用できないという問題に気づきました。 注意! 2022年7月時点の内容です。2022年12月からは同一オーナーのprivate repository も参照可能になりました。 Github Actionsのusesの説明 を見ると、 uses に指定できるのは次のものだけでした。 publicな GitHub リポジトリ にあるaction 同一 リポジトリ 内のaction publicなdockerイメージ 私たちはサービスごとに GitHub の リポジトリ を分けていてその数は20を超えています。 それぞれの リポジトリ の中には GCP SDK の初期化、terraformの実行などの共通処理が多数ありますので、これらの処理を共通actionとして別 リポジトリ に管理できないと、コピペの嵐となってしまいます。 しかし、これらの処理をpublic リポジトリ に置くこともできません。 private リポジトリ を checkout するア イデア 同様の悩みを抱えている人は多数いるようで、その中で出てきていたのは別private リポジトリ をcheckoutして使うというものでした。 #.github/workflows/sample_workflow.yaml name: PAT checkout sample on: pull_request: jobs: sample_job: runs-on: ubuntu-latest steps: # PAT で sampleorg/private-actions の内容を .github/actions/common にチェックアウト - id: checkout-private-repo-by-PAT uses: actions/checkout@v3 with: repository: sampleorg/private-actions path: ./.github/actions/common ref: "main" token: ${{ secrets.CHECKOUT_PAT }} # チェックアウトした action を使う - uses: ./.github/actions/common/sample actions/checkout actionは別 リポジトリ の内容をパスを変えてチェックアウトできます。 チェックアウトした後であれば同一 リポジトリ 内のファイルと見做せるので、 uses: ./.github/actions/common/sample のようにして使うことができます。 ですが、別の リポジトリ をチェックアウトするにはデフォルトの GITHUB_TOKEN では権限が足りないため、 PAT(Personal Access Token)を使う必要があります。 PAT は個人に紐づく トーク ンですし期限もあるため、退職リスクや期限切れによって突然CI/CDが動かなるリスクもあるので、 組織活動としてなるべく使いたくありません。 そこで考えたのが GitHub Appsを使うというものです。 GitHub Apps GitHub Apps は、 アプリケーションが適切な権限で GitHub API にアクセスする仕組みを提供するものです。 GitHub Apps であれば、Organization 内の リポジトリ 単位でアクセスを制御できますし、チェックアウトに利用するアクセス トーク ンを安全に発行できます。 一方で、 GitHub Appsを使ってアクセス トーク ンを発行するのはそこそこ複雑です。 詳しくは 公式ドキュメント などを見ていただきたいですが、簡単に説明すると以下の作業が必要です。 事前準備として、 GitHub Appsを作成して 秘密鍵 を取得した後、 GitHub Appsを organization にインストールしておきます。 アクセス トーク ンを取得するには次の手順を実施します。 GitHub Appsの 秘密鍵 からJWTを生成する installations API をJWTを使用して呼び出し、 GitHub AppsがインストールされているOrganization一覧を取得し、アクセス対象のOrganization の ID (installation ID) を特定する installation IDを使用して installations/:installation_id/access_tokens エンドポイントを呼び出してアクセス トーク ンを取得する アクセス トーク ンを使用して リポジトリ をチェックアウトする このようにPATを使用する場合と比べて GitHub Appsを使う手順は複雑です。 そこで、上記の Github Appsを使ってprivate リポジトリ をチェックアウトするpublic actionを作成しました。 checkout-private-action https://github.com/caddijp/checkout-private-action は、前述の GitHub Appsを使って アクセス トーク ンを発行して、private リポジトリ をチェックアウトするactionです。 このactionだけはpublic actionとして定義します。 次のように使用します。 name: sample workflow on: pull_request jobs: sample-job: name: Sample job runs-on: ubuntu-latest steps: # リポジトリのチェックアウト - uses: actions/checkout@v3 # Github appsを使用して caddijp/common-github-actions private リポジトリを .github/actions/common にチェックアウト - uses: caddijp/checkout-private-action@v0.1.0 with: app_id: ${{secrets.CHECKOUT_PRIVATE_ACTION_APPS_ID}} secret_key: ${{secrets.CHECKOUT_PRIVATE_ACTION_APPS_SECRET}} org: "caddijp" repo: "common-github-actions" ref: "main" dist: "./.github/actions/common" # チェックアウトした action を呼び出す - uses: ./.github/actions/common/common_action 事前に GitHub Appsを作成して、 GitHub AppsのIDと 秘密鍵 をsecretに入れておく必要があります。 これで、別 リポジトリ にある共通actionを各repositoryで使うことができるようになりました。 具体的な処理内容を知りたい方は https://github.com/caddijp/checkout-private-action を見てみてください。 これまでに説明した内容の処理が書かれています。 共通actionを使用する際の注意点 action. yaml の内部にも uses を使用して、別のactionを呼び出すことができます。 そのため、action の中からさらに別の共通actionを呼び出したいと思うかもしれませんが、 これには注意が必要です。 Github Actionsのusesの説明 で説明したとおり、同じ リポジトリ 内のaction指定は、 uses: ./.github/actions/sample のように リポジトリ のルートからの指定しかできないためです。 相対パス や、自分のactionのパスを示す変数である ${{ github.action_path }} などを uses 節で使うことはできません。 そのため、actionから別の共通actionを呼び出すには、必ずチェックアウトするパスを固定しておく必要があります。 この制約を満たすことが難しい場合は、そもそもactionから共通actionを呼ぶような構成を見直して、workflow側で制御すると良いでしょう。 まとめ CircleCIからの移行を検討したときに Orb 相当の機能がなくて困りましたが、 GitHub Appsを使う工夫をすることで対応できました。 将来 GitHub Actionsの機能追加で、private リポジトリ のactionも利用可能になると嬉しいですが、それが待てないという方は参考にしてください。 https://github.com/caddijp/checkout-private-action は図らずともCADDi初の OSS ライブラリとなりました。 今後、違う形で OSS のライブラリが出せると個人的には嬉しいなと思っています。 私たちは他にも CI/CDパイプラインの品質を高く保つための工夫を取り入れています。 Workload Identityによるシークレットの排除や Renovate による依存ライブラリの定期更新など様々な取り組みをおこなっています。 これらの取り組みもまた別の記事で紹介できればと思っています。 興味がある方はぜひ、 採用ページ をご覧ください。

はじめに ご無沙汰しております。キャディでCTO務めております小橋です。 先ほど製造業のモノづくりに直接関わっていたキャディならではの製造業向け SaaS プロダクト 「CADDi DRAWER」のプレスリリース を出しました。この数年間、物理的な製造・検査・納品をしながら培った ドメイン 知見とソフトウェア技術を レバレッジ して、ソフトウェアを通じて産業に直接的な価値を提供出来たことは非常に嬉しく思っています。 今回は長い歴史のある製造業に寄り添ったプロダクト作りの体験を皆さんに共有させて下さい。 背景 製造業は物理的な物を作る産業です。バーチャルな構想を物に変換する工程を「製造」と呼び、その想定アウトプットを描いた「設計図面」が設計者から製造担当者に渡ります。図面には、製造する物（部品）の材質や形状や寸法が記載されています。下記の図は社内で書いたサンプル図面です。ここから、SUS304(ステンレス)で幅500ミリの金具で、といった加工の現場で必要な情報を多く読み取る事ができます。 私達の生活を支えている家電は、この図面で製造されるような個別部品の集合体から組み立てられ、我々の手元に届いています。極端な例かもしれませんが自動車には30,000点以上の部品が搭載され、部品ごとにこのような図面が存在しているのです。 さて、この図面のデータや管理には製造業独特の難しさがあります。先述の通り、現場で読み取るためのツールであるため、フォーマットも多く、人間が読むために注記等が記載されていたりします。また、 SVG に似たベクトル画像フォーマットを利用する場面が多く、バージョン管理がしにくいためsuffixに v1, v2, v3 と連番を追加したり、図面内に記載の図番(XCVF-118)を変更する事もあります。(製造業ではよく図番という図面固有の番号をふります)ソフトウェアの世界だと簡単にコードを GitHub 上で検索したり、過去書いたコードと比較出来ますが、設計図面を扱っていると実現しにくいのが現状です。もちろん、数多くの設計CADソフトとセットで専用 バージョン管理システム が販売されていますが、オープンな業界スタンダードはありません。 また、製造業の特徴として、産業 バリューチェーン が長いということが挙げられます。複数の会社が物や情報を受け渡しながら数多くの部材・部品を製造し、組み立てることで製品をつくる産業です。大手メーカーでは、部品の多くを自社工場ではなく外の加工会社に製造をお願いしています。この、社外に部品の製造を依頼したり購買・調達する業務や役割を「調達」といいます。調達担当者は、設計図面をもとに加工会社に部品の製造を依頼しますが、この図面が殆どの場合、紙や2D画像(pdfや tiff のようなデータ)でやりとりされているため、過去の担当者の知見や発注履歴などの情報を活用することができません。調達部門は会社の財務状況に直接影響する製造原価を握る重要な役割を持っているからこそ、調達に関わるデータの課題を解くことは製造業においても非常に重要であるといえます。 実際、キャディが受発注事業を拡大する上で取引社数も、社内で取り扱う図面数も急増し、まさに自社でこの図面管理の難しさを実感し苦しめられていました。社内のオペレーションを清流化するためのシステムを作り改善を続ける中で、図面の問題にはもっと大きなポテンシャルがあると考えるようになりました。図面を管理するだけではなく、情報を自動的に抽出するといったデータ活用法へのニーズがあり、図面特有の画像解析技術の研究も進めてきました。解析 アルゴリズム が成長したタイミングでこの技術の業界への汎用性にも気づき、ソフトウェアの技術を通じて産業全体に価値提供が出来るのではないかと思ったのが本製品の始まりです。 始まり この気付きをもとに業界調査を始めたかったものの、アンケート資料も無い状態でした。専属の開発チームも マーケティング 担当もいない、ア イデア と夢だけの創業期に戻った感覚でした。 既に受発注の事業を提供していたため、キャディには沢山の製造業のお取引先様があります。1日でも早く ヒアリ ングを始めようと、コンセプトを伝えて反応をつかむためのデモを突貫工事で作る事になりました。システムの設計としても状態を持たず、図面データの検索性や活用シーンといった使い勝手を想像しやすいUXを起点に、裏側はフルマネージドのデータベース(Firestore, Algolia)を利用しました。検証段階でデータ構造が揺らぐことも想定し、schema-lessに寄せてバリデーション緩く。リリース時にドタバタしたく無かったので最低限の開発と本番環境までCI/CDを設けましたが、一方で 結合テスト などは省略し、人力 テスト駆動開発 でデモの品質を担保することにしました。 突貫工事を数週間続けてお客様の意見を回収した結果、我々が社内で当たり前のように使っている図面管理の仕組みが驚くほど数多くの企業様・製造業で働く方々に求められていると実感できました。早速、本格的にプロダクト開発の投資を始める判断に至りました。あまりにも商談が順調で正直焦りましたが、これは喜びの悲鳴とも言えるでしょう。お客様に「いいね」「欲しいです」と言われる事で価値検証の確度が上がり、プロダクトの価値が固まっていきました。 事業としては素敵な事ですが、開発者としては冷や汗をかき始めます。今までは運用や安定性などを考慮せずでデモを作ってきたところで、突然複数のお客様が触れるシステムが求められている訳です。「技術負債が…」と言いたい気持ちもありますが、検証したい仮説を絞った上で全力で走ろうと決めました。社内でサンプル図面を作成する事でセキュリティ要件も抑え、ブラウザも指定、テストも最低限とする戦略を取りました。 走りながらも未来に投資 スタートアップはよく“崖から飛び降りながら飛行機を作る”事に例えられますが、我々もまさに目の前の仕事で必死なのにも関わらず、同時に将来に投資し続ける事が求められました。翌週のリリースに向けて開発しながらも、並行して新規プロダクトのために顧客理解を深めるリサーチも続け、さらに半年後の技術的不確実性を潰す挑戦も必要でした。新たな検証結果や情報が手に入る度に軌道修正する事も求められました。仮説の上にまた仮説を重ねていたので、初期仮説が崩れれば全部ひっくり返る。そんな状況でしたが、これこそが新規事業に求められるアジリティだと今では思います。 組織や体制づくりについても同様で、まだプロダクト価値の検証中でも、成功する前提で将来を見据えて投資する必要もありました。設計図面は製造業にとって最重要データといわれており、大切な 知財 に当たります。そうした機密性の高い情報を扱うプロダクトになる事が想像出来ていたため、セキュリティ対策の優先度は当然高めました。技術的なプロダクト自体のセキュリティだけでなく、組織として情報取扱を含む幅広い情報管理体制を整える必要があると考え、社内の関係者10人前後の段階から ISMS (Information security management system) の構築を決断しました。詳細に営業や開発部門の取り扱うデータを整理し、強弱を付けて施策に落とすだけではなく、制度と実態が合っているのか継続的に確認、改善できる体制を作りました。もちろん、 クラウド 世代のエンジニアらしくIaC (Infrastructure as Code) 管理で運用負荷を下げるために特定情報取り扱うSlackチャネルの参加者もIaC管理しました。 この段階で情報セキュリティに投資した事が、正式ローンチを迎えた今、 組織力 に変換され根付いています。開発のスピードが重要なフェーズにも関わらずセキュリティ対策に時間をとられ目の前の進捗を犠牲にすることもありましたが、お客様の大切な情報を取り扱うプロダクトだからこそ過剰といえるぐらいの対策を行う必要がありますし、非常に重要な施策だったなと今振り返ってみて思います。事業が拡大してから、組織の価値観を変える事はとても難しいからです。 突貫工事を卒業しベータ版へ お客様からの強いニーズを確認できたため、ベータ版として提供し使っていただくことにしました。突貫工事のデモを卒業するにあたっては、事業的にも技術的にも多くの仕事がありました。特にエンジニアとして「ソフトウェアを作る人」ではなくて「ソフトウェアの専門性を活かして事業を作る人」として振る舞う必要がありました。お客様が直接ソフトウェアを触る事で初めてプロダクト価値が分かるので、それに向けて少しでも早く商談が始められるように開発の順番等を調整し続けていました。営業の場に同席して、自分達で ヒアリ ングもする事で情報を 仕入 れ続けていました。IT分野を超える 多能工 化が求められるわけですが、これこそが新規事業の楽しみだなとも振り返って思います。 数ヶ月かかりましたが徐々にデモの状態 からし っかりと組まれたソフトウェアに成長し、ドキュメントやタスクも整理出来ていきました。弊社の設計図面の解析技術も進化して、当初の想定以上のパフォーマンスを出せるようになっていました。ソフトウェアのスタックも社内標準に合わせ、インフラも Kubernetes クラスタ ーに移し、監視も出来るようになり、定期的に ブラックボックステスト も追加されていきました。今では、メトリクスを通じて提供したい価値がユーザにお届けできているかの測定も可能になっています。 エンジニア個人の腕力と気合に依存していた部分もありますが、この四年間で蓄積してきた B2B のシステム運用の知見が社外に発揮出来たとも思っています。社内用に大量の図面を処理する仕組みを構築した経験もありましたし、複雑なデータ構造を扱う非同期処理が多い基幹システムの落とし穴も事前に分かっていました。 ドメイン 駆動設計（DDD）に レバレッジ をかけた開発の難しさも経験していたお陰で、なるべく事業の目指す方向に適した開発手法が選定出来たのかなと思います。 新規目玉機能の開発 ベータ版を通じてお客様の調達の課題をひとつ解決出来ることは検証出来ましたが、これはいわゆるProblem Solution Fitでしか無く、まだ1つの大きなプロダクトと言える状態ではありませんでした。我々は痒いところに手が届く仕組みだけを作りたいわけではなく、大きく業界を次の世代に進化させる事を目的としています。もちろん業務簡略化機能を届ける事も大切にしていましたが、他の誰にも実現出来ないキャディならではの圧倒的なWOW要素を込めた1つの”プロダクト”にするために試行錯誤を繰り返しました。 プロダクトマネージャの ヒアリ ングやリサーチから出てきた案が、設計図面の類似検索でした。 Google で検索キーワードの代わりに写真をキーにした画像検索が出来るかと思いますが、それを調達というコンテキストで設計図に適用し、類似品の比較を通じて調達の最適化を行うというア イデア です。製造業に関わっていないと分からない「類似」に関する強い ドメイン 知識もあり、まさに受発注に日々関わっているキャディにしか出来ない事です。 素早く弊社のAI Labを巻き込み、社内の ドメイン エキスパートや図面に纏わるデータを参考にした探索を始めました。また、「類似」というほぼ定義の無い要件を 言語化 して評価指標を用意出来るまで、数多くの方々にお世話になりました。受発注に日々関わっているからこそ仮説を立てフィードバック頂ける時間が短縮出来たのかなと思います。見積・調達・製造・検査と幅広いオペレーションを社内で持っているため、 アルゴリズム の評価指標を設計する上で重要な要素を現場に ヒアリ ングする事も出来、まさにキャディの総力で挑んだプロダクトになっています。 アルゴリズム だけではなく、アプリケーション全体の設計も一気に難易度が上がりました。類似判定をする特殊な アルゴリズム の開発を始め、その解析技術を活用する分散処理の仕組みや類似データを格納する特殊なデータベースも必要になりました。データ保管をするともちろんバックアップや マイグレーション も求められ、開発の関係者数も増えるため情報の交通整備の難易度も上がっていきました。 色々組織的にも技術的にも苦労して負債も積んでいますが、お客様に調達業務を進化させるプロダクトがついに出来たと思っています。デモを作り始めてから一年間で業界特化の バーティカル SaaS を立ち上げ、プレスリリース出せた事は嬉しい限りです。ですが、これから事業成長を続けるには正直足りていない要素ばかりです。この勢いで急速立ち上げしているので、改善の余地しか無いです。 現状パフォーマンス改善を省略しマシンスペックで殴っていたり、CI/CDの関係で新規機能がお客様の手元に届くまでの時間が長かったり、開発者体験や運用コストを犠牲にして走ってきた部分もあります。また、設計変更を繰り返した結果チーム構造とシステム構造にねじれがあって連携コストが高くなっている事実もあり、チームとシステム両方の最適化が必要です。 プロダクトとしてもこれがまだスタート地点にやっと立てた状況です。公開は出来ないワクワクするロードマップが沢山待ち構えておりますので、また皆さんに紹介出来るのを楽しみにしております。 これからの挑戦 ユーザ数及び図面数が急増する中での継続安定運用 今後事業伸ばしていく上で桁違いの負荷に耐えて安定運用を継続出来る組織体制や技術挑戦が必要とされてます。組織的にはカスタマーサクセスに向けたUX改善やユーザより先に問題を検知出来る品質の作り込み、そして障害が起きても速やかに リカバリ ー出来る体制の強化が重要かなと思います。これを実現出来る組織作りに挑戦したい エンジニアリングマネージャー を探しております。 技術的には既に クラウド のスケーラビリティ力に頼っておりますが、甘えすぎずにパフォーマンスを常に意識し続ける事で、新たな機能開発の弊害を避けられると信じています。非同期処理も多い複雑なプロダクトに関わりたい アプリケーションよりの方々 、そして縁の下の力持ちとして組織とプロダクトを支えたい プラットフォームエンジニア の仲間も絶賛募集しております。 開発者体験改善を通じて組織のアジリティ向上 最初の一年は不確実性が多く、そもそもプロダクトとして価値を出せるのかも分からずに走って来たため、人数絞ってハイコンテキストで仕事を進められる体制をとっていました。しかし、これからさらなる拡大をしていく上では内部の API やインタフェースを安定化してドキュメント化し、毎週 breaking change が起きない状態を目指したいです。複数チーム横断したパッケージの共有やリリースの清流化、細かいけど重要なログフォーマットの共 通化 等も今後は開発者体験及び生産性に効いてくると思います。 キャディの プラットフォームエンジニアリングチーム は開発者組織のアジリティ向上と イノベーション 推進をミッションに掲げており、直近ではサービスメッシュの検討等も進めており、深い知見をお持ちの方に協力して頂きたいです。 種からプロダクトまでの イノベーション パイプライン短縮化 今後、R&Dから生まれた新規画像解析 アルゴリズム や新たなUXの検証実験等、数々の施策を打っていくことを想定しています。最速で新規ア イデア をユーザの手元に届けられ、プロダクション提供しているものを継続改善出来る世界に持っていきたいんですが、まだ苦労しているのが現状です。 データ領域に関しては半年前にAI Lab設立したばかりで、更地どころか無の状況で始まり、やっと更地になったくらいです。今回のプロダクトリリースで初めてend-to-endのデリバリーが実現出来た良い事例かなと思いますが、今後はこの価値提供を加速化する領域にも投資したくて MLOps や Data Engineering の領域を強化して行こうとおもっています。上流のデータ取得や ディスカバリー は現状 人海戦術 な部分も多いのは多少仕方がないとしても、運用中のモデルのパフォーマンス評価を元に PDCA 回したり、更新に伴うバージョン管理やロギング周りも劣後して来たので、今後は力入れていきたい。データが好きだったり、データとソフトウェア開発の境界線を歩みたい方と一緒に イノベーション パイプライン作っていきたいです。 プロダクト成長を支える新規施策 最初の課題を解くプロダクトが出来上がったと感じていますが、これからデータ基盤になるのか、新しいWOWの提供に特化したサービスになるのか、 ヒアリ ングと試行錯誤を続ける難しいフェーズになるなと考えています。プロダクトとして立ち上がった今、1から100に成長させられる力強い プロダクトマネージャー と プロダクトデザイナー も募集しています。 製造業の品質管理とソフトウェアの比較記事を以前書きましたが、キャディでは現状テスターのみの組織はもっていません。四六時中 単体テスト 書く職人もいません。現状は各開発者にお任せしている状況ですが、これではキャディ全体がスケールしないと考えており、DevOps系の施策が好きな方や自動化に興味がある Quality Assuranceエンジニア とも一緒に働きたいと考えています。

はじめまして、キャディでバックエンドエンジニアをやっている秋山です。 趣味で粛々とやっていたバイナリ解析について2022年5月17日に開催された社内勉強会で発表させていただきました :tada: [toc] バイナリ解析とは？ バイナリ解析とは、製品や実行ファイルなどソフトウェアの内部の詳細を分析し、一般に公開されてないシステム設計や仕様を明確化し調査することです。 その他にマルウェアを静的解析する際もバイナリ解析を使用して調べたりします。 バイナリ解析って、やってもいいの？ 法律的に、脆弱性診断のためのリバースエンジニアリングは合法です。 ただし、市販の製品に対してリバースエンジニアリングを行い、その情報を開発などに使用したり情報を開示すると特許法上や著作権上の違法性が認められる場合があります。 また、ソフトウェアの使用許諾契約書などにリバースエンジニアリング禁止条項として記載されている場合は要注意です。 どう楽しむといいのか？ 安全かつ楽しんで解析しましょう。 具体的な方法は以下の2つです。 CTFに参加する マルウェア捕まえて解析する CTFに参加する セキュリティコンテストはいくつかあるので、参加してみるといいかもしれません。 終了後には Writeup という形で解答を掲載する人もいるため、コンテスト終了後に復習できることがあります。 - SECCON Beginners - picoCTF - WaniCTF マルウェア捕まえて解析する 解析対象のバイナリ入手方法 マルウェアを収集するツール マルウェアを収集できるツールをご紹介します。 ハニーポッド（Dionaea） マルウェア収集用のハニーポットです。 検体の収集はもちろん、インシデントログからネットワーク経由の攻撃を再現することもできます。 T-POTを入れると諸々入るのでサクッと試せます。 VIRUSTOTAL 検体をダウンロードすることも可能なサービスです。 普段の用途としては、怪しいファイルをアップロードするとよしわるしをパッと判断してくれます。 ※ アップしたファイルは公開されるので、機密ファイルなどは避けてください。 Cuckoo Sandbox サンドボックスで怪しいファイルを動作させて、動的に解析できるツール 実行時のキャプチャや書き換えられたレジストリ、どこと通信しようとしているかなどを確認できます。 一家に一台あると安心です。 ランサムウェアのWannaCryを動かしてみるとこんな感じです。 1. ファイルをドロップします。 少し待つと、Summaryやキャプチャなどがかえってきます。 解析手法の種類 バイナリを解析するときの手法としては、大きく3つほどあります。 今回は、静的解析をやってみたいと思います。 ① 表層解析 どういった実行形式で実行されているのか、ファイルのハッシュ値（VIRUSTOTALでハッシュ値を検索すればマルウェアが判明することも）など、どういったファイルであるかをデータという視点で解析します。 ② 動的解析 プログラムを実行すると何が見えるかを解析します。 ※ 検体を実行する場合は手元ではなくCuckooSandboxなどを利用することをお勧めします。 ③ 静的解析 プログラムを可視化して構造や動作を解析します。 バイナリ解析（静的解析）で使うツール 解析する上で色々なツールがありますが、今回は radare2 を使ってみます。 radare2　 ← 今回はこれをやってみます。 ghidra gdb objdump IDA Pro（有料） OllyDbg バイナリ解析（静的解析）を行う前におさえておきたいこと 解析するうえでABIの部分と、命令セットアーキテクチャ（ISA）の部分をおさえておきましょう。 ABIとは ABIとはApplication Binary Interfaceの略のことで、バイナリレベルで関数やデータの仕様を規定したものです。 関数をコールするときの引数の渡し方などを規定します。 コンパイラで生成されるバイナリはABIに準拠しており、ABIを知ることで一覧のアセンブリ命令が何をしようとしているのかを理解することができます。 ABIは何によって決まるの？ ABIは、ISAとOSにより決まります。 厳密には、言語やコンパイラごとに異なることもあるらしいです。 今回の環境は x86-64 と Linux なので System V AMD64 ABI を参考にしています。 参照： https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf レジスタとは CPU内部にある記憶装置のことで、アセンブリが何かをやる際に利用します。 汎用レジスタ 色々な用途に使用できるレジスタで、状況に応じて様々な用途に用いることができます。 - rax - rbx - rcx - rdx - rsi - rdi 特殊レジスタ それぞれ専門的な用途があるレジスタです。 - rbp：現在のスタックフレームにおける底のアドレスを保有。 - rsp：現在のスタックトップのアドレスを保有。 - rip：次に実行するアセンブリ命令のアドレスを保有。 メモ：RCXとECX 64bitでは、RCXなど頭にRがついたレジスタがあります。 32bitでは、ECXなどのレジスタ名になります。 今回のアセンブリでは、64bitの環境なのに頭がEのレジスタを使っています。 これは格納する値が32bitで事足りるので下位32bitだけ使った結果こうなっているらしいです。 参照： https://www.mztn.org/lxasm64/amd04.html バイナリ解析（静的解析）を行う それでは、バイナリ解析（静的解析）を実際にやってみましょう。 解析対象のソース 今回利用するソースコードです。 #include <stdio.h> int add(int a, int b, int c, int d, int e) { int sum = 0; sum = a + b + c + d + e; return sum; } int main(void) { printf("sum = %d\n", add(1, 2, 3, 4, 0)); return 0; } コンパイルする gcc sample.c 実行時のメモリレイアウトは以下が参考になるかと思います。 https://twitter.com/404death/status/968381431146778624/photo/1 解析する 以下のコマンドで解析します。 r2 -d a.out 関数一覧を見てみる aaa 　でバイナリ全体を解析しています。 afl 　でバイナリのなかにどういった関数があるのかを一覧で出しています。 [0x7f7b5ad84090]> aaa [0x7f7b5ad84090]> afl 0x5564c6ff7050 1 42 entry0 0x5564c6ff9fe0 1 4124 reloc.__libc_start_main 0x5564c6ff7080 4 41 -> 34 sym.deregister_tm_clones 0x5564c6ff70b0 4 57 -> 51 sym.register_tm_clones 0x5564c6ff70f0 5 57 -> 50 entry.fini0 0x5564c6ff7040 1 6 sym..plt.got 0x5564c6ff7130 1 5 entry.init0 0x5564c6ff7000 3 23 map.root_a.out.r_x 0x5564c6ff7210 1 1 sym.__libc_csu_fini 0x5564c6ff7135 1 58 sym.add 0x5564c6ff7214 1 9 sym._fini 0x5564c6ff71b0 4 93 sym.__libc_csu_init 0x5564c6ff716f 1 61 main 0x5564c6ff7030 1 6 sym.imp.printf 0x5564c6ff6000 3 404 -> 393 loc.imp._ITM_deregisterTMCloneTable 0x5564c6ff61aa 5 32 -> 55 fcn.5564c6ff61aa mainとsym.addのアセンブリ全体像 下図の左側が main のなかのアセンブラで、右側が add 関数のアセンブラです。 AT&T構文とIntel構文があるのですが、Intel構文で表示されています。 main関数 関数呼び出しをする際のお決まり（Function prologue）を実行する 関数呼び出しをする際のお決まりのようなものです。 コールされた関数は、呼び出し元に戻る時にスタックの状態が呼び出し時と同じ状態になるように rbp を退避しておきます。 push rbp mov rbp,rsp 有効な命令アドレスの範囲は0x00007FFFFFFFFFFFです。 push rbp 　が実行されると、スタックの一番上に積まれます。 push rbp mov rbp,rsp 　が実行されると、スタックの番地を rbp に保存します。 これは、main関数におけるスタックの底を指定する処理になります。 この状態になっていると、現在の関数でスタックを好きに使っても呼び出し元に戻る時には元の状態にして戻すことができます。 mov rbp,rsp 引数を渡す add関数に渡すための値をレジスタに設定します。 mov r8d, 0 mov ecx, 4 mov edx, 3 mov esi, 2 mov edi, 1 メモ：関数呼び出しに関する決まりごと 引数の渡し方はABIに準拠しており、関数呼び出しに関する決まりごとはABIのドキュメントの「 Figure 3.4: Register Usage 」に記載があります。 関数をコールする call を実行すると、スタックにリターンアドレスをプッシュします。 call sym.add printf関数に渡す値を設定する printf関数に渡すための値をレジスタに設定します。 第一引数（ rdi ）にはフォーマットとなる文字列 sum = %d\n のアドレスを設定し、第二引数（ esi ）には一つ目の %d に表示するための合計値を格納しています。 mov esi, eax ; addの戻り値を第二引数に設定する lea rdi, qword str.sum____d ; 0x5564c6ff8004 ; "sum = %d\n" mov eax, 0 call sym.imp.printf ; int printf(const char *format) メモ：mov eax, 0命令 mov eax, 0 命令は、今まで見てきた引数渡しのパターンに当てはまらないため調べてみました。可変長引数に浮動小数点の値を必要とする場合、その数を設定する必要があるらしいです。今回は整数型なので0を設定しています。 こちらもABIの「3.5.7 Variable Argument Lists」で説明されています。 main関数を終了する main関数の戻り値として eax に0を設定し、スタックに積んでいたベースポインタの値を rbp にポップ（Function epilogue）してきたらretでmain関数を終了します。 mov eax, 0 pop rbp ret add関数 次にadd関数内の処理を呼んでみます。 関数呼び出しをする際のお決まり（Function prologue）を実行する push rbp mov rbp, rsp コールスタックに引数を格納する 渡された引数をコールスタックに格納しています。 メモ [rbp-0x14] という中途半端な場所からスタートしているのは「アライメント境界」というのが関係しているらしいです。 スタックには赤い四角で囲まれているように、引数が積まれています。 sum変数を初期化する 変数領域sumを0で初期化しています。 mov dword [var_4h], 0 引数の合計値を求める 渡された引数1から引数5までの値を足しています。 mov edx, dword [var_14h] ; 1 mov eax, dword [var_18h] ; 2 add edx, eax mov eax, dword [var_1ch] ; 3 add edx, eax mov eax, dword [var_20h] ; 4 add edx, eax mov eax, dword [var_24h] ; 0 add eax, edx sum変数に結果を格納する 足し算の結果を変数sumに当たるアドレス[rbp-0x4]に格納して、戻り値としてeaxレジスタに値を格納しています。 mov dword [var_4h], eax mov eax, dword [var_4h] add関数を終了する add関数の戻り値としてeaxに0を設定して、スタックに積んでいたベースポインタの値をrbpにポップ（Function epilogue）してきたら、retでmain関数の呼び出し元に戻ります。 pop rbp ret 最後までお読みいただきまして、ありがとうございます。

In March 2022, I was fortunately to join CADDi Inc. for a month-long internship as a frontend developer. It was an amazing and fruitful experience. Why I joined the internship Without any explanation, it might be hard to imagine why a company in the manufacturing industry would need a large team of developers. However, the message from the CEO and the CTO about the company explains this: by leveraging the power of IT to facilitate operations, CADDi attempts to transform the manufacturing industry, which I found very interesting. Reading the Company Overview for Engineers also encouraged me to apply for this internship program. It gives a brief introduction to some of the products in CADDi and also introduces the technology stack used. This shows that the company is willing to adopt the best tools available to solve challenging problems, and also that the internship would be an opportunity to learn how to use many new tools. There are also things that would have been hard to learn on one's own, working effectively as a member in a team of developers being one of them. Even though I have a few years of programming experience, I believe that I need to strive to become a better programmer and a better developer. Believing that this would be a precious learning experience, I applied and got an offer for the internship. What I did during the internship As an internship participant, I joined one of the teams in the company and had the chance to experience how it is like to be an actual software engineer. The following are some of the activities I participated in. Development & code review Most of the time in the internship was spent implementing new features and fixing bugs. Even though I joined as a frontend developer, I was able to read and modify the backend code in the same monorepo. I also spent some time reviewing and modifying the CI pipeline to improve developer experience. In addition, we also reviewed each other's pull requests. Apart from catching mistakes in the changed code, it is also an excellent opportunity to share knowledge of how to write more maintainable code and gain understanding of a different part of the product when one is not involved in the development of the part. Scrum meetings I also spent time participating in scrum events like sprint planning, daily scrum, sprint review and sprint retrospective. We were able to raise our concerns about what we find confusing during the development cycle and attempt to fix these problems to make the development process more efficient. I also got to understand how scrum allows a team to work towards a defined goal with trackable metrics. User interview There also happened to be several user interview sessions, where potential users are invited to try out new features and provide feedback to developers. It was a humbling experience, reminding me the reason that we develop the product is always to make something useful for the user. What I had learnt from the internship Technical knowledge This internship has been an opportunity to experience using technologies that I have only heard about but never used before. Usually, in order to learn new technologies, one needs to be proactive in finding new technologies to learn and spend time finding resources and actually try to use the library. Through the internship, it is possible to learn new technologies quickly and gain a deep understanding reading code written by other developers. As CADDi makes use of a frontend-BFF-backend architecture , this is my first experience using Protocol Buffer and gRPC. It is also my first time developing a project that adopts the clean architecture. Fellow developers in the same team had been very kind to answer my questions and explain to me some of the things which I do not understand, for example how the application is deployed to the Kubernetes cluster from CI. Even though I joined a frontend engineer position, I was not limited to frontend development, and was able to learn much about backend development and DevOps. The difference between personal programming and team programming Personal programming and team programming are completely different. For instance, one has to pay particular attention to write code in a way that is easy for other developers to understand. This may include having a common way to structure code, writing comments to explain code if it is not obvious why it is done in a certain way, etc. On the other hand, the friendly environment in CADDi had been really helpful. When one gets stuck while trying to solve a problem, it is easy to consult other team members for help. As members each have their own strengths and weaknesses, this allows us to combine the strengths and develop much faster than a single developer could. The importance of reading and writing documentation When knowledge is shared effectively among team members, it allows developers to solve problems more efficiently, without needing to ask other team members all the time. Meetings are of course one of the ways to do this, but documentation allows this knowledge to be retained even if members change teams. By setting up a general convention on where to put documentation and nurturing a culture of reading it, the knowledge is effectively shared and preserved. Although effort is required to keep the documentation updated, it is arguably time well spent as not only can the onboarding cost for new members be reduced but also can developers reference it at any moment. Ending Notes After the end of the internship, I have gladly been allowed to join CADDi Inc. as a part-time software engineer. Overall, the internship has been a very fruitful experience. I had gained much precious experience that would not have been possible without joining the internship. I believe that internship programs are excellent learning opportunities for aspiring engineering students, and starting early will open you to a world of opportunities.

キャディでエンジニア採用を担当しています片渕です。 今回は2022年3月25日に開催したイベント、『 CADDi Be Agile! 〜開発もビジネスもスクラムで回してみた 』の内容をレポート形式で紹介しています。 メインの アジェンダ としては大きく以下3点です。 Tech組織の スクラム について Biz組織の スクラム について パネルディスカッション Tech組織のみならずBiz組織での スクラム 導入の背景や現状、課題と感じている点などについて、Techからは高藤・Bizからは佐野がプレゼンしています。 [ toc ] Tech組織の スクラム 『LeSS』に関して 高藤： LeSSという仕組みを一部のチームで導入しているので、その話を今回はしていきます。 なぜ スクラム という開発手法を用いているのか LeSSをやる時にも考えたことになるのですが、私は「Tech組織は価値を届ける開発組織でありたいな」と思っています。 これはどういうことかというと、エンジニアは技術的に難易度が高いことにも挑戦したいのですが、結局は作ったシステムを使う ステークホルダー の方々が、価値を感じてもらわないといけないのです。 技術的にとても難しいものを作ったとしてもユーザ側に価値が無い、となるとエンジニアとしては何をしていたんだ？ということになってしまいます。 よって、しっかり価値を届ける組織を目指した時に、ビジネスが急成長してきた会社なので解決したい課題も少しずつ変化してきます。 そうした不確実な部分が多くあるものの、常に軌道修正をしながら開発できる組織で、しっかり価値提供できる開発チームでありたいと考えています。 また、上からの指示があったからやりましたというのではなく、ユーザとコミュニケーションして課題を設定し、課題を解いていく組織でありたいですね。 その実現のために必要なことが、 スクラム とマッチしているので、現在も スクラム を継続しています。 スクラム 導入の歴史や背景について 私がキャディに入社して3年ちょっと経過するのですが、入社時はエンジニアは数名ほどで、現在は50名ほどの組織になっています。 最初の頃は、なんちゃって スクラム のような状態で、生産管理プロダクトという我々の受発注の仕組みの中での基幹システムの部分は、数名規模の開発から始まりました。 この頃は アジャイル 開発で、 スクラム という言葉は知っているものの、しっかり学んだ人は私自身も含めていませんでした。 もちろん スクラム マスターという役割の人もいなかったですし、 スクラム イベントがあるようだということを、なんとなくで進めていたのが正直なところです。 当時は、JIRAという仕組みを使ってチケットを切ることをやっていたのですが、何だか合わないなという意見もあり一旦辞めて、 スプレッドシート にやることを書いていったことがあり、結果的に荒れたスプレットシートができあがってしまいました。 本格的に スクラム を知ったきっかけ その後、 スクラム 開発に詳しいエンジニア リングマ ネージャーが入社して、また様々なプロダクトも作られるようになってきました。 エンジニア リングマ ネージャーからは、「Howをどうするか？」を教えられたというよりは、 スクラム 基本原則の理解が重要という話もあり、 スクラム ガイドを輪読して読書会なども開催していました。 結果、「 スクラム では何を大事にしているか？」という原理・原則を理解して、その上で自分たちは何をしなければいけないかを考えるようになりました。 この頃から、JIRAを改めて使うことになり、やや抵抗を感じながらも スプレッドシート からJIRAに移行もしました。 現在ではキャディの中では基本的にはJIRAを使っていますし、Biz側でも使われるようになっています。 そのような歴史があり、チーム全体通して スクラム でやる理由を理解した状態になれたのではないかと思っています。 LeSSの導入の背景 そして最近の話になってきますが、この1年でエンジニアが2倍の数にもなってきて組織が大きくなったので、LeSS(Large Scale Scrum)を導入することになりました。 LeSSを導入した背景としては、 スクラム で推奨される人数は10名以下とガイドには書かれているのですが、我々のチームもそのようなサイズ感になってきた時に、コミュニケーションにやりづらさを感じていました。 例えば、デイリー スクラム や振り返りの場などで時間を定めてコミュニケーションをするのですが、人数が多いと全員がすっきりするまで発言できず、限られたトピックのみしかコメントができなくなったのです。 自分の意見を言い切れなくて消化不良となるケースも多くなってきたり、プロダクトの面でも自分が担当しているプロダクトに近いもの、生産管理でいうと受発注がメインでデータを扱っているシステムと我々が発注するデータをパートナー様に提供するポータルのプロダクトチームとの連携の時に、お互いにどんなことを今後やっていくのかを、クオーターやスプリント単位での可視性・透明性が薄れてきているなと感じました。 そうした点を考慮すると、もう少し大きな人数で スクラム を回す方法がないかなと考えた時に、LeSSという仕組みを導入しました。 １つのプロダクトを開発する人数も増えてきて、プロダクトの価値を考えると一緒に動ける方が良いかなと思っていました。 そのため、2021年の11月からLeSSを導入し、1ヶ月間を準備期間としてそれぞれの開発チームが合流するためのことを考えていました。 LeSS以外にも手法はあるのですが、我々がやっていることをそのままできそうなのがLeSSだと思ったので、こちらを選んだということですね。 プ ラニ ング・リファイメント・レトロスペクティブもLeSSにあり、理解しやすかったです。 LeSS導入当初にやったこと 準備期間にやったことは、ミロというオンラインのホワイトボードでやったのですが、スプリントプ ラニ ングではチームごとにやる前に全体でプ ラニ ングして、その後に各チームごとにプ ラニ ングをやりましょうという話です。 スクラム の代表者、LeSSに参加してくれる各チームのリーダーに集まってもらって、どういうことをやらないといけないのかを書き出していきます。このイベントはどのくらいの時間をかけるのか、などを最初に議論するわけです。 開発者だけではなく、プロダクトオーナーとなるPdMにも理解して欲しかったので、オーナーがやるべきことを議論してすり合わせをして準備を進めて行きました。 実際に去年の11月からスタートして2ヵ月経過して問題も見えてきたので、「クオーターごとにLeSSを導入してどうだったか？」を振り返り、次のクオーターで新しい取り組みをやるということを継続しています。 今後に向けて LeSSを選択して苦労もありましたし、私自身はもちろんですが参加したエンジニアも同じだったと思います。 スクラム やLeSSは、自分たちが経験したことを改善するのにはとてもいい方法で、各組織が経験したことを積み重ねていくことができます。 今後は、LeSSならではの悩みもありまして、チーム同士のコミュニケーションはどこまで担保すべきなのか、などは引き続き考えて行きたいと思っています。 Biz組織の スクラム に関して 佐野： 私の方からは、2022年3月24日にアトラシアンのイベントにてプレゼンさせていただきました資料をもとに、Biz組織での スクラム 導入の話をしていきます。 一般的にはソフトウェア系の会社に スクラム を導入すると思うのですが、どのような経緯でBiz側に導入していったのか、説明してきます。 Biz部門への スクラム 導入経緯 2021年の10月から スクラム を導入しはじめたのですが、ちょうど事業や組織が一気に拡大するフェーズで、プロジェクトマネジメントが急務という状態になりました。 QCD担保はもちろん、どんどん事業や組織が大きくなるものの、まだアーリーステージの会社なので、スケーラビリティを担保するには一定の型も必要になると考えていました。 そのため、何かしらの手法を入れようと検討したところ、 スクラム の話があがり導入することにしました。Tech組織で既に導入していたので、Biz組織でも試験的に3プロジェクトからやってみましょうということでスタートしました。 導入直後のカオスからの改善 導入してみたところ、導入直後はカオスな状態が発生し、メンバーから スクラム やJIRAなどへの不満が続出しました。 バーンダウンチャートも見事にバーンアップしてしまうことにもなり、全然 スクラム として機能していませんでした。 そこでスピードを意識して PDCA 回し、 スクラム マスターを配置して、JIRA警察と称して DoD やストーリーポイントが入っていないことなど、細かくチェックをしていきました。 また、KPIの設定やモニタリングを行い、スプリント達成率などを計算して集計し、100%を目指していくといった取り組みを進めていきました。 このように毎週改善に取り組んでいった結果、少しずつコツが見えてきました。 このプロジェクトだったらバーンアップチャートが良いよね、JIRAオートメーション機能を使うといいよねというコメントが出て、やり切る意識が高まってきました。 導入してから２ヶ月後くらいで、きれいなバーンダウンチャートを示せるようになったのは、劇的なbefore/afterになったなと感じています。 このように結果がついてくると、 スクラム やJIRAを嫌がっていたメンバーから、「とてもいいツールですね」「JIRAと スクラム の親和性がいいね」という話が出てきました。 導入した成果やメリット キャディでは ムーンショット と呼ばれる非連続の成長を実現したり、事業課題の 見える化 も進み、スムーズなリプ ラニ ングも可能になってきました。 また、各チームの フレームワーク が共通 言語化 したことから、議論の土台がそろってきたことは成果の1つと思います。 以上が、2021年の10月から12月までに起きたことです。 Bizやコーポレートも含めた全部門への スクラム 導入 この３ヵ月の成果を踏まえて一気に改善も進んだので、Biz/CPの全部門に入れて組織のOSにしたく、 トップダウン で スクラム をインストールすることにしました。 そのために年始の全社ミーティングで2時間くらい勉強会をやりました。 キャディでは前職がコンサル・ ベンチャー ・商社・メーカーなど様々で、 アジャイル なプロジェクトマネジメントへの慣れ・不慣れの程度さは大きいのですが、改善を高速で回していくのは良いことだよね、と議論を進めながらやってきました。 スクラム 導入の目的を 言語化 キャディの組織のあり方によって、理想的な スクラム の形は異なると思いますが、少なくともBiz組織ではShift Leftな組織づくりを目指したいと考えています。 つまり、計画性や透明性を担保したり、事業スピードを早めたり、メンバーのコミットメントの担保することが大切になります。 さらに スクラム 浸透に向けた取り組みとしては、認定 スクラム マスターを取得したり、 スクラム マスター育成プログラムを作ったり、新人研修で スクラム やJIRAの研修をやったり、型化を推進したり、業務特性に応じてはカンバンと併用することもやってきました。 スクラム マスターへの期待値も 言語化 し、チームの達成やスプリントの PDCA 、チームの 心理的 安全性を高めることなどを定めました。 スクラム 運用において学んだ3つのこと やってみて学んだことは、３つほどあります。 まず1つ目は今やるべきことにフォーカスすることです。Mustでやることにフォーカスして、やるべきタイミングの優先順位をつけることが必要です。 2つ目は、Bizの特徴として社外の ステークホルダー が多く、顧客やサプライパートナーなどに依存する不確実性が多いので、これを先につぶしていくことです。 DoD や担当者は明確になっているか、 ステークホルダー との認識合わせができているか、このあたりを最初に確認しておくことが必要です。 3つ目は、必ず達成することを目標にすることです。コンサバティブになりがちなスプリント計画ばかりでは、 ムーンショット を達成できないので、プロジェクトオーナーや スクラム マスターが連携して対応しています。 見えてきた課題と改善に向けた取り組み このように取り組んできて現時点では半年くらいが経過してきているのですが、スピード感を高めていく点についてはKPI設計を見直したり、 スクラム マスターの育成については、 スクラム マスター横串での連携強化やベストプ ラク ティスの共有などを行いました。 TechでLeSSを導入し始めた話がありましたが、Bizでも10人くらいだったチームが3ヶ月で30人とか40人の規模になってくることもあり、これからLeSS的な取り組みをしようとしているのが、Biz側の状況となります。 パネルディスカッション ここでは以下4つのテーマに関して、パネルディスカッションに参加したTech/Bizのメンバーからのコメントをまとめています。 [1]Biz/Techともに スクラム 導入の背景や、当初解決したかった課題感は何か？ 正林： Bizの方で案件のデリバリーをやっていましたが、お客様も大きくなってきて案件が大型化してきています。 そんな中で、業務の全体像を管理したり、進捗を追っていくこと、タイムボックスを切っていく成果管理のところに課題があり、組織ごとのリーダーの力量によって質が異なりました。 プロジェクトマネジメントの手法がいるよねという話も出ておりましたが、JIRAとセットで使える手法がなかった点が課題でした。 高藤： Techでは不確実に対してどう立ち向かうのかが大きいと思っていましたし、規模や求められるスピード感が変わってきているので。 見える化 も難しくなり、そこをスッキリできるといいなと思っていました。 [2] スクラム を導入してみた時の難しさや、想定していなかった困難とそれらへの対処方法は？ 木岡： そもそもJIRAに慣れておらず、Biz組織もすごいスピードで組織拡大していく中で、自分自身をマネジメントできる人ばかりではない中で スクラム を運営することが難しかったです。 例えば DoD を適切に設定できないことが挙げられます。 これを設定できるようリーダー層にオーナーを任せ、品質を担保できるよう スクラム マスターとしてサポートしていました。 濱口： LeSS自体の困難さと言っても、2〜3チームくらいの規模でしたし、LeSSの特有のチーム横断的なイベントは最小限で行なっていたので、あまり問題は発生しませんでした。 ただし、 スクラム 自体の浸透度やストーリーポイントの理解度について（他のチームと比較したときに消化ポイントが低いことを気にしてしまうメンバーがいる等）は、課題として出てきました。 [3] スクラム 導入の成果を 言語化 すると何か？ 朱： TechとBizで共通言語で議論ができることがよかったです。私が所属しているチームでは、 原価計算 のロジックアップデートをやっているのですが、Biz側で要求を分析していてTech側にシステムに反映するため2つのチームを統合しようとした時に、 スクラム があったのでやりやすかったです。 共通基盤で価値提供がしやすく、スプリントのイベントも一緒にできるので成果の１つかなと感じています。 山下： BizとTechの同じところとして、不確実性が高いので見積るのが難しいことがあります。よって、完了定義を明確化することをみんなが意識し、開発を着手する前に考えておくことができるのは成果だと思います。 違うところとしては、TechとBizではBizの方がチーム一体になっているように見えるのですが、実はプロダクトは1つなのでTechの方がフロントエンドとバックエンドなどお互いがサポートしあっています。 よって、今回の スクラム の目標から、具体的にブレイクダウンしないとBiz側では スクラム を進めるのは難しいと思っています。 正林： 全部が見えるようになったことですね。 第 三者 からみても、 見える化 は進んだと思います。 JIRAと スクラム をセットで運用していたので、プロジェクト管理がそろいました。 キャディは仮説検証を高速で繰り返しているフェーズの会社なので、同じOperating Systemの上で動かせるようになったのは成果です。 [4]今後 スクラム をさらに活用して取り組んでみたいことは何か？ 木岡： Bizでは大きな人数・組織に同時多発的に スクラム を導入したので、各 スクラム で独自の運用となっているケースもあります。 そのため、 スクラム 同士を横串で連携強化したり、標準化を進めることが必要です。 こうすることで、新しく入った人や異動で入ってくる人ともスムーズに入ることができますし、やりづらさが減ると考えています。 佐野： キャディでは、様々なバックグラウンドの人が集まっており、国内・グローバルで今後さらに展開するためには、とても良いメンバーに恵まれていると思っています。なので、Biz スクラム のベストプ ラク ティスといえばキャディだよね、と言われるようになりたいですね。 濱口： この4月からキャディでは次の期が始まりますが、3チームがシステム的に連携するようになりますので、LeSSの真果がこれから問われるだろうなと思っています。 高藤： LeSSの枠組みで活動しているチームと、LeSSの外のチームとの取り組みや改善が今後のテーマになるので、ここをやっていきたいと考えています。 最後に いかがでしたでしょうか？ Tech組織はもちろんBiz組織も積極的に採用を進めておりますので、まずはカジュアルにもっと話を聞いてみたい！という方は、 こちら より申し込んでいただけますと幸いです。 また、イベントに関する情報は、 キャディのconnpass がありますので、こちらも登録いただけると嬉しいです。 最後までお読みいただきまして、ありがとうございます。

キャディでエンジニア採用を担当しています片渕です。 本記事では、2022年3月29日に開催されたエンジニアの社内勉強会「STUDDi」、Yaoからのプレゼン内容をレポート形式でまとめています。 [toc] PLCを語る上で欠かせないのはFA Yao： 私の方からは今回、PLC（Programmable Logic Controller）に関してお話します。 PLCを語る上で欠かせないのはFA(Factory Automation)で、名前の通り生産現場の生産工程の自動化を図るシステムの総称です。 出典： https://www.denso-fy.co.jp/business/ タッチパネルやワーク投入口、非常停止ボタンなどがあります。 FAを構成するコンポーネント FAを構成するコンポーネントを紹介しますと、まずはスライダーです。 出典：IAI 1軸ロボット　 https://www.youtube.com/watch?v=hvGYRJ3Cqys これはFAの中で一番重要なものになりますが、加工するワークを搬送して、加工機に送り込むもので、直線的に移動させるものが必要になります。 シリンダーで動くもので、中にボールネジ（円柱状のネジを切っているもの）が回転して、構造物を動かしている仕組みになっています。 出典：ヤマハリニア搬送　 https://www.youtube.com/watch?v=5bQXPJvl01Y リニア搬送は2015年くらいから始まったもので、ヤマハの製品が有名です。 特徴としては移動が速く、ワークを把持したまま移動できることで、ネジを回転する機構ではなく磁石の力で動かしています。 搬送系は、基本的には端にいくと次の搬送機器に取り置きする機構が必要ですが、リニア搬送では乗り継ぎ機能がついており、取り置きなしでワークを搬送することができます。 しかし、実装管理などが大変なので、大量生産ラインかつ資金が潤沢であるところで利用されることが多いです。 インデックステーブルは簡単な機構かつ安価で、ステッピングモータを使って一定角度ずつ回転するものです。 出典：インデックステーブル　 https://www.youtube.com/watch?v=4q8fpRYNt2w 場所はとりますが、簡単な機構でワークを順送りできるのが特徴です。 それから直行ロボットは、IAIが使っているものを2つ組み合わせていますが、難易度の要求が高くない時によく使われます。 出典：IAI https://www.youtube.com/watch?v=hvGYRJ3Cqys 搬送して、取り置いていく作業が基本動作になります。 その他には、６軸ロボットに加えて、マシンビジョンをつけていくものがあります。 出典：デンソーランダムピッキング　 https://www.youtube.com/watch?v=me1MnsZhwRk 指定されたポイントに移動するものを連続させていくのですが、これはマシンビジョンと組み合わせているので、バラ積みの部品供給などに使われたりします。 本来であれば、パレットに対象物がきちんと並んでいて、定位置で取っていった方がシステム的には安定します。 出典：パーツフィーダー　 https://www.youtube.com/watch?v=PsKvgdphEY8 こちらはパーツフィーダーで、金属部品を投入口に運ぶのですが、圧電素子によって微振動を起こして部品を運んでいくものです。 ランダムな姿勢になっているものを、目的とした姿勢の部品だけを取っていきます。 センサー類としては、スイッチやワークの有無、位置計測に使われるエリアセンサーなどがあります。 コンポーネントはどのように制御されるのか？ さて、ここまでご紹介してきたコンポーネントは、どのように制御されるのでしょうか。 組み込みで思いつくのはマイコン・FPGA・PCなどが考えられがちですが、実際の現場はPLCによって行われています。 PCLはシーケンサーとも呼ばれ、エレベーターなどリレー回路で制御されてきたものの代替装置となります。 リレーシーケンスは、電磁リレーを利用します。電流を流すと金属が引っ付いて、別の端子がOnになるようなスイッチング素子を組み合わせて、エレベータや自動販売機、信号機や工場の自動生産ラインなどで使われてきました。 一例として、自己保持回路というものがあります。ランプをOn/Offを保持する回路を例に考えてみます。 スイッチ緑がOnするとリレー制御側がオンとなり、ランプがついてリレーのOn状態が保持されるというのが自己保持回路というもので、これがシーケンス制御になります。 PLCとは PLCとは、配線によるリレーシーケンス制御を電子的に再現している制御機器です。 PLCを制御するのはラダー言語。 これはリレーシーケンス回路にGUIが備わっており、GUIで定義された回路図を、1つ1つのニーモニックに置き換えられて処理されています。 回路上の、1つ1つの回路への入力・出力を評価していき、最後の回路に到達するとまた先頭の回路に戻ってきます。 この１ループをスキャンといい、1~10msほどの処理時間になります。 PLCでは、スキャンを無限ループしてIO制御をしています。 なぜPLCが使われるのか？ PLC利用がなぜ使われているかというと、プログラミング言語になじみがなくても開発・保守ができる点にあります。 生産設備など複雑なロジックではなくて、センサからの情報と次に起きるアクションを決定するものなので、状態遷移との相性が良いです。 産業機器としても耐環境性あり、機械的・電気的にも強いです。マイコンなどはノイズ対策が必要になりますし、ノイズによってロボットが暴走して意図しない動きをしてしまうと大きなリスクになります。 また、周辺機器が充実しているので、PLCが制御側となりますが、CCリンクで20m先のモータを動かしたり、操作板にてOn/Offが可能です。 PLCは、下位レイヤーに対してはリモートIOを経由し、IO通信に特化したネットワークを経由して、モータやロボットを制御しています。 上位レイヤーに対しては生産ラインの工程管理などIoTなども含め、ロボットの稼働時間や故障時のログを収集するシステムと連携します。 おわりに 以上、Yaoからの社内勉強会の内容をまとめたレポートととなりますが、いかがでしたでしょうか。 記事内容をご覧いただいて、興味持った方は こちら にて、お話する機会をご用意しておりますので、ぜひご活用ください。 また社外向けに一般公開するイベントに関する情報は、 キャディのCONNPASS をご用意しておりますので、こちらもご登録いただけますと幸いです。 最後までお読みいただきまして、ありがとうございます。

キャディでエンジニア採用を担当しております片渕です。 今回は、2022年3月8日に開催されたエンジニアの社内勉強会「STUDDi」、八巻からのプレゼン内容をレポート形式でまとめています。 キャディでは製造業DXに取り組んでおり、社内の受発注オペレーションも内製でシステム開発をしています。 今回のテーマは受発注オペレーションと関わりの深い会計ドメインナレッジの「収益費用対応の原則」になっています。 [toc] 「収益費用対応の原則」について 受発注では取引を通じてお金を扱いますが、このお金の扱い方は会計でルールとして決められています。 その中でも受発注オペレーションと関わりの深い「収益費用対応の原則」を説明します。 用語 「収益費用対応の原則」を説明するために、いくつか会計の用語の説明をします。 仕訳 会計データは仕訳で登録します。会計取引のデータ様式で、取引日・賃貸借の区分・勘定科目・仕訳金額などで構成されます。 仕訳データはイベントデータで、更新はされず常にデータを追加します。 借方・貸方 賃貸借区分とは借方(かりかた)、貸方(かしかた)と呼ばれる区分です。複式簿記の様式で借方が左、貸方が右に記載されます。 勘定科目 勘定科目は取引内容のマスターで、仕入、売上、棚卸し商品などの項目があります。 勘定科目同士が親子関係になることもあります。 勘定科目の「賃貸借区分」は決算で仕分けを集計するときに利用します。 仕訳の「賃貸借区分」と勘定科目の「賃貸借区分」が一致する場合はプラス、異なる場合はマイナスで集計します。 「勘定区分」はどの決算書の項目にまとめるかを決めます。 貸借対照表（BS） 画像の出典 賃借対照表（BS）は、仕訳を資産科目・負債科目・資本科目の３つに分けます。 資産は現金そのものか、売れば現金になるもので、不動産・建物・仕入れてきた商品などです。手形とか売掛金と呼ばれる、いつかお金になる契約形態も資産という扱いになっています。 負債は他から借りているお金で、銀行借入だけではなく、請求書で届くような買掛金なども負債になります。 純資産は会社自体のお金で、資本金や経済活動の結果で利益が出た時の会社に残っているお金になります。 損益計算書（PL） 画像の出典 損益計算書（PL）は、仕訳の収益科目と費用科目を集計したもので、売上高からそれぞれの費用を引いて計算します。 取引データの流れ ここからは「収益費用対応の原則」を理解するために、取引データの流れをみます。 説明の中の図で左側の図形はその取引時点でのBS、右側の図形はその取引の仕訳になります。 事業の立ち上げ 例として、100万円を元手に事業を始めます。 調達 70万を使って商品を仕入れます。 このタイミングではお金は支払わず、後日請求書払いとします。 このタイミングでは会社の資産は商品(70万) + 現金(100万) = 170万になっています。 支払 購入した商品の代金を支払います。 買掛金がなくなり、現金が100万から30万に減っています。 販売 50万円分の商品を100万円で販売します。 ここが今回のポイントになります。 販売の場合には100万円の売上だけでなく、販売した分の商品の仕入の費用を登録しています。 請求・回収 販売した商品の代金を回収します。 売掛金がなくなり、現金が130万になりました。 収益費用対応の原則 取引データの流れのなかで、販売において売上とそれにかかった仕入を登録していました。 これが「収益費用対応の原則」になります。 つまり購入した商品は販売されるまで、費用として計上されないことになります。 例えば、2月に買った商品が3月に売れたとすると、3月になるまで買った商品の費用は計上されません。 これはPLがある期間で集計する際に、損益計算の収益と費用が同じ期間になる必要があるためです。このルールがなければ、収益や費用の登録のタイミングを変更して損益をいじれてしまいます。 ルールとしては「売上の際に費用も計上する」というシンプルなものですが、このルールを知っていれば売上のタイミングでかかった費用が計算できるようになっている必要があると要件を導き出すことができます。 開発に関わる背景を知るひとつの例として、「収益費用対応の原則」のドメインナレッジを紹介しました。 おわりに 八巻からの社内勉強会の内容をまとめたレポートは以上となりますが、いかがでしたでしょうか。 記事内容をご覧いただいて、興味持った方は こちら にて、お話する機会をご用意しておりますので、ぜひご活用ください。 また社外向けに一般公開するイベントに関する情報は、 キャディのCONNPASS をご用意しておりますので、こちらもご登録いただけますと幸いです。 最後までお読みいただきまして、ありがとうございます。

はじめに Rust のマクロ 宣言的マクロ 手続き的マクロ proc_macro_workshop proc_macro_workshop について proc_macro_workshop の進め方 derive(Builder) マクロを作る マクロの処理の流れ マクロを開発する上での Tips dbg!マクロの使用 cargo-expand 01-parse 目標 実装方針 実装 02-create-builder 目標 実装方針 実装 空のbuilder関数をCommand構造体に実装する CommandBuilderを返すようにbuilder関数の実装を変更する 構造体名、フィールド名に応じた Builder 構造体を生成する 03-call-setters 目標 実装方針 実装 04-call-build 目標 実装方針 実装 05-method-chaining 目標 実装方針 実装 まとめ 参考文献 はじめに この記事では proc_macro_workshop というリポジトリを使って Rust の手続き的マクロの作り方を学んでいきます。想定している読者は以下のような方です。 Rust の基本的な文法や概念（トレイトや所有権、ライフタイムなど）を知っている 手続き的マクロの作り方について知りたい この記事では以下のことを説明します。 Rust のマクロの概要 手続き的マクロ（ derive マクロ）の作り方 proc_macro_workshop の進め方 また、この記事では以下のことは説明 しません 。 Rust の基本的な文法や概念 宣言的マクロの作り方 Rust のマクロ Rust のマクロには宣言的マクロと手続き的マクロの 2 種類があります。 宣言的マクロ 宣言的マクロは macro_rules! 構文を使用して定義されるマクロで、match 式に似た形で処理内容を定義します。 vec! や println! など普段良く使うマクロも宣言的マクロです。 宣言的マクロについては The Rust Programming Language 日本語版 に vec! マクロを例にした解説があるので、そちらをご覧ください。 手続き的マクロ 手続き的マクロはトレイトのデフォルト実装の導出に用いる derive マクロなどに代表されるマクロです。宣言的マクロよりも複雑な処理を記述できることが特徴で、以下の 3 種類があります。 derive マクロ 構造体やenumに付与することでその構造体やenumに追加の処理を実装できます 関数風マクロ 関数風マクロは宣言的マクロのように関数呼び出しと似た形で使用できるマクロです。宣言的マクロと比較するとより複雑な処理を記述できます 属性風マクロ deriveマクロと同様に付与した対象に対して追加の処理を実装できますが、こちらは構造体やenumだけでなく関数などにも適用できます。テストを書くときに用いる #[test] アトリビュートなどがこれにあたります 手続き的マクロについては The Rust Programming Language 日本語版 により詳しい説明があるのですが、これだけで実際に使えるような手続き的マクロを作り始めるのは難しいかと思います。この記事では proc_macro_workshop というリポジトリを使って実際に手を動かしながら手続的マクロの作り方を学んでいきます。 proc_macro_workshop proc_macro_workshop について proc_macro_workshop には作成するマクロの種類によって 5 つのプロジェクトがあります。 derive マクロ derive(Builder) derive マクロ derive(CustomDebug) 関数風マクロ seq! 属性風マクロ #[sorted] 属性風マクロ #[bitfield] これらのマクロの内容については proc_macro_workshop リポジトリ をご覧ください。 この記事では、Builder パターンに必要な実装を導出する derive(Builder) プロジェクトを進めつつ手続き的マクロの作成方法を学んでいきます。 derive(Builder) プロジェクトを進めると最終的には以下のような使い方のできるマクロが完成します。 use derive_builder :: Builder; #[derive(Builder)] pub struct Command { executable: String , #[builder(each = "arg" )] args: Vec < String > , #[builder(each = "env" )] env: Vec < String > , current_dir: Option < String > , } fn main () { let command = Command :: builder () . executable ( "cargo" . to_owned ()) . arg ( "build" . to_owned ()) . arg ( "--release" . to_owned ()) . build () . unwrap (); } proc_macro_workshop の進め方 proc_macro_workshop の各プロジェクトは以下の流れで進めていきます。 テストケースを追加する tests/progress.rs に記載されているテストケースのコメントアウトを解除する 追加したテストケースをパスするようなマクロを実装する src/lib.rs に実装します テストをパスしたら 1.に戻る proc_macro_workshop の各プロジェクトにはそれぞれのマクロがパスすべきテストが記載されており、これらのテストに通過するようなマクロを実装することが目標となります。 derive(Builder) プロジェクトの場合は builder/tests ディレクトリにテストケースが記載されたファイルが格納されています。各ステップでテストケースを 1 つずつ増やしていき、これに対応した機能を実装してきます。 プロジェクトの進捗は tests/progress.rs を用いて管理します。 tests/progress.rs は以下のようになっており、各行がそれぞれのテストケースに対応しています。各ステップでテストケースのコメントアウトを解除し、それぞれのテストを通過するように実装を進めていきます。 #[test] fn tests () { let t = trybuild :: TestCases :: new (); t. pass ( "tests/01-parse.rs" ); //t.pass("tests/02-create-builder.rs"); //t.pass("tests/03-call-setters.rs"); //t.pass("tests/04-call-build.rs"); //t.pass("tests/05-method-chaining.rs"); //t.pass("tests/06-optional-field.rs"); //t.pass("tests/07-repeated-field.rs"); //t.compile_fail("tests/08-unrecognized-attribute.rs"); //t.pass("tests/09-redefined-prelude-types.rs"); } 各テストケースにおける目標はテストケースが記載されているファイルのコメントに書いてあります。実際に作業する際はこれらのコメントを参考にしつつ実装していくことになります。 テストは builder ディレクトリで cargo test コマンドを実行することで実行できます。 derive(Builder) マクロを作る derive(Builder) プロジェクトでは大まかに以下のような流れでマクロを作成していきます。 マクロのひな型を用意する 01-parse で作業します builder パターンを実現するために必要な機能（setter メソッドなど）を実装する 02-create-builder ~ 05-method-chaining で作業します エラーハンドリングなどを実装する 06-optional-field ~ 09-redefined-prelude-types で作業します それでは実際にマクロを書いていきましょう。以降の各節の名前はテストファイルの名称と対応しています。以降の各節では以下の流れで進めていきます。 ステップの目標を確認する 実際には具体的なテストケースがありますが、すべて記載すると煩雑なので各ステップのゴールのみ記載します 実装方針の説明 実装 各ステップの最後にテストケースをパスする実装例を提示します マクロの処理の流れ Rust の手続き型マクロの処理は基本的に以下のようになっています。本記事ではこの内容を具体的に実装していきます。 トークン 列を入力として受け取る 受け取ったトークン列を構文木に変換する 変換した構文木をもとに処理を行い所望の構文木を得る 得られた構文木をトークン列に変換して返す トークン列と構文木の相互変換には syn クレート と quote クレート がよく使われます。この記事でもこれらのクレートを用いてマクロを実装します。 syn クレートはトークン列から構文木への変換に使用します。また、 syn クレートには構文木に関する構造体が定義されており、パースして得られた構文木はこれらの構造体のインスタンスとして保持されます。 quote クレートは構文木からトークン列への変換に使用します。 マクロを開発する上での Tips dbg! マクロの使用 マクロのデバッグをする際などには構文木の中身が実際にどうなっているかを知りたくなることがあるかもしれません。 syn クレートの extra-traits フィーチャー を有効にするとこれらの構造体に Debug トレイトが実装されて dbg! マクロを使ったデバッグができます。開発する上で便利なので開発中は有効にしておくと良いでしょう。 syn = { version = "1.0.86" , features = [ "extra-traits" ] } cargo-expand cargo expand を使うとマクロによって生成されたコードを出力できます。これもデバッグに便利なので詰まった時は使うと良いでしょう。 proc-macro-workshop の GitHub リポジトリ と cargo-expand の GitHub リポジトリ に使い方の説明があるので、使う場合はこちらを参照してください。 01-parse 目標 空の derive マクロを作る 実装方針 テストが実行されるのは tests/01-parse.rs の main 関数ですが、このステップでは何も記載がありません。ですので、特に何もしなくてもテストをパスする…かというとそうではなく、 #[derive(Builder)] が使われた際に呼ばれる derive マクロが存在している必要があります。 なぜかというと、テストコード中で以下のように構造体に対して derive マクロが呼ばれているためです。 #[derive(Builder)] pub struct Command { executable: String , args: Vec < String > , env: Vec < String > , current_dir: String , } マクロの基本的な処理内容についてはすでに説明しましたが、より具体的には以下のような流れになっています。 トークン列 proc_macro::TokenStream （以降では基本的に TokenStream と記載します）を引数として受け取る syn::parse_macro_input! マクロでパースして構文木にする パースした構文木を元に所望の構文木を生成する 生成した構文木を TokenStream に変換して返す このステップではマクロが存在していればよいので、1.と 4.の処理を実装すればテストをパスします。 実装 それでは実際に実装をしていきます。 まずは derive マクロの定義から始めます。関数に proc_macro_derive アトリビュートをつけることでその関数内に記載された処理が derive マクロの実装になります。 derive マクロのシグネチャは (TokenStream) -> TokenStream になっており、実態は Rust のトークンを TokenStream という構造体で受け取り、内部で処理した後に TokenStream という構造体として返す関数です。 #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream {} では関数の中身を実装してきましょう。最低限テストが通るためにはこの関数から TokenStream を返せば良いので、以下のように TokenStream を新しく作って返してやれば OK です。 #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { proc_macro :: TokenStream :: new () } このままでも良いのですが、次のステップへの準備として入力をパースできるようにもしておきましょう。入力のパースには syn::parse_macro_input! マクロを使います。derive マクロの入力は syn::DeriveInput で定義される構造をしているので DeriveInput としてパースします。入力をパースする処理を追加すると最終的なマクロの実装は以下のようになります。 use proc_macro :: TokenStream; use syn :: {parse_macro_input, DeriveInput}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let _input = parse_macro_input! (input as DeriveInput); proc_macro :: TokenStream :: new () } 02-create-builder 目標 CommandBuilder 構造体のインスタンスを返す builder 関数を Command 構造体に実装する 実装方針 最終的には以下のような CommandBuilder 構造体のインスタンスを返す builder 関数を Command 構造体に実装するのが目的です。 pub struct CommandBuilder { executable: Option < String > , args: Option < Vec < String >> , env: Option < Vec < String >> , current_dir: Option < Vec < String >> , } 必要な作業は大きく分けて以下の 2 つです。 builder 関数を Command 構造体に実装する CommandBuilder 構造体の定義を実装する 汎用的に使えるようにするには Builder 構造体の構造体名やフィールドの名前、型は derive マクロが適用される構造体に応じたものにする必要がある これを同時に全部進めるのはたいへんですので、以下の順に進めていきます。 空の builder 関数を Command 構造体に実装する CommandBuilder を返すように builder 関数の実装を変更する 構造体名、フィールド名に応じた Builder 構造体を生成する 実装 空の builder 関数を Command 構造体に実装する 前のステップで説明したように、手続き的マクロの処理の概要は以下の通りです。1.と 2.は前のステップで実装しました。このステップでは 3.と 4.の処理を実装していきます。 まずは空の builder 関数を実装する処理を書いていきましょう。この段階では入力について気にする必要はありません。 proc_macro::TokenStream （以降では基本的に TokenStream と記載します）を引数として受け取る syn::parse_macro_input! マクロでパースして構文木にする パースした構文木を元に所望の構文木を生成する 生成した構文木を TokenStream に変換して返す トークン列を生成するためには quote クレートの quote! マクロを使います。以下のように Rust のコードと（ほぼ）同じ構文で記述でき、この内容がトークン列に変換されます。 #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let _input = parse_macro_input! (input as DeriveInput); let expand = quote! { impl Command { pub fn builder () {} } }; proc_macro :: TokenStream :: new () } このままだと proc_macro::TokenStream::new() によって生成された空のトークン列が戻り値として返るので、生成したトークン列を返すようにしましょう。 quote! マクロを使うと proc_macro::TokenStream ではなく proc_macro2::TokenStream が生成されます。 proc_macro2::TokenStream は proc_macro2 クレートによって提供されるトークン列です。 proc_macro::TokenStream が Rust コンパイラの使用するトークン列です。 proc_macro2::TokenStream は proc_macro::TokenStream::from で proc_macro::TokenStream に変換できるので、以下のようにして生成したトークン列を返します。 #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let _input = parse_macro_input! (input as DeriveInput); let expand = quote! { impl Command { pub fn builder () {} } }; proc_macro :: TokenStream :: from (expand) } この段階でのマクロの実装は以下のようになります。 use proc_macro :: TokenStream; use quote :: quote; use syn :: {parse_macro_input, DeriveInput}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let _input = parse_macro_input! (input as DeriveInput); let expand = quote! { impl Command { pub fn builder () {} } }; proc_macro :: TokenStream :: from (expand) } CommandBuilder を返すように builder 関数の実装を変更する 前のステップで実装した builder 関数は空ですので、このままでは何もしてくれません。次の段階として、ハードコードされた CommandBuilder 構造体を返すように builder 関数の実装を変更してみましょう。 まずは CommandBuilder 構造体の定義を quote! マクロ内に追加します。 let expand = quote! { pub struct CommandBuilder { executable: Option < String > , args: Option < Vec < String >> , env: Option < Vec < String >> , current_dir: Option < Vec < String >> , } impl Command { pub fn builder () {} } }; 次に builder 関数内からデフォルト値でフィールドを埋めた CommandBuilder を返すように変更します。 CommandBuilder のフィールドはすべて Optional なので None で埋めておきます。 let expand = quote! { ...略... impl Command { pub fn builder () -> CommandBuilder { CommandBuilder { executable: None , args: None , env: None , current_dir: None , } } } }; 最終的な実装は以下のようになります。 use proc_macro :: TokenStream; use quote :: quote; use syn :: {parse_macro_input, DeriveInput}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let _input = parse_macro_input! (input as DeriveInput); let expand = quote! { pub struct CommandBuilder { executable: Option < String > , args: Option < Vec < String >> , env: Option < Vec < String >> , current_dir: Option < Vec < String >> , } impl Command { pub fn builder () -> CommandBuilder { CommandBuilder { executable: None , args: None , env: None , current_dir: None , } } } }; proc_macro :: TokenStream :: from (expand) } 構造体名、フィールド名に応じた Builder 構造体を生成する さて、ここまでで Command 構造体用の Builder 構造体を返すマクロができました。ただ、このままだとほかの構造体に対して使用できません。derive マクロが適用された構造体の名前やフィールドに応じて適した実装を与えるようにしたいです。Builder 構造体の要件をまとめると以下のようになります。 構造体の名前は derive マクロの適用された構造体名の末尾に Builder を付けたものとする フィールド名は derive マクロの適用された構造体のフィールド名と同じものを使う フィールドの型は derive マクロの適用された構造体のフィールドの型を Optional にしたものとする このような要件を満たすためには derive マクロが適用された構造体の情報を取得する必要があります。では、どこから取得すれば良いのでしょうか。derive マクロの入力をパースすると以下のような syn::DeriveInput 構造体が得られるのですが、実はこの構造体の中に必要な情報が入っています。 pub struct DeriveInput { pub attrs: Vec < Attribute > , pub vis: Visibility, pub ident: Ident, pub generics: Generics, pub data: Data, } このステップに関係する部分は以下の 3 つです。 vis は構造体の可視性の情報を保持しています ident は identifier の略で、変数名などの Rust コード中の識別子の情報を保持しています。ここでは derive マクロが付与された構造体/enum の名前を保持しています data は構造体の保持するフィールドの情報を持っています 構造体名は ident を使えば取得できそうです。derive マクロの使われた構造体名の末尾に Builder を付けたものを Builder 構造体の名前にしたいので、 format_ident! マクロを使って末尾に Builder を結合します。 format_ident! マクロはこのように新たな識別子を作るときに使用します。詳しくは quote クレートの GitHub リポジトリ をご覧ください。 let ident = input.ident; let builder_name = format_ident! ( "{}Builder" , ident); 構造体名についてはこれで良さそうです。次はフィールド名と型を取得しましょう。フィールドの情報は data フィールドに入っているのでした。 syn::Data は以下のような enum です。今回扱うのは構造体なので DataStruct 構造体の中身を見てみましょう。 pub enum Data { Struct (DataStruct), Enum (DataEnum), Union (DataUnion), } syn::DataStruct はこうなっています。 fields がフィールドの情報を持っています。 pub struct DataStruct { pub struct_token: Struct, pub fields: Fields, pub semi_token: Option < Semi > , } Fields は以下のような enum です。 Named が名前のついたフィールドです。今回は Unit 構造体やタプル構造体はサポートしないので Named だけ見てみましょう。 pub enum Fields { Named (FieldsNamed), Unnamed (FieldsUnnamed), Unit, } FieldsNamed はフィールド情報を持っている Field 構造体を複数保持しており、 named.iter() で Field 構造体のインスタンスをイテレートできます。 pub struct FieldsNamed { pub brace_token: Brace, pub named: Punctuated < Field, Comma > , } syn::Field 構造体はこうなっています。 ident がフィールド名で ty が型の情報を持っています。ようやく必要な情報までたどり着きました。 pub struct Field { pub attrs: Vec < Attribute > , pub vis: Visibility, pub ident: Option < Ident > , pub colon_token: Option < Colon > , pub ty: Type, } パターンマッチを使って必要な情報だけを取り出します。サポートしないケースについては今は panic! させておきましょう（後のステップでちゃんとコンパイルエラーが出るようにします）。この後で使いやすいように ident と ty は Vec に格納しておきます。 let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; さて、必要なものはすべて準備できました。これらを使ってマクロの出力として返すトークン列を生成しましょう。 この前のステップで quote! マクロについて Rust のコードと（ほぼ）同じ構文で記述することができ と説明しましたが、 quote! マクロの内部では特殊な記法を使うことができます。たとえば、 quote::ToTokens トレイトを実装する変数に quote! マクロの中で # をつけるとその変数の内容が挿入されます。これを使って適切な名前や型のフィールドを持った構造体を動的に生成します。今までに出てきた syn::Ident などの構造体は quote::ToTokens トレイトを実装しているので特に気にせず使うことができます。 これを使って CommandBuilder 構造体の構造体名を書き直すと以下のようになります。 quote! { #vis struct #builder_name { executable: Option < String > , args: Option < Vec < String >> , env: Option < Vec < String >> , current_dir: Option < Vec < String >> , } } また、 quote! マクロの中では #(...)* のような形で IntoIterator を実装した型の変数を繰り返して挿入できます。これを使って CommandBuilder 構造体のフィールド名も書き換えると以下のようになります。 idents と types はそれぞれフィールド名と型を格納したベクタですので、以下のようにしてベクタの各値について繰り返し展開できます。 ) と * の間に文字を記述するとその文字で区切って展開してくれるので、以下では #(...),* のようにして構造体のフィールドをベクタから生成しています。 quote! { #vis struct #builder_name { #( #idents : Option < #types > ), * } } さて、これでハードコードされた構造体名やフィールド名などをすべて取り除くことができました。 同じように builder 関数も書き換えると以下のようになります。 quote! { #vis struct #builder_name { #( #idents : Option < #types > ), * } impl #ident { pub fn builder () -> #builder_name { #builder_name { #( #idents : None ), * } } } } 以上をまとめると最終的なマクロの実装は以下のようになります。 use proc_macro :: TokenStream; use quote :: {format_ident, quote}; use syn :: {parse_macro_input, Data, DeriveInput, Fields, Ident, Type}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; let expand = quote! { #vis struct #builder_name { #( #idents : Option < #types > ), * } impl #ident { pub fn builder () -> #builder_name { #builder_name { #( #idents : None ), * } } } }; proc_macro :: TokenStream :: from (expand) } 03-call-setters 目標 CommandBuilder 構造体の各フィールドに対する setter メソッドを作る 実装方針 具体的な実装から考えるとやりやすいです。 Command 関数の executable フィールドを例にとると setter は以下のようになるので、これを前のステップと同様、変数の展開や繰り返しを使って書き直しましょう。 pub fn executable ( &mut self , executable: String ) -> &mut Self { self .executable = executable self } 実装 実装方針で書いた具体的なフィールドの実装を書き直しましょう。変数の展開や繰り返しの書き方はすでに説明した通りです。 #(...)* の括弧内には変数以外を入れることもできます。今回は関数の実装自体を #(...)* で繰り返してやれば良いでしょう。 impl #builder_name { #( pub fn #idents ( &mut self , #idents : #types ) -> &mut Self { self . #idents = Some ( #idents ); self }) * } 最終的な実装は以下の通りです。 use proc_macro :: TokenStream; use quote :: {format_ident, quote}; use syn :: {parse_macro_input, Data, DeriveInput, Fields, Ident, Type}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; let expand = quote! { #vis struct #builder_name { #( #idents : Option < #types > ), * } impl #builder_name { #( pub fn #idents ( &mut self , #idents : #types ) -> &mut Self { self . #idents = Some ( #idents ); self }) * } impl #ident { pub fn builder () -> #builder_name { #builder_name { #( #idents : None ), * } } } }; proc_macro :: TokenStream :: from (expand) } 04-call-build 目標 Command 構造体のインスタンスを返す build メソッドを CommandBuilder 構造体に実装する CommandBuilder の各フィールドが None の場合はエラーを返すようにする 実装方針 これも具体的な実装から考えるとわかりやすいです。 Command 構造体の場合は以下のようになるので、これを変数の展開や繰り返しを使って書き直しましょう。 impl CommandBuilder { ...略... pub fn build () -> Result < Command, Box < dyn Error >> { if self .executable. is_none () { return Err (...略...) } ...略... if self .current_dir. is_none () { return Err (...略...) } Command { executable: self .executable. clone (). unwrap (), args: self .args. clone (). unwrap (), env: self .env. clone (). unwrap (), current_dir: self .current_dir. clone (). unwrap (), } } } 実装 ガード節をまず作ります。このように quote! を使って部分的にトークン列を作って後で組み合わせることもできます。 let checks = idents. iter (). map ( | ident | { let err = format! ( "Required field '{}' is missing" , ident. to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()) } } }); 前のステップと同じようにして build 関数を作ります。上で作ったガード節を #(#checks)* で展開しています。 let expand = quote! { ...略... pub fn build ( &mut self ) -> Result < #ident , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #ident { #( #idents : self . #idents . clone (). unwrap ()), * }) } ...略... } 最終的な実装は以下の通りです。 use proc_macro :: TokenStream; use quote :: {format_ident, quote}; use syn :: {parse_macro_input, Data, DeriveInput, Fields, Ident, Type}; #[proc_macro_derive(Builder)] pub fn derive (input: TokenStream) -> TokenStream { let input = parse_macro_input! (input as DeriveInput); let ident = input.ident; let vis = input.vis; let builder_name = format_ident! ( "{}Builder" , ident); let (idents, types): ( Vec < Ident > , Vec < Type > ) = match input.data { Data :: Struct (data) => match data.fields { Fields :: Named (fields) => fields .named . into_iter () . map ( | field | { let ident = field.ident; let ty = field.ty; (ident. unwrap (), ty) }) . unzip (), _ => panic! ( "no unnamed fields are allowed" ), }, _ => panic! ( "expects struct" ), }; let checks = idents. iter (). map ( | ident | { let err = format! ( "Required field '{}' is missing" , ident. to_string ()); quote! { if self . #ident . is_none () { return Err ( #err . into ()) } } }); let expand = quote! { #vis struct #builder_name { #( #idents : Option < #types > ), * } impl #builder_name { #( pub fn #idents ( &mut self , #idents : #types ) -> &mut Self { self . #idents = Some ( #idents ); self }) * pub fn build ( &mut self ) -> Result < #ident , Box < dyn std :: error :: Error >> { #( #checks ) * Ok ( #ident { #( #idents : self . #idents . clone (). unwrap ()), * }) } } impl #ident { pub fn builder () -> #builder_name { #builder_name { #( #idents : None ), * } } } }; proc_macro :: TokenStream :: from (expand) } 05-method-chaining 目標 CommandBuilder 構造体でメソッドチェーンを使えるようにする 実装方針 03-call-setters ステップで実装した setter は &mut Self を返すようになっているので、実はすでにメソッドチェーンを使えるようになっています。そのため、このステップでは追加の実装をする必要はありません。 実装 このステップでは追加の実装は必要ありません。このステップ用のテストを実行して変更なしでテストをパスすることをチェックしてみましょう。 まとめ 前編では Builder パターンを実現するのに最低限必要な機能を持ったマクロを作りました。 しかし、まだ Optional なフィールドの取り扱いに不十分な点があったり、ベクタ型のフィールドの取り扱いに改善の余地があったりします。後編ではそのあたりの機能を実装していきます。 後編へ続く。 参考文献 proc-macro-workshop/builder に取り組む Rust の procedural macro を操って黒魔術師になろう〜proc-macro-workshop の紹介 実践 Rust プログラミング入門 syn - Docs.rs quote - Docs.rs

はじめに こんにちは。2022年に誕生したAI Labというチームで、主に図面解析をしている中村遵介です。 趣味が料理と画像を4倍に拡大することなので、今日は最近読んだ「Revisiting l_1 Loss in Super-Resolution: A Probabilistic View and Beyond[1]」という、画像の拡大で利用される損失関数に関する論文を紹介したいと思います。 趣味以外の理由として、CADDiでは図面画像の解析を行なっておりノイズ除去や画像拡大などの分野に注目しているという点もあります。 畳み込みニューラルネットに関する知識は必要ですが、画像の拡大に関する知識は必要としないように書いたつもりです。 論文の概要 いったん細かい話を置いておいて、論文の概要をざっくりご説明します。 この論文が取り組んだ課題は以下の点になるかと思います。 入力された画像を拡大する超解像分野において、低画質画像と高画質画像を1対1で学習させる既存手法を拡大し、低画質画像から「対応する可能性のある高画質画像の分布」を学習する手法を提案した 提案した損失関数が既存手法で頻繁に使用される l_1 loss を下限に持ち、同時に不可能決定問題としてのランダム性も捉えられることを明らかにした 分布を学習することの副作用として、生成画像に対する画素ごとの不確実性も同時に予測できることを明らかにした それでは詳細についてみていきましょう。 前置き Single Image Super-Resolution について 論文のタイトルは「Super-Resolution」とだけありますが、報告されている内容は Single Image Super-Resolution（SISR） と呼ばれる分野の話になります。 SISRは、日本語で「単一画像超解像」と呼ばれ、 1枚の画像を入力とし、対応する1枚の拡大された画像を出力する タスクを指します。 SISRではバイリニアフィルタによるシンプルな手法もあれば、畳み込みニューラルネット（Convolutional Neural Network: CNN）を用いた手法もあり、画像処理分野では今も盛んに議論が行われる領域です。 これの一つの理由が、SISRが不可能決定問題であるというところにあると思います。つまり、ある低画質画像 x が与えられた際、縮小すると x になる画像、すなわち求めたい綺麗な高画質画像 y は複数存在します。そのため、SISRという問題設計においては正解の手法が存在せず、今後も既存手法より良い結果を得られる手法が登場する可能性が残り続けます。 SISRでよく用いられる損失関数と評価指標 最近では、CNNを使用した教師付き学習を利用した数多くのCNNが提案されています。学習方法やネットワーク構造など様々な点が議論されていますが、学習時に利用する損失関数に着目すると、大きく4つに分けられるかと思います。 生成画像と教師画像の l_2 loss 生成画像と教師画像の l_1 loss 生成画像と教師画像の perceptual loss 生成画像と教師画像の discriminator loss このうち l_2 loss と l_1 loss は非常に似ており、生成画像 y と 教師画像 \hat{y} に対して画素ごとに二乗誤差もしくは絶対誤差を計算して、その合計値を最小化することでより教師画像に近い画像を生成しようと試みます。 3番目のperceptual loss は特徴空間での比較を行います。具体的には、生成画像と教師画像をなんらかの学習済みCNNに通し、途中で得られる深層特徴について、その二乗誤差もしくは絶対誤差を最小化しようと試みます。 最後の discriminator loss はGenerative Adversarial Network（GAN）ベースの手法で利用される損失関数で、生成画像と教師画像を見分けるネットワークを同時に訓練し、生成ネットワークはなるべく見分けがつかないような画像を出力しようと学習していきます。 これらの損失関数は単独で使用されることもあれば、組み合わせて使用されることもあります。 一方で評価指標は大きく分けて3つ存在します。 Peak Signal-to-Noise Ratio（PSNR） 二乗誤差ベースで生成画像と教師画像の近さを比較します。値が大きいほど2つの画像が近いことを意味します Structural Similarity Index Measure（SSIM） パッチの統計情報ベースで生成画像と教師画像の近さを比較します。値が1に近いほど2つの画像が近いことを意味します MOS（Mean Opinion Score） 複数の評価者による5段階評価で画像の綺麗さ・自然さを評価します。5が理想的な高画質画像であることを意味します L1 loss の限界 SISRに対するCNNベースの教師付き学習では、 l_2 loss もしくは l_1 lossが使用されることが多いです。特に近年では l_1 lossがPSNR/SSIM/見た目の点で l_2 lossより優れているというのが実験的に言われ、 l_1 lossが使用される傾向が強まっています。 やや横道に逸れて歴史の話をすると、最初にCNNがSISRに適用されたのがSRCNN[2]という手法でした。これは l_2 lossを損失関数に利用した3層のネットワークで、当時の手法から大きくPSNRを向上させました。その後に登場するESPCN[3]やVDSR[4]・DRCN[5]では高速化やネットワークの層数の増加が行われましたが、やはり l_2 lossを使用する点は変わりませんでした。 PSNRが二乗誤差を元に計算されるため、この傾向は非常に自然な流れであったと思われます。 流れが変わったのが SRGAN[6] と呼ばれるGANベースの手法の登場です。SRGANは discriminator loss を採用することで、不可能決定問題に対してGANで「低画質画像 x に対応し、かつ高画質画像として自然な分布から生成されたかのような綺麗な画像 y 」を生成するという一つの解を提案しました。その中では学習の安定化のために、perceptual loss、そしてやはり l_2 loss が使用されていました。このSRGANの生成部分のネットワークはSRResNetと呼ばれ残差構造を積極的に取り入れた手法だったのですが、このネットワーク構造がSISRに向いていることがわかり、後の多くの手法がこのSRResNetを参考にしています。 その中でも注目を集めたのがEDSR[7]という手法で、EDSRはSRResNetを巨大化させたネットワークです。徒に巨大化させたわけではなく、例えばそれまで使用されてきたバッチ正規化を「実際に学習させてみた結果、ほぼ正規化能力が失われていた」ということで削除したり、より残差構造を取り入れたりといった工夫をしています。そして、はっきりと l_1 lossによる学習がPSNR/SSIMの両者において良い結果を示したことを報告しました。 We train our networks using L1 loss instead of L2. Minimizing L2 is generally preferred since it maximizes the PSNR. However, based on a series of experiments we empirically found that L1 loss provides better convergence than L2. EDSR[7]より引用 以降は多くの場合で l_2 lossの代わりに l_1 lossを損失関数に採用することが増えています。安定的に高パフォーマンスを出せるRCAN[8]も l_1 lossで学習を行なっています。 話を戻します。 l_1 loss が l_2 lossより実験的に優れていること自体は良いのですが、その本質はあまり変わりがありません。縮小したらある低画質画像 x になる高画質画像の集合を 仮に y とすると、 l_2 loss での学習は、これら y の平均値を学習することと等しく、 l_1 lossは中央値を学習することに等しいです。 つまり、 l_2 loss も l_1 loss も解空間のある一点だけを捉えようとする損失関数であり、解空間そのものを捉えるには不十分であると言えます。 そこで、論文ではパラメータ W と入力 x が与えられた時の高画質画像 y の事後分布を明示的にモデリングすることで、解空間を推定することに注力します。 確率的モデリング 多くの既存手法では以下の尤度関数の最大化を目的とします。 \max_{W}{L\left(W\mid\hat{y}\right)} = P\left(\hat{y}\mid x;W\right). W がパラメータで、 \left( x, \hat{y} \right) が学習データとして用意された低画質画像と高画質画像のペアです。論文の根幹は事後分布 P(y\mid x;W) の明示的な推定です。 ここでいう y は高画質画像として可能性のある複数の自然画像を意味しています。このとき、 \hat{y} は P(y\mid x;W) に従って高い確率で生成された画像のうちの1枚とみなすことができます。 つまり、最終的には以下の確率を最大化したいことになります。 P\left(\hat{y}, y\mid x;W\right) = P\left(\hat{y}\mid y\right)P\left(y\mid x;W\right). 日本語で言えば「入力 x とパラメータ W が与えられた条件での、高画質画像の確率分布に対し観測された \hat{y} がその分布から生成される確率」を最大にしたい、という感じでしょうか。 ここでは y が無数に存在するので扱いやすくするため期待値を考えることにしています。 \mathbb{E}_{y\sim P\left(y\mid x;W\right)}\left[P\left(\hat{y}\mid y\right)\right] あとはこれをいくつかの仮定をおきながら分解して考えるだけです。まず第一に「入力 x とパラメータ W が与えられた条件での、高画質画像の確率分布（ P\left(y\mid x;W\right) ）」を噛み砕いていみます。 論文では、ある画素は似た領域の加重平均で表せるという仮定と中心極限定理から、この分布は多変量正規分布に従うという仮定を置いています。 P\left(\hat{y}, y\mid x;W\right) \sim N\left(\mu_{\left(x;w\right)};\Sigma_{\left(x;w\right)}\right) ここで出てきた \mu と \Sigma はパラメータ W を用いてCNNで実際に推論するものになります。また、 P\left(\hat{y}, y\mid x;W\right) が多変量正規分布に従うという仮定を置きましたが、実際にこれを利用して学習する場合、分布からのサンプリングを行う必要があります。これは微分可能な操作ではないという問題がありますが、これに関してはすでに Variational Auto-Encoder[9] が Reparameterization Trick と呼ばれる方法での回避を提案しているので、そのまま利用することにしています。 すなわち、標準正規分布から生成される z を用いて \mathbb{E}_{y\sim P\left(y\mid x;W\right)}\left[P\left(\hat{y}\mid y\right)\right] = \mathbb{E}_{z\sim N\left(0, 1\right)}\left[P\left(\hat{y}\mid \mu + \sigma \ast z\right)\right]. のように y を捉え直すことで微分可能にします。 P\left(y\mid x;W\right) については考え終わったので、残っている P\left(\hat{y}\mid y\right) をみていきます。 ここでは、[10]に従ってこの分布をボルツマン分布に従うと仮定します。 P\left(\hat{y}\mid y\right) \propto \prod_{i}^{H\times W} \exp \left( – \frac{\|\hat{y}_i – y_i\|_1}{kT} \right) これを先程の式に代入することで最終的な目的関数を得ることができます。 \mathbb{E}_{z\sim N\left(0, 1\right)}\left[\prod_{i}^{H\times W} \exp \left( – \frac{\|\hat{y}_i – \left(\mu_i + \sigma_i \ast z\right)\|_1}{kT} \right)\right] あとは扱いやすいように負の対数尤度関数にして、最大化問題を最小化問題へと変更しています。 \min\mathbb{E}_{z}\left[\frac{1}{kT} \sum_{i}^{H\times W}{\|\hat{y}_i – \left(\mu_i + \sigma_i \ast z\right)\|_1}\right] kT は定数なので無視することにすると、結局のところは上の式を最小化する \mu と \sigma の2つををCNNで推定してあげれば良いことがわかります。その際に z がランダム性を与えてくれるイメージです。 ちなみに z は標準正規分布なのでその期待値は0になります。つまり、上の式は（Jensenの不等式にそのまま代入すると）下限が \hat{y} と \mu の l_1 lossになります。 こうして振り返ってみると、 l_1 lossが分布の1点だけしか捉えられていなかったことがよくわかります。 さて上式の最小化ですが1点だけ困った点があり、それはネットワークとしては \sigma を0としてしまう（ランダム性を排除して l_1 lossと同等にする）のが最も最小化できる戦略になる、ということです。 論文ではこれを実験的にも確かめ、 \sigma が0に落ちる様子をプロットしてくれています。 そこで、 \sigma を0にせず（ランダム性を失わず）良い感じに勾配降下法で常識を最小化するための設計を提案しています。 分散の実践的な設計 論文では、実際に学習させるための \sigma の設計を2パターン挙げており、それぞれを「入力データに依存しない \sigma 」と「入力データに依存する \sigma 」と呼んでいます。 最終的に選択しているのは後者の方ですが、せっかくですので両方見ていきます。 データに依存しない分散 データに依存しない分散 \sigma の設計は実に簡単で、「学習によって \sigma が0に収束してしまうなら、 \sigma を学習しなければいい」というものです。 すなわち、あらかじめ \sigma を非常に小さな定数 k として設定する、という方法です。この場合、最適化対象は以下のように読み替えられます（余計な定数は除外しました）。 \mathbb{E}_{z}\left[\sum_{i}^{H\times W}{\|\hat{y}_i – \left(\mu_i + \sigma_i \ast z\right)\|_1}\right] = \mathbb{E}_{z}\left[\sum_{i}^{H\times W}{\|\left(\hat{y}_i + k \cdot z\right) – \mu_i\|_1}\right]. これは、すなわち教師データである \hat{y} に対して、平均0、分散 k のガウシアンノイズをかけてから l_1 loss で学習させていることと同義です。 この考え方自体は Noise2Noise[11] と似ています。Noise2Noiseは、（ノイズ画像、綺麗な画像）というペアを用いでデノイジングを学習するのではなく、（ノイズ画像、ノイズ画像）のペアを用いても同等の性能が得られる、ということを示した論文です。ただし、事前条件としてガウシアンノイズであれば平均が0の分布に従う必要があります。また、理論的には l_2 lossでの精度を保証したものですが（ l_2 lossが平均値を推定するため）、実験では l_1 lossでも良い性能を示すことを報告してくれています。今回は乗せるノイズは平均0のガウシアンノイズなので問題なしです。 しかし、この方法だとノイズによっては \mu が \hat{y} に対して遠ざかるような方向の勾配を産む可能性があります。これは先程の式を \mu で偏微分すれば明らかで、余計な定数項を除くと \frac{\partial \| \hat{y} + k\cdot z – \mu \|_1}{\partial \mu} となりますが、これは \hat{y} と \mu – k \cdot z との大小関係で符号が入れ替わります。 一方で、一般的な l_1 lossに関しては \frac{\partial \| \hat{y} – \mu \|_1}{\partial \mu} なので \hat{y} と \mu との大小関係で符号が入れ替わります。このため、 \mu – k \cdot z と \mu の間に \hat{y} が存在するような z では、 l_1 lossによる学習と、提案する学習では勾配の方向が逆転します。 この勾配の逆転による学習の不安定化を防ぐためには、十分な数の z のサンプリングが必要になりますが、これは学習コストが肥大化を意味し、論文では使用されませんでした。 データに依存する分散 やや天下り的なのですが、 \sigma を定数 k ではなく |\hat{y} – \mu| に設定してみます。 これによって、ネットワークが求めるべき \mu は以下であれば良いということになります。 \min_{\mu}\mathbb{E}_{z}\left[\frac{1}{kT} \sum_{i}^{H\times W}{\|\hat{y}_i – \left(\mu_i + |\hat{y}_i – \mu_i| \ast z\right)\|_1}\right] これを \mu で偏微分すると（余分な定数項は除外） \frac{\partial \mathbb{E}_{z}\left[\sum_{i}^{H\times W}{\|\hat{y}_i – \left(\mu_i + |\hat{y}_i – \mu_i| \ast z\right)\|_1}\right]}{\partial \mu_i} となります。これは \hat{y} と \mu との大小関係でのみ符号が入れ替わるので、勾配の符号だけ見れば l_1 lossで学習するのと同義です。また、 \sigma が0に収束するということは、 \mu と \hat{y} が完全に一致することを意味しますが、それはSISRの不可能決定性に反するので、過学習しない限りは起きないことになります。 論文ではこれを l_\mathbb{E} loss として呼んでいます。 ここで l_\mathbb{E} lossの意味合いを振り返ると、考え方としては y の分布の平均 \mu を予測しつつ、同時に \hat{y} と \mu の誤差も分散として使用することを意味します。 そこで、単に上式を最適化するだけでなく、ネットワーク上では1つのブランチで y の分布の平均 \mu を予測しつつ、同時に別のブランチで \hat{y} と \mu の誤差を予測し、それを \sigma として扱うマルチタスクラーニングとしても良さそうです。 \sigma ブランチでは \min_{\sigma} \| |\hat{y} – \mu| – \sigma \|_1 を求めれば良いことになります。論文ではこれをauxillary lossとして命名しています。 この \sigma を推論しておくメリットとして、 \sigma の値が予測の自信度として使用できる、という点を挙げています。 実験 理論が出来上がったので後は実験して評価をします。 論文では一般的なSISRの実験と同じ設定を用いていました。 学習にはDIV2Kデータセットのtraining setを使用し、評価データセットではSet5 / Set14 / BSD100 / Urban100 / Manga109データセットを使用します。Manga109は比較的新しいデータセットなので、3,4年より前のSISR論文では評価に使用していない場合もあります。 また、Set5 / Set14は慣習的に使用しますが、枚数がそれぞれ5枚 / 14枚なので評価値としてはブレが大きい印象があります。 拡大倍率については、2 / 3 / 4倍について実験を行なっています。最近だと8倍についても実験する論文を見かけることがあります。 評価指標は輝度に対するPSNRとSSIMを使用しています。 学習の詳細についてはあまり触れませんが、入力 x が48px x 48pxになるようにクロップしてリサイズしています。これは、SISRでは広範囲のコンテキストを必要としないという前提に基づくことが多く、他の多くの論文でもあまり大きな画像を入力に用いることはありません。 そのため、RCANのような大きいモデルであってもV100を1枚で十分学習が可能です。 最終的な推論結果としては \mu を使用しています。 提案手法は損失関数を調整し、また最後に \sigma 推論用のブランチを追加するだけで実現できるため、基本的にどのようなCNNにも適用できます。そこで、論文では、VDSR / SRResNet / EDSR / RCAN といった有名どころのCNNに適用し、 l_1 loss との比較を行なっています。 軽量なモデルに対して提案手法を適用した結果の比較（EDSR-baselineはEDSRの中で提案されている比較的軽量なモデルです） 重いモデルに対して提案手法を適用した結果の比較 PSNR/SSIMともに上がり幅としては僅かに見えますが、CNNベースのSISRの精度は年々上がり幅が小さくなっているので、それを踏まえて見ると悪くない結果のように思えます。 比較実験 提案手法の有効性を確認するために、以下の実験を行なっています。 損失を l_1 lossだけにして学習 損失を l_\mathbb{E} loss だけにして学習（論文ではEq. (8)として登場） 損失を auxillary loss だけにして学習（論文ではEq. (10)として登場） 損失を l_1 loss と auxillary loss で学習 損失を l_\mathbb{E} loss と auxillary loss で学習 それぞれについて、ベースネットワークとしてEDSRを使用し、Set14でPSNR/SSIMを評価しています。学習時間はやはり伸びますが、PSNR/SSIMとしては提案手法が最も良い結果を示していました。 予測の自信度の可視化 推測した \sigma を使用してモデルの自信度を画素ごとに表示させています。 当然と言えば当然なのですが、画像のエッジ部分（高周波部分）でモデルが自信をなくしているのが分かります。 感想 l_1 lossは近年のCNNベースのSISRで積極的に利用されてきましたが、きちんと焦点を当てている論文は中々限られているように思っていたので新鮮でした。 一方で、最終的な推論結果を \mu のみから導き出していた点がやや疑問点として残りました。結果として分布の平均値をピックアップせざるを得ないのかな、という印象です。 \sigma の結果を利用して、自信がない領域だけ生成的な手法で推測してあげる、みたいなことが出来たら面白いのかもしれないなぁ…というような未来を感じさせる論文でした。 引用 [1] He, Xiangyu, and Jian Cheng. “Revisiting L1 Loss in Super-Resolution: A Probabilistic View and Beyond.” arXiv preprint arXiv:2201.10084 (2022). [2] Dong, Chao, et al. “Image super-resolution using deep convolutional networks.” TPAMI 2015. [3] Shi, Wenzhe, et al. “Real-time single image and video super-resolution using an efficient sub-pixel convolutional neural network.” CVPR 2016. [4] Kim, Jiwon, Jung Kwon Lee, and Kyoung Mu Lee. “Accurate image super-resolution using very deep convolutional networks.” CVPR 2016. [5] Kim, Jiwon, Jung Kwon Lee, and Kyoung Mu Lee. “Deeply-recursive convolutional network for image super-resolution.” CVPR 2016. [6] Ledig, Christian, et al. “Photo-realistic single image super-resolution using a generative adversarial network.” CVPR 2017. [7] Lim, Bee, et al. “Enhanced deep residual networks for single image super-resolution.” CVPR workshops 2017. [8] Zhang, Yulun, et al. “Image super-resolution using very deep residual channel attention networks.” ECCV 2018. [9] Kingma, Diederik P., and Max Welling. “Auto-encoding variational bayes.” ICLR 2014. [10] Bruna, Joan, Pablo Sprechmann, and Yann LeCun. “Super-resolution with deep convolutional sufficient statistics.” ICLR 2016. [11] Lehtinen, Jaakko, et al. “Noise2Noise: Learning image restoration without clean data.” ICML2018 The post Revisiting L1 Loss in Super-Resolution: A Probabilistic View and Beyond を読んで appeared first on CADDi Tech Blog .