Auroraクローン機能を使ってコピーDBを作成する方法

この記事は弥生 Advent Calendar 2024の14日目の記事です。

qiita.com

はじめに

こんにちは。弥生でエンジニアをしている田邊です。

システムを運用するために本番環境のコピーDBを用意する場合、これまではスナップショットから復元する方法を利用していました。
あるタイミングでAuroraクローンの機能を知り、実際に業務目的で使ってみたところ、スナップショットから復元するより便利なポイントがあると感じました。

本記事では、Auroraクローンのメリットや作成手順について書いていきます(本記事に記載の内容は2024年12月現在の情報です)。
Auroraクローンについて気になっていた、使ってみたいが手順が分からないという方はぜひ参考にしてもらえればと思います。

※本記事ではAuroraクローンの機能にフォーカスして記載します。本番環境のコピーDB作成時に行うマスク処理等の個人情報管理上の作業は省略しています。

Auroraクローンとは

Auroraクローンとは、AWSのAmazon Auroraの機能の一つで、あるクラスターと同じデータページを共有する新しいクラスターを作成できる機能です。
要はクラスターをコピーすることができるものになります。
運用用のコピーDBを作成したり、データの分析等のクエリを本番環境に影響を与えずに実行したりする用途で使うことができます

Auroraクローンの大きな特徴はコピーオンライトプロトコルです。これはコスト効率良くクラスターのコピーを作る手法です。

Aurora DB クラスターでは、通常では以下のようにAuroraストレージボリュームのページにデータが格納されています。

Aurora クローン機能を使うと、新たにクラスターを作った上で、データページは共有された状態になります
これによって、同じデータを持つクラスターを複製することができます。

クローン作成後にクローン元のデータが変更された場合、その差分だけデータページが更新され、共有されなくなります。
クローン先のデータには影響がありません。

逆にクローン先のデータが変更された場合も、その差分だけデータページが更新され、共有されなくなります。
クローン元のデータには影響がありません。

このような形で、データページを共有した上で、クローン元、クローン先でお互いに影響しない状態でクラスターを複製することができるのが特徴です。

クローンのメリット

上記のようにスナップショット的に同じデータを持つDBクラスターを作成できるのがクローンの機能ですが、それであればRDSのスナップショットを復元するのとあまり変わらないように思えます。
スナップショットと比較して、クローンのメリットは以下の2つが挙げられます。

  • コスト効率が良い
  • 素早く作成が可能

コスト効率について、スナップショットを作成した場合、複製元と複製先は全く別のクラスターとなるため、複製先のクラスターでもインスタンスのコストとデータベースストレージのコスト両方が発生します。
一方で、クローンであれば上記のコピーオンライトプロトコルの仕組みのように、初期状態ではデータページを共有した状態となるため、その分ストレージのコストを抑えることができます。もちろんデータ更新が多くなると共有しないストレージが増えるため、抑えられるコスト幅は小さくなります。
また、クラスターを作成するまでの時間についても、スナップショットの場合、スナップショット作成とスナップショット復元によるクラスター作成のそれぞれにかなり時間がかかりますが、クローンの場合、DBクラスターの作成のみの時間で済むため、複製までの時間を短くすることが可能です

クローン作成手順

まずは複製元となるクラスターを用意します。

複製元のクラスターを選択し、アクション>クローンの作成を選択します。

クローン作成画面では、複製先のDBインスタンス名を指定します。

その他の設定はAurora作成時と同様です。設定が全て完了したら「クローンの作成」を選択します。

選択後、クローンが作成中になります。クローンのクラスター名は指定したDBインスタンス名から自動で命名されますが、後から変更も可能です。

しばらく経つとクローンのクラスター、インスタンスが利用可能に変わります。利用可能に変わるまでの時間はストレージの量によって変わります。

これでDBの複製が完了します。複製後のDBへのアクセス、操作が可能になります。

アカウントをまたがるクローンの作成

本番環境のコピーDBの場合、開発環境などの別アカウントにクローンを作成したいケースが多いと思います。
別アカウントにクローンを作成する場合も手順はあまり変わりませんが、以下の追加作業が必要になります。

  • Resource Access Managerによるリソースの共有
  • 暗号化キーの使用許可付与

Resource Access Managerについて、複製元のDBクラスターのあるアカウントから複製先のDBクラスターを配置したいアカウントにリソースを共有することで、クローンが可能になります。
複製元のDBクラスターのあるアカウントでResource Access Managerにアクセスし、「リソース共有を作成」を選択します。

リソースで「Aurora DB クラスター」を選択し、共有したいDB識別子を選択します。

プリンシパルで複製先のDBクラスターを配置したいアカウントIDを入力し、「追加」を選択します。

「追加」を選択することで、「選択されたプリンシパル」に共有先のアカウントIDが追加されます。この状態でRAMを作成することで共有先のアカウントでDBクラスターを参照することができるようになります
その後、共有先のアカウントで、クローン作成を行うことで、DBを複製することができます。

暗号化キーについて、DBクラスターを作成する際に暗号化キーを指定することができますが、クローンの作成の際にその暗号化キーを使用する必要があります。
そのため、DBクラスターのあるアカウントと異なるアカウントでクローンを行う場合、暗号化キーの使用を複製先のアカウントに許可する必要があります。
もし暗号化キーにAWSのマネージドキーを利用すると、別アカウントに使用を許可できないため、別アカウントでのクローン作成ができません。

マネージドキーを使うとアカウントをまたがるクローンができない

別アカウントでクローンする場合、複製元であるDBの暗号化にはカスタマー管理型キーを作成して使用する必要があります。キーの作成時に「別のAWSアカウント」を指定することで、別アカウントに該当のキーを使用するポリシーを付与することができます。

アカウントIDは仮の値

指定することで、キーポリシーに別アカウントへの使用許可が追加されます。

このように作成したキーを暗号化キーに指定することで、別アカウントでクローン作成することが可能になります。

おわりに

以上が、Auroraクローン機能の紹介になります。今後Auroraクローン機能を使用する人の参考になれば幸いです。


弥生では一緒に働く仲間を募集しています。
開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。
herp.careers

販売課金システムの移行体験談

はじめに

こんにちは。弥生で販売課金システムのエンジニアをしています、Kです。
このブログは弥生 AdventCalendar 2024 の13日目の記事です。
本記事では、弊社の販売課金システムの移行プロジェクトについて記載します。

ざっくりと販売課金システムについて説明

弊社の販売課金システムは、新システムと旧システムの並行稼働で運用していました。
「デスクトップソフト」および「あんしん保守サポート」の契約管理は旧システムで行っていましたが、ゆくゆくは新システムに移行する計画でした。
私が5年前に入社した時も、社内研修などで全社的な大きな課題として話されていたのを覚えています。
当時は正直「へー、大変そうだな(遠い目)」と思っていましたが、 まさかそのプロジェクトに自分が深く関わることになるとは思いませんでした。
今回は移行プロジェクトで成し遂げたことや大変だったこと、学びなどをまとめてみたいと思います。

システム移行の概要

旧システムには、新システムと同様に画面の契約導線が存在し、 バックエンドも新システムとは別に持っています。
以下のような順に移行の準備、実施を行います。

  
新システム側に、必要な画面の追加やバックエンド機能の追加
(旧システムでできていたことで必要なもの精査し、新システムにも機能を作る)
↓
新システム側だけで、デスクトップ製品の契約操作や管理ができる状態にする
 ⇒ここまでで、移行先の箱はできた状態
↓
旧システムのデータ構造から、新システムのデータ構造に置き換える「データの移行」を行う
  

また、移行のタイミングについては移行期間を設けて、その間はお客様の好きなタイミングでデータの移行を行うことができます。
ただし、ある程度早めに移行を進めたいため、契約期間に応じて月初にまとめて自動移行する仕組みも導入しました。
毎月月初に、母数の約1/12のデータが移行されるというものです。

システム移行リリースまで

私はデータ移行の実装をメインで担当していましたが、着手前から大きな壁にぶち当たっていました。それは…
”そもそも旧システムのデータ構造が全く分からない!!”

旧システムの画面を見たことは何度かありましたが、詳細な契約導線やバックエンドの構造などは全くもって知りませんでした。
DBのテーブル名も一つもわからないという状況でした!
そんな状況でしたが、以下のような順に進めていきました。

  
とっかかりとして、旧システムを知っている有識者に相談
↓
細かいところはさておき、最低限軸となるデータ構造(今回の場合、契約内容や契約期間など)
が分かったところで、最もシンプルなケースの移行を、詳細なデータ構造込みで描いてみる
↓
上記を有識者レビューしてもらい、指摘やアドバイスをいただく
↓
開発環境で、上記のプロトタイプを実装してみる(実現可能性のチェック)
↓
上記を軸に、他に必要な情報が何かを洗い出す
↓
必要な情報の洗い出し後、それらに対してパターンの網羅を行い、移行前後のデータ構造を確定する
↓
上記を実現するためのプログラムを、プロトタイプをもとに設計する
  

一番重要だと感じたのが、まずシンプルなケースをプロトタイプ作成まで実装することです。
基本的なデータ構造の理解や実現可能性まである程度検証できるため、このステップは複雑なシステム移行には必須の手順だと思います。
ここまでできてしまえば、これを軸にパターン分けをしていく作業になります。
パターン分けの際、どうしても実現が難しいケースがあった場合は、移行とは別の機能で補完するか、もしくは移行対象外とするような対策を取ります。
実際はプロトタイプ作成から最終的な仕様確定・リリースまでには色々課題が見つかりましたが、 移行ロジックや周辺機能による補完で、何とかテストをクリアできました。

システム移行リリース後

システム移行機能のリリースは無事成功しました。(実はリリース当日も色々あったのですが…)
リリース当初はいくつか不具合があり、移行時にエラーになってしまうお客様もいらっしゃいました。
加えて、エラーになった方だけでなく、希望通りの移行がされなかった方から問い合わせがカスタマーセンターに殺到しました。
リリース後に一番大変だったのは、上記のようなお客様への対応でした。
システム移行は弊社の都合で行うものであって、決してお客様が悪いわけではないので、 お客様の希望通りに契約管理ができるように、お客様対応や場合によってはシステムメンテナンスで対応する必要がありました。

これは後から聞いた話ですが、リリース当時のカスタマーセンターは大混乱で、応答率の低下もさることながら、 どう対応したらいいかもわからないケースが多い状況でした。
(問い合わせの原因が、システム障害なのか、お客様の操作ミスもしくは元のデータが悪かったのかが切り分けられなかった。)
カスタマーセンターの方と直接会って話を聞く中で、改善が必要だと感じた点は以下です。

  
・お客様影響が大きいリリースの直後は、開発本部への問い合わせ窓口を多く持っておく
・同時に、すぐに相談できる開発担当の有識者を現場に派遣し、迅速なエスカレーションができるようにする
  

正直、大規模なリリース直後は不具合対応などで開発本部も余裕がないため(実際余裕はなかった)、実現できるかはわかりません。
しかし、当時は上記のような発想自体無く、現にカスタマーセンターは大混乱で、開発担当もなかなかエスカレーションに対応できていなかったです。
次回こういった"お客様影響の大きい"リリースがある場合は、事前にエスカレーション担当を確保するなどの対策をとろうと考えています。

実はリリース直後ではないですが、上記のように開発担当者が現場にいてほしいという意見があったので、 移行の最繁忙期に私が1週間ほどカスタマーセンターに出張し、現場でエスカレーション業務をしていました。
その時は既に対応方針がある程度確立されているものが多かったので、頻繁にエスカレーションが来ることはなかったですが、 「やはりすぐに開発担当に質問できるとその場で解決できるし効率が上がる、あるいは安心する」という声が多くありました。
そういった声からも、上記のような対策は必要だと考えます。

まとめ

システム移行のとっかかりとしては、まず移行元のシステムの有識者にヒヤリングし、シンプルなケースで移行方針を決定&プロトタイプ作成まで実施すると良いです。
また、お客様影響の大きいリリースになる場合は、開発担当者の一部をカスタマーセンターからの問い合わせ担当にするなどの工夫をする必要があります。
弊社の基幹システム移行に関する実話なので、あまりシステムの詳細に踏み込んだ具体的な話は書けませんでしたが、 今後大規模なシステム移行を担当する方には是非参考にしていただきたいと思っています。

最後に

弥生では一緒に働く仲間を募集しています。
開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。

herp.careers

タスクスケジューラの実行環境を Azure へ移行したお話

この記事は弥生 Advent Calendar 2024の12日目の記事です。

こんにちは!弥生のサービスプラットフォーム部でエンジニアをしている寺山です。
中途で入社して約2年間、主に Azure 環境の運用保守に携わっています。

早速ですが、業務効率化や生産性向上を目指すにあたって「自動化」は欠かせないですよね!
今回は、Azure 環境で稼働しているサービスの運用効率化を目的に、自動化基盤をオンプレミスから Azure へ移行したお話をご紹介したいと思います。

はじめに

IT サービスを運用していくにあたって、多かれ少なかれ定型タスクが存在すると思います。
私が担当しているサービスにおいても、データ抽出用 DB コピー、運用メンバーのユーザー作成、一部カラムのマスキング、 KPI などのデータ抽出、オートスケール など、数多くの定型タスクが自動化されています。
当初、これらはオンプレミスの Windows Server 上でタスクスケジューラによって定期実行されていました。
しかしながら、このやり方にはいくつか問題があります。

①タスクが失敗しても気づけない

タスクスケジューラは設定したスケジュールに基づいてタスクを起動してくれますが、実行結果を監視する機能はありません。
別途仕組みを作り込む必要がありますが、そのようなことはしていませんでした。
そのため、あるタスクの失敗を検知することができず、他チームからの問い合わせで発覚して手動対応なんてこともたまにありました。

②実行元が止まるとタスクが実行されない

実行元である Windows Server はオンプレミスのメンテナンス用仮想マシンで冗長化も考慮されていません。
そのため、仮想マシンがダウンするとタスクが軒並み実行されないというリスクを常に抱えていました。
実際にダウンすることはありませんでしたが、もし起きた場合は1つずつ手動で実行するようなリカバリ対応が必要となります。(非常に面倒くさい、、)

③実行環境を自ら管理しないといけない

タスクスケジューラで定期実行しているスクリプトは主に PowerShell で記述されています。
例えば、複数の Azure リソースに対する操作を同時並行で実施する場合に Foreach-Object の Parallel パラメーターをよく使うのですが、こちらは PowerShell7.0 以降で利用可能となります。
また、 Azure を触っている方にはお馴染みの Az PowerShell モジュールも、バージョンによって使えるコマンドやコマンドの使い方が変わってくるので注意が必要です。

まだ他にもありそうですが、主に上記のような問題を解消するために実行基盤をオンプレミスからクラウドへ移行することを決めました。
弥生で使用しているクラウドサービスは AWS がマジョリティとなりつつありますが、連携面での高い親和性や権限管理のしやすさを考慮して Azure を採用しました。

採用した Azure サービス

実際に採用したクラウド基盤での自動化を助けてくれる心強い Azure サービスたちをご紹介します。

Azure Automation の Runbook

learn.microsoft.com

Azure Automation は、タスクをクラウド環境で自動化するための様々な機能を提供するオートメーションサービスです。

learn.microsoft.com

中でも一番使っているのは Runbook と呼ばれるスクリプト化された処理を自動実行する機能です。
任意のランタイムバージョンを選択して、 PowerShell や Python などでスクリプトを記述することができます。
また、PowerShell の場合、 Az PowerShell をはじめとする代表的なモジュールは既定で用意されています。
実行方法も幅広く用意されており、スケジュール実行やアクショングループからの実行、 Webhook を用いた外部からの実行も可能です。
さらに、Automation アカウント上で認証情報や変数を管理する機能があるため、重要な情報はコードと切り離すことでセキュリティを担保できます。
元のコードをコピペするだけ!とはいきませんでしたが、ほとんどのスクリプトを容易に移行することができました。

Azure Data Factory

learn.microsoft.com

Azure Data Factory は、Azure SQL Database、Azure Storage など様々なデータソースを取り扱う ETL サービスです。
移行対象のタスクには DB に対して SQL クエリを実行するものがあり、 Runbook への移植が少々面倒かつ処理が複雑化するものはこちらへ移行しました。
ノーコードで簡単に処理を作成できることに加え、Azure Key Vault を組み合わせることで接続情報や認証情報をセキュアに管理することができます。
また、パイプラインと呼ばれる処理単位は Runbook と同様にスケジュールやトリガー実行することも可能です。

Azure Logic Apps

learn.microsoft.com

Azure Logic Apps もノーコードでワークフローを作成して自動実行することができるサービスです。 こちらは、ビジネスプロセスを自動化できる RPA ツールとして Microsoft が提供する Power Automate と似ています。
構築済みの操作ブロックを GUI 上で自由に組み合わせることで思い思いのワークフローを作成することができます。
強みの一つとして、既述の Runbook や Data Factory のパイプラインを同一ワークフロー内で呼び出すことができ、「タスク A が成功したらタスク B を実行」といった順序関係があるタスクを簡単に実現することができました。
余談ですが、最近 GUI 周りが大きく改善されてかなり使いやすくなりました…!

結果

オンプレミスで抱えていた問題を概ね解消することができました。

①各タスクの実行結果を簡単に監視できる

今回採用したサービスはいずれも実行結果を Azure Monitor で監視することができます。
アラートを関係メンバーに対してメール通知するように構成しており、失敗をいち早く検知できるようになりました。

②クラウド基盤なので停止の心配がない

Microsoft が公開している SLA に基づいて、オンプレミスよりも高い可用性が保証されています。
万が一障害が発生したとしても、サービス正常性アラートで検知できるようにしています。

③実行環境の管理が楽

スクリプトの大半を移行した Runbook では、ランタイムバージョン以外の項目は意識する必要はありませんでした。
ランタイムバージョンもスクリプト作成時に選択するだけなので、ユーザー側で管理する必要はありません。
また、モジュールのバージョンも Azure Portal 上で管理することができ、更新も数クリックで完了します。
Azure Data Factory や Azure Logic Apps に至ってはそういった概念すらありません。

終わりに

今回は、自動化基盤をオンプレミスから Azure へ移行したお話をご紹介しました。
Azure の他サービスや AWS を含め、自動化や効率化を助けるサービスは数多く存在するため、色々試しながら継続的な改善を図っていきたいと思います。
もちろん、要件によってはオンプレミスを使わざるを得ないケースもあると思いますが、そうでないものはクラウドサービスへの移行を考えてみてはいかがでしょうか?


弥生では、一緒に働く仲間を募集しています。
herp.careers

ブラウザ自動化ライブラリPlaywrightの紹介とRailsでの利用可能性

この記事は弥生 Advent Calendar 2024 (シリーズ1) の11日目の記事です。

はじめに

はじめまして、弥生株式会社のMisocaチームエンジニアの粟津です。

今回は比較的新しいブラウザ自動化フレームワークであるPlaywrightについて、その利点とMisocaでの利用可能性を検討した結果を書こうと思います。

Misocaについて

Misocaは簡単に利用できる請求書発行サービスです。請求書だけでなく、納品書や見積書、領収書の発行もできます。
インボイス制度や、弥生株式会社のサービスであるスマート証憑管理と連携した電子帳簿保存法対応もしております。
ぜひ使ってみてください。

www.yayoi-kk.co.jp

Misocaとブラウザ自動化

MisocaはRuby on RailsとVue.jsを利用して開発していますが、その中で多くの種類の自動テストを実行しています。
それらの自動テストの中で、特にe2eテストとビジュアルリグレッションテストはブラウザ自動化を利用しています。
ビジュアルリグレッションテストとは、過去の状態の画面のスクリーンショットとの差分を比較して差分を検知するテストです。

zenn.dev

ちなみにe2eテストとビジュアルリグレッションテストの両方とも、テストフレームワークであるRSpecとRubyのブラウザ自動化ライブラリであるCapybara(driverはselenium)を利用しています。
(Railsユーザーにはお馴染みの構成です。)

RSpec: Behaviour Driven Development for Ruby

GitHub - teamcapybara/capybara: Acceptance test framework for web applications


また、ビジュアルリグレッションテストではスクリーンショットの取得までをRSpec/Capybaraで行い、
差分検知と結果画面の出力にはreg-suitを利用しています。

reg-viz.github.io

ブラウザ自動化のつらさ

ユーザーの操作をシミュレートできるブラウザ自動化はとても便利で、ソフトウェアの品質を担保してくれます。
しかしそのメリットの反面、開発生産性の低下につながるデメリットもあります。

それは次の2つの点です。

  • テストが多くなると負荷がかかったり、実行時間がかかる
  • flaky(不安定)なテストが不定期で失敗し、再実行をする必要がある

Misocaでは主にリリース前やプルリクエストのマージ時に各種テストがCI上で実行されますが、上記のような理由で時間がかかると
開発生産性が低下し、結果としてユーザーへの価値の提供が遅くなってしまいます。

開発を進めるごとにテストケースが増えて実行時間が長くなることは一定仕方のないことではありますが、それでもなんとかしたいという課題意識がありました。

Playwrightとは?

そこで目をつけたのがPlaywrightです。
PlaywrightはMicrosoft製のテストやスクレイピングのためのブラウザ自動化ライブラリです。

playwright.dev

公式ドキュメントを参考にとても簡単に試すことができます。
(自分はインストール含めて5分くらいでテストが実行できました!)

Installation | Playwright

Playwrightの特徴とSeleniumとの違い

ブラウザ自動化といえばSelenium、という人も多いのではないでしょうか。
先述のようにMisocaでもCapybaraのdriverとしてSeleniumを利用しています。

PlaywrightとSeleniumにはどのような違いがあるのでしょうか。
Playwrightの特徴をいくつか抜粋しながら紹介します。

複数ブラウザサポート

Playwrightはデフォルトで、主要ブラウザであるChromium/WebKit/Firefoxをサポートしています。
Seleniumでも上記ブラウザへ対応はしていますが、それぞれのブラウザごとに設定をする必要があります。

対して、Playwrightではデフォルトの状態で各ブラウザ全てに対するテストが実行できます。
公式ドキュメントのチュートリアルでも何もせずに全てのブラウザでのテストが実行されます。ぜひ試してみて下さい。

また、エミュレーションによるモバイルブラウザのサポートもされているようです。

flakyなテスト対策

ブラウザ自動化の辛い点としてあげた、flakyなテストですが、Playwrightではこちらの点も対応しています。
例えば、Javascriptが利用されたアプリケーションのテストをする際、特定の要素が出現するまでに時間がかかってテストが失敗することがあります。
このような場合、これまでは明示的に待ち時間を設定することで要素の表示を待つ方法を取ることが一般的です。

対して、Playwrightでは明示的な待ち時間を設定する必要がなく、自動的に要素の変更を待つことができます。
また、flakyなテストの再実行に関する機能もしっかりと用意されているので、特定のテストが落ちてしまったら全てのプロセスを再実行、といった無駄を省けます。
このような機能がデフォルトでサポートされているのが嬉しいですね。

playwright.dev

Playwrightの結果出力

個人的に一番魅力的だった点はこちらの機能です。
Playwrightではデフォルトで結果の出力ができます。
このようにブラウザごとの結果から、各テストケースごとの操作手順、どこで失敗したのかが非常に分かりやすく確認することができます。

playwright.dev

これまでのブラウザ自動化ではテストが失敗した際に原因を探すことも大変でしたが、Playwrightでは何か起きた時でデバッグしやすいことは大きなメリットです。

そもそもRailsに使えるの?

ここまでPlaywrightについて調べてみましたが、そもそもRailsに使えるのでしょうか?
答えは「YES」です。

実は、Misocaでも利用するCapybaraのdriverとしてPlaywrightを指定することができます。

playwright-ruby-client.vercel.app

driverを切り替えるだけなので、個別のテストケースの書き換えは必要ありません。

Misocaでも先行して、ビジュアルリグレッションテストのdriverを切り替えてみました。
しかし、Capybaraを少しカスタマイズして利用している箇所で調整を行う必要があり、残念ながらまだ移行はできていません。
(また移行が完了した際にはテックブログを書きます…!)

今後の展望

これまで紹介したように、Playwrightには大きな可能性を感じています。
より気軽かつ高速にe2eテストやビジュアルリグレッションテストが実行できるようになることで、開発生産性を維持しながらユーザーへの確かな価値提供を早めることができます。

また、今回紹介した機能以外にも、画面収録ができたり、実際のブラウザを操作しながらテストケースを書き起こしたりもできます。
Playwrightを使いこなして、弥生の品質保証とその生産性とさらに向上していきたいです。

社員募集

弥生では一緒に働く仲間を募集しています!

弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers

Microsoft Developer Dayに参加しました(おまけ編)

この記事は弥生 Advent Calendar 2024 (シリーズ1) の10日目の記事です。

こんにちは、弥生でエンジニアをしています、shiba_tです。 好きな勘定科目は「その他の預金」です。「現金」や「普通預金」などと比べると使われる機会が少なく、ひっそりと存在している感じが好きです。

11/6(水)、大手町で開催されたMicrosoft Developer Dayに参加してきました。 イベントについてはAdvent Calendar 4~6日目の記事で触れていますので、本記事では取りこぼした話題を中心に、番外編的に紹介します。

Platform Engineering のための5つの観点

近年注目を集めているPlatform Engineeingについて、実現しようとしていることはなにか、そのために必要なことはなにかを知ることができました。

Platform Engineeingとは、登壇者様のZenn記事(Platform Engineering について諸々)をお借りすると、以下の内容となります。

組織内にあるさまざまな技術やツールをすべて設計し繋ぎ合わせ、開発者のセルフサービスを可能にし、認知負荷を軽減するゴールデンパスとする技術です。 運用チームに目を向けると、反復的な作業 (トイル) を行う負担が軽減されます。 プラットフォームエンジニアは、社内の開発者用プラットフォームを構築・設計し、ユーザーを支援し、サービスを提供するのです。

以下の5つのポイントが必要であることがわかりました。

  • Alignment:コンウェイの法則にとらわれず、アーキテクチャをベースに最適のチーム構成を設計すること
  • Building the Blocks:開発者が効率的に働ける仕組み(開発ツールやCI/CD、生成AIやセキュリティ等含めた)を作ること
  • Culture:開発者ファーストのカルチャーを作ること(開発者ファースト、エンドユーザーが見るプロダクトと開発者が見るプラットフォームが同じであること、etc...)
  • Delivery:要求からリリースまでのデリバリーの環境整備
  • Experience for User:開発者の体験「Devloper Experience(DevEx)」を重視すること

特に最後の「Devloper Experience(DevEx)」は印象的でした。 開発者がストレスなく、かつセキュリティ等のリスクを抑えて効率的かつ安全にデリバリーする環境を作ることの重要性を再認識しました。

【実践】GitHub Copilot Enterpriseで実現するこれからの開発体験 by オルターブース

GitHub Copilot Enterpriseの活用について、30分で学べるワークショップにも参加しました。 Copilotを活用して開発効率を高める実践的な方法を体験しました。

業務で使っているメンバーは弥生社内でもいますが、私は今まで触れた経験はありませんでした。

リポジトリからソースコードをcloneして、Copilotを使いながらコードの修正や機能追加を実践しました。

用途に応じてモデルを使い分ける方法や、レコメンドの受け入れ方法などを学ぶことができました。

社内でもCopilotが利用可能になったので、私もワークショップで習得した知識を試しているところです。

(おまけ)参加品等の紹介

  • ラムネ

ラムネ(イベント限定)

参加者にはラムネが配られました。パッケージが#MSDevDay限定のものです。 ブドウ糖を摂取して、集中力を高めて開発してほしいというメッセージですかね、多分。

  • クリアファイル

参加者アンケートに回答すると、クリアファイルがもらえました。 Azure Portalに慣れている方には親しみやすいデザインでした。

まとめ

Microsoft Developer Dayは、技術トレンドを吸収し、登壇者や企業ブースで直接交流できる貴重な場でした。生成AIやPlatform Engineeringといった最新の話題を学び、自分の開発プロセスにも活かせるヒントを得ることができました。

特に Platform Engineering の重要性や GitHub Copilot Enterprise を活用した効率化の具体的な方法など、今後の業務に直結する知見を得られました。

今後もこういったイベントに参加し、ぜひ製品に還元していきたいと思います!

社員募集

弥生では一緒に働く仲間を募集しています!

弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers

デジタル署名環境をクラウドに移行した話

この記事は弥生 Advent Calendar 2024 シリーズ1の9日目の記事です。

弥生の石橋です。開発本部でデスクトップ製品共通モジュールのエンジニアを担当しています。
Windowsアプリケーション開発者であれば避けては通れないデジタル署名。
先年、CA/ブラウザフォーラムにおけるコードサイニング基本要件の変更が行われ、弥生で利用しているDigiCertの証明書の要件が変更となりました。

[重要]コードサイニング証明書における要件変更について(2022年11月)

この影響を受け、デジタル署名環境を変更する必要があったのですが、弥生ではAzureを利用したデジタル署名環境を採用しました。
この記事では、採用までに至った経緯や、Azureの環境構築からアプリケーションの署名方法まで紹介します。

デジタル署名環境の要件変更

これまではDigiCertから入手した証明書をデジタル署名用マシンにインストールして、MicrosoftのSignToolを利用して署名を行っていました。
しかしながら、上記の要件変更に伴い、コードサイニング証明書の秘密鍵はFIPS140 Level2、 Common Criteria EAL 4+、または同等のセキュリティ要件を満たすハードウェアに格納されなければならないこととなり、一般的なマシンに直接に保管することはできなくなりました。
これに伴って、DigiCertへの証明書の申請の手順も変更になり、下記のいずれかの方法を選択して申請することとなりました。

  1. DigiCertが提供するハードウェアトークンを利用する
  2. 自分でハードウェアトークンを準備する
  3. HSM(Hardware Security Module)を利用する

弥生の対応

弥生では仮想環境でデジタル署名を付与しており、デジタル署名プロセスはCI/CDで自動化されています。
これに対し、1と2のハードウェアトークンを利用する方法は下記理由から採用が難しいものでした。

  • ハードウェアトークンが仮想環境で利用できないため、物理マシンを用意する必要がある
  • SignToolでデジタル署名を付与する際に都度パスワードの入力が必要である

そのため、3のHSMを利用する方法を検討しました。
しかし、物理的なHSMデバイスやクラウドHSMは非常に高価で、デジタル署名の秘密鍵だけを保管する用途としてはコストに見合っていませんでした。
そんな中、AzureのKey VaultというサービスがオプションとしてHSMを利用できるため、上述の要件を満たして証明書と秘密鍵を保管できることがわかりました。
また、AzureSignToolというツールを用いることでKey Vaultに保管された証明書を用いてWindowsアプリケーションに署名できることもわかりました。
Key Vaultは月額5USD+0.03USD/10,000トランザクション(弥生で利用している鍵長の場合)と安価に利用することができ、Azure自体は弥生で利用していて導入にハードルもなかったため、Key Vault+AzureSignToolでデジタル署名を行う事としました。

Azureの環境構築

1. キーコンテナーの作成

まずはキーコンテナーを作成します。
この際、価格レベルはプレミアムを選択します。
プレミアムとすることで、上述のハードウェア要件を満たす秘密鍵を作成できるようになります。

2. キーコンテナーのアクセス制御(IAM)の設定

キーコンテナーのアクセス制御(IAM)ロールの割り当ての追加からキーコンテナー管理者を自身のアカウントに設定します。
以降の操作のため必要となります。

3. 証明書の作成

証明書生成/インポートし、証明書を作成します。
ポリシーの詳細構成で下記を入力または選択します。

項目
証明機関 (CA) の種類 統合されていない CA によって発行された証明書
拡張キー使用法 (EKU) 1.3.6.1.5.5.7.3.3
X.509 キーの使用フラグ デジタル署名
エクスポート可能な秘密キーですか? いいえ
キーの種類 RSA-HSM

他の項目はプロジェクトに応じて設定してください。

証明書が作成出来たら、作成された証明書を開き、証明書の操作CSRのダウンロードをクリックすることでCSRがダウンロードできます。

4. 証明書のマージ

先の手順でダウンロードしたCSRをDigiCert等の認証局に送付すると、証明書を取得することができます。
Key Vaultで作成した証明書を選択し、署名された要求をマージをクリックして、認証局から取得した証明書をマージします。

5. アプリの登録

後述のAzureSignToolからこれまでの手順で登録した証明書を利用するために、Microsoft Entra IDからアプリを登録する必要があります。
まず、アプリの登録の新規登録から、新しいアプリを作成します。
作成したアプリの証明書とシークレットから、新しいクライアントシークレットを作成します。
作成したシークレットの値は画面を遷移するとコピーできなくなるため、作成後の画面で保存しておいてください。

6. アクセス権限の付与

手順5で作成したアプリにKey Vaultの証明書を利用するための権限を与えます。 作成したキーコンテナーのアクセス制御 (IAM)ロールの割り当ての追加より、下記の2つの職務ロールを作成したアプリに割り当てます。

  • Key Vault Certificate User
  • キー コンテナー暗号化ユーザー

7. 認証情報の取得

手順5で取得したシークレットの他に、AzureSignToolで下記の情報が必要となるので取得します。

  • 手順1で作成したキーコンテナー
    • コンテナーのURI
  • 手順3で作成した証明書
    • 証明書の名前
  • 手順5で作成したアプリ
    • アプリケーション (クライアント) ID
    • ディレクトリ (テナント) ID

これでAzureの環境構築は完了です!
必要に応じてキーコンテナーのネットワークの設定からファイアウォールの設定を行ってください。

デジタル署名

AzureSignToolのインストール

.NETがインストールされている環境であれば、dotnetコマンドでインストールすることができます。

dotnet tool install --global AzureSignTool

.NETがインストールされていない場合、.NETをインストールして上記コマンドを実行するか、GitHubのReleaseからアセットを取得してください。
Releaseに公開されているアセットは.NETのインストールなく利用することができます。

AzureSignToolによる署名

先述の手順で取得した情報を利用して、下記コマンドを実行することでデジタル署名を付与することができます。

AzureSignTool sign ^
    -kvt <テナントID> ^
    -kvu <コンテナーのURI> ^
    -kvi <アプリケーションID> ^
    -kvs <シークレット> ^
    -kvc <証明書の名前> ^
    -t <タイムスタンプサーバーのURL(例:http://timestamp.digicert.com)> ^
    -v <署名対象のファイルパス>

最後のファイルパスは複数指定することも可能です。
複数のファイルをまとめてAzureSignToolに渡すと、1回の証明書へのアクセスで複数のファイルへのデジタル署名ができ、高速かつ低コストなのでおススメです。
ファイルパスが長くなる場合はテキストファイルでファイルパスのリストを作成しておき、-iflオプションで指定することもできます。

AzureSignTool sign ^
    -kvt <テナントID> ^
    -kvu <コンテナーのURI> ^
    -kvi <アプリケーションID> ^
    -kvs <シークレット> ^
    -kvc <証明書の名前> ^
    -t <タイムスタンプサーバーのURL(例:http://timestamp.digicert.com)> ^
    -ifl <署名対象のファイルリストが記載されたテキストファイルのパス>

おわりに

今回の記事では、Azure Key VaultとAzureSignToolを用いたデジタル署名環境の構築方法について紹介しました。
秘密鍵の保管要件が厳しくなったことで、秘密鍵が漏洩してデジタル署名のなりすましが発生するというリスクも低減されるので、今回の要件変更で対応できてよかったと思っています。

本記事が、デジタル署名環境の構築に役立つ情報となれば幸いです。
弥生 Advent Calendar 2024では、今後も様々な技術情報を発信していきますので、ぜひご期待ください。



弥生では一緒に働く仲間を募集しています。
開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。
herp.careers

第23回Quesをチーム弥生で視聴しました

この記事は弥生 Advent Calendar 2024の8日目の記事です。

クリスマスまであと何日?
こんにちは、かとあず(@kato_az)です。弥生でQAエンジニアをしています。
好きな勘定科目は未払金です。

11月8日に第23回Quesが開催されました。

Quesとは

Quesとは、Software品質保証に関わるQAエンジニアの活性化を目的としたQA専門のイベントです。
Software品質保証に関わるQAエンジニアの方が、会社間の垣根を越えて、情報交換や交流を深めてもらうことで、日本のSoftware品質保証を盛り上げていく場にしたいと思います。

ques.connpass.com

第23回Quesイベント概要

日時:2024年11月8日(金)19:00~21:00
開催方法:現地、オンラインのハイブリッド開催

今回のテーマは「QAチームの在り方」。
QAの必要性が広く認知されてきた中、QAチームを持つ企業・プロジェクトも増えてきたように思います。
自分たちにあったQAチームの在り方を模索されている方も多くいらっしゃるのではないかと考え、取り組みの工夫をご紹介することで、QAチーム活性化の一助となればと思い、今回のテーマとしました。

ques.connpass.com
5月に開催した第22回Quesを弥生株式会社本社で開催したご縁で、弥生は第23回Quesに協賛に名前を連ねました。

「チーム弥生で視聴」とは

Quesのイベントは、現地参加とオンライン参加から選択することができます。
現地に行って、現地ならではの雰囲気を感じること、登壇者や他の参加者と交流することはすてきな参加方法です。
オンラインで、家事をしながらや家族と過ごしながら参加したり、または、ひとりでじっくりとメモをとったり不明点を調べながら参加することもすてきな参加方法です。

私たちは第3の選択肢として弥生株式会社本社で集まって視聴する「サテライト会場」参加をすることにしました。
「サテライト会場」参加ははじめての取り組みです。いろいろなやり方があるかと思いますが、今回はスモールスタートにしました。

  • 弥生株式会社に所属するメンバーであること
    • 今後の勉強会では弥生株式会社に所属しているメンバー以外にもサテライト会場を解放して参加できるようにするかもしれませんが、今回は関係者限定としました。
  • イベント当日に本社に出社できること
    • オンラインの勉強会を視聴しながら、別のオンライン会場とつないで会話をするのは難しそうだったので、今回は開催時間に本社に来られる人限定としました。
  • 第23回Quesにオンライン参加で申し込みすること
    • 1人の申し込みで複数人が参加することは想定されていないと思います。無料の勉強会であってもルールは守ろうと考え、サテライト会場で視聴するメンバーも全員オンライン参加として参加申し込みをしました。

サテライト会場実施のきっかけ

2023年3月開催のJaSST'23 Tokyoに複数メンバーで参加し、アフタートークをしました。
アフタートークの際、「同じセッションに参加してもロールや担当しているプロジェクトによって感想が違うこと」や、「話すことで自分の理解度合を確認できること」を知りました。
tech-blog.yayoi-kk.co.jp

2024年5月開催の第22回Quesは、弥生本社が会場だったこともあり広く弥生社員に参加を呼びかけました。
Quesに現地参加したエンジニアが参加ブログを作成し、「チームのQAエンジニアと話してみたら想像以上に収穫があった」という感想を持ったことを知りました。
tech-blog.yayoi-kk.co.jp

これらの経験から、アフタートークでできる学びを、勉強会と同時並行にできないか?と考えました。

もちろん、会場で口頭質問したり、用意されていた質問投稿ツールに書き込んだりすることで、学びを深めることができます。
それでも、質問をするのに説明しなければならない業務の前提となる条件やプロジェクトの状況を伝えられずにうまく質問ができなかったり、QAエンジニア以外のロールの人にとってはQAエンジニア向けの勉強会で使われている用語がわからなかったりするかもしれません。
弥生社員で集まって勉強会に参加しながら話すことでこれらの問題点をクリアできるかもしれないと考えました。

当日の雰囲気

現地では勉強会パートと懇親会パートが分かれていましたが、サテライト会場は勉強しながら懇親をすることにしました。
声かけをして参加メンバーを募った私は、主催者として事前に場所だけは確保していました。
当日の午後に「会場の準備をしなきゃいけないな」と思いながら業務をしていたのですが、私が気づいたときには業務をはやめに終えたメンバーがモニターをいい感じの場所に設置し、机と椅子を配置し終えていました。すごい。

そして、開始時間の19時少し前から食事や飲み物を準備しました。
食べたいものを食べたいだけ持ってきたら、ボリューム多めでした。

動画視聴と懇親には欠かせないお食事。お菓子、ミニバーガー、たこ焼き、ピザ!
ブログ掲載用の食べ物の写真を撮ったら、あとは自由に座って、飲食しながら勉強会の開始を待ちます。
※画像はイメージです。
発表開始後は、「すごーい!」「わかるー!」といった感想を口に出し、「あの単語どういう意味?」というような疑問をその場でみんなで解消し、お話しを聞きながらも「弥生でチャレンジするにはどうしたらよい?」といった本編から派生したディスカッションをしました。
もぐもぐ、わいわいしつつ、真剣に聴く場面もあります。

感想

サテライト会場をつくってわいわい勉強会に参加することは、じっくりと聴きたい人にとっては不向きかもしれません。
それでも、ひとりで勉強会にオンライン参加参加していると「見ただけ」で終わってしまうことがあるかもしれないという点や、自分が専門としているロール以外の勉強会に参加するのは難しいという点は解消できそうです。
使われている単語がわからないと内容の理解が追い付きません。
会場で「どういう意味ですか?」と声をあげることはハードルが高いことです。質問できたとしても一般的な回答になってしまいます。
「弥生ではこういう言い方をしている」「弥生ではこういう場面で使っている」といった会話ができるのは、非常に有意義な時間になると感じました。
「"ちーとぽ"(チームトポロジー)、はじめて聞いたとき"ちいかわ"の仲間かと思ったわ」レベルの話をするのは、少人数でクローズドな方がやりやすかったです。

弥生はフルリモートワークを取り入れており、全国各地のメンバーが活躍しています。オフィスでも自宅でも働ける環境が整っています。
チーム全員がオフィスに出社をして直接話す機会は年に数回と限られていますし、Zoomを使ったオンラインでの雑談は非常に難しいことです。
サテライト会場を使った勉強会開催は、業務と絡めた雑談ができる場になりました。チーム弥生の連携を強め、お客さまに価値提供するためのヒントが得られ、これからあたらしい学習に取り組むきっかけになりそうです。


弥生では、一緒に働く仲間を募集しています。 herp.careers