Japan株式会社様が主催のウェブセミナーです。「お客様事例セッション!」Webinarシリーズでは、Zuoraを導入し顕著な成功を収めた顧客の実践事例を通じて、Zuoraがいかにビジネスの成長を促進し、ゴール達成をサポートし、現場業務を革新的に効率化しているのかをご紹介します。リアルな成功体験を余すところなくお伝えし、業界の先駆者たちが実践する戦略とソリューションを深く理解いただくことで、貴社の次なる成功に向けた貴重な知見とインスピレーションを得る絶好の機会を提供します。記念すべき第一回目では、弥生株式会社の成功事例を特集します。弥生株式会社は2016年にZuoraを導入し、今年で運用9年目を迎えました。初期導入から段階的にシステムを拡張し、現在ではほぼ全商材をZuoraで一元管理しています。ここに至るまでの道のりや、直面した課題への対応方法、そして実際の成果について、Zuora導入に携わってきた山川和也様からの貴重な体験談をお聞きいただける対談セッションです。参加申し込み以下のリンクのウェビナー参加申し込みフォームからお申し込みください。山川さんってどんな人?山川さんを取り上げている記事をぜひご覧ください。www.wantedly.com弥生では一緒に働く仲間を募集しています。開発生産性を追求しているチームにご興味のある方、ぜひエントリーお待ちしております。Studioの仮想マシンの容量を変更する方法AWSTL;DRこんにちは。弥生R&D室のsiidaです。Studioというサービスがあり、Web上のUIを通してMLのための環境を構築することができます。Studioで建てる仮想マシンのデフォルトの容量は100GBが上限なのですが、昨今のLLMはモデルだけでも100GBを超えることが多く、不足気味です。そこで、容量の上限を引き上げる方法をまとめたいと思います。ECSのCPUアーキテクチャをArmに変更してコスト削減AWSこんにちは、インフラ/Misocaチームのfuku710です。MisocaチームではAWSのコスト削減の一環として、ECS上で動いているコンテナアプリケーションのCPUアーキテクチャをArmプロセッサに変更する取り組みを行いました。その過程でやってきたことや工夫したことなどについて書きたいと思います。Fargateを使用しています。Graviton2がサポートされており、x86ベースのFargateからGraviton2ベースのFargateに変更することにより約20%のコスト削減が見込めます。0.00442USDaws.amazon.comまた、パフォーマンスとしてもx86と比べて最大19%高くなると記述されています。aws.amazon.comECSをArm対応するまでの流れECSにおいてx86で動いているコンテナをArmで動かすためには以下の二つの作業が必要となります。Armアーキテクチャに対応したコンテナイメージを作成するECSのタスク定義ファイルでCPUアーキテクチャにArmを指定するここで肝となるのはコンテナイメージの作成です。Dockerでは1つのイメージで複数のアーキテクチャに対応したマルチプラットフォームイメージを作成できます。マルチプラットフォームイメージとしてイメージを作ることにより、コンテナが動作するプラットフォームに応じて自動で適切なイメージが選択されて実行できます。これにより、ECSのタスク定義でCPUアーキテクチャを指定するだけでArm環境に移行できます。マルチプラットフォームイメージを作成するための方法はいくつかありますが、1つはQEMUを使ったビルドです。QEMUはプロセッサエミュレータであり、これを利用してビルドすることによりx86のマシン上でx86のイメージとArmのイメージ両方を作成することができます。この方法のメリットとしてアーキテクチャごとにマシンを用意する必要がないため、既存のCI/CDの変更を少なくしてイメージの作成が行えます。デメリットとしてQEMUはエミュレータであるためイメージによっては非常に時間がかかる可能性があります。installで非常に時間がかかり、数分で終わっていたビルドが30分近くかかるようになってしまいました。これでは運用上もコスト上もよろしくないため、アーキテクチャ別の環境を用意してそれぞれの環境でビルドしてマルチプラットフォームイメージを作成するという方針に切り替えました。Actionsの2つのサービス上でコンテナイメージをビルドをしていたため、それぞれのサービスで対応した内容を紹介します。CodePipelineのフロー上でCodeBuildによるビルド/デプロイを行っています。CodeBuildでは動作するビルド環境のイメージを選択できるため、x86環境のCodeBuildとArm環境のCodeBuildを作成しCodePipelineのビルドステージで2つのCodeBuildを並列に動かすようにします。ポイントは各環境のビルド後にマルチプラットフォームイメージをプッシュするステージを用意している点です。ここで各プラットフォームのイメージへの参照しているマルチプラットフォームイメージを作成してプッシュする処理を行います。マルチプラットフォームイメージを作成するCodePipelineの構成AWSの構成管理にTerraformを使用しているため、Terraformでの記述を示します。CodeBuildでArm環境を利用する場合はenvironmentのtypeをARM_CONTAINERにしたうえでimageで利用可能なイメージを指定します。CodeBuildCodePipelineでは各環境でビルドした際のイメージ名をマルチプラットフォームイメージをプッシュするCodeBuildに渡すようにします。-mの出力をイメージタグにすることで、アーキテクチャごとに別のタグでECRにプッシュします。buildxを使ってマルチプラットフォームイメージを作成します。createコマンドで引数に各プラットフォームのイメージ名、--tagオプションに新しく作成するイメージ名を指定することでマルチプラットフォームイメージがプッシュされます。Actionsではアプリケーションの共通となるイメージなどを定期的に作成しています。こちらもCodeBuild同様にアーキテクチャの環境別にビルドをしてマルチプラットフォームイメージを作成したいところです。実はこれまでGitHubがホストするランナーでArmアーキテクチャに対応しているものはなく、Arm環境上でワークフローを動かしたい場合はセルフホステッドランナーを使い自前でランナーを用意する必要がありました。6月の初めからGitHubがホストするランナーとしてArmランナーが提供されるようになり、より手軽にArm環境上でビルドするワークフローを構築できるようになりました。Cloudプランである必要があります。通常のランナーと異なり事前にOrganizationの設定から新しくGitHubホステッドランナーとして追加する必要があります。Teamであれば3000分/月)を使用することができないため、独立して課金されることには注意してください。Organizationにランナーの追加が完了したら、ワークフローファイルのruns-onプロパティにランナーのラベルを指定することで該当のランナーを使用することができます。Actionsではmatrixを使用することによりジョブを並列に動作することができます。Dockerのドキュメントには複数のランナーでビルドするワークフローファイルの例がありますが、そこから以下のようにstrategyとrun-onを変更してランナーを分けるようにすればx86とArmのランナーそれぞれでビルドすることができます。}}ECSの対応Arm対応のイメージがビルドできる環境が整ったら、ECSのFargateでGraviton2を利用できるようにします。Gravion上で動作します。Explorerのグラフを見るとArmに切り替えてから期待通りに時間あたりのコストが下がっていることが確認できます。レスポンスタイムの改善もみられました。以下のグラフでは実線がArmに切り替えた後のレスポンスタイム、点線がその前の週のレスポンスタイムです。パフォーマンスの改善はそこまで期待していなかったのでうれしい誤算です。今回のArm対応により月1回動くバッチ処理の時間が長くなったり、CIの動作が不安定になるといった問題も発生しました。バッチ処理に関してはx86でのイメージのビルドも残してx86とArmを併用して運用するという方法で解決することにしました。本来であればArm環境移行後にx86のビルド処理を削除してコストを抑えるつもりだったので残念ですが、マルチプラットフォームイメージとしてイメージを作ったことにより、このような対応が容易にできたのは良かったです。まとめECSで動いているコンテナをFargateのGraviton2で動かせるように対応した結果、期待以上にコストの削減とパフォーマンスの改善を達成することができました。特定の処理でのパフォーマンス悪化やCIでの問題が発生することがあったので、そういったリスクにも注意しながらArm環境への移行を進めたほうがいいでしょう。弥生では一緒に働く仲間を募集しています。エントリーお待ちしております。弥生は第23回Quesに協賛します。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。