はじめに
こんにちは、AWAで一ヶ月インターン生をやっていた髙田敦生です
北陸先端科学技術大学院大学の修士2年でモバイルコアの研究を行っています
インターン先のチーム
私は音楽サービスであるAWAのバックエンドエンジニアとして配属されました。
マイクロサービスの考え方を取り入れたアーキテクチャ設計
音楽サービスでは様々な要素が組み合わさりユーザーに機能を提供します。たとえばどのユーザーがどんな曲を再生したかを1再生ごとに記録する基盤であったり、ラウンジ機能と呼ばれるアーティストとリアルタイムで音楽を楽しむための基盤が存在しています。またAWAではDevOpsの考え方を取り入れたシンプルなインフラ構成であり、Terraformを使用したIaC設計です。ECSのタスク定義をterraformで管理を行い、CI/CDをGitHub Actionsで行っています。これらは複雑になるマイクロサービスのデプロイ環境をファイル一つ一つずつがサービスとして機能するマイクロサービスの考えの元に設計されています。
以上の事から多くの機能を提供するためにAWAではサービスの細分化を行いマイクロサービスアーキテクチャの考え方を取り入れた機能設計をAWS ECSなどを使用して実現しています。しかしながらAWSのようなパブリッククラウドをフルに活用した設計は料金に関するコストが大変重く悩みの種の一つです。
そこでAWAではECSサービスで動作しているCPUアーキテクチャをx86からARMに変更してコストを削減しています。また他の基盤ではECSサービス内の1タスクの処理能力が下がる事なく、置き換えることで料金コストが20%も下がる事が分かっているコストカットを行う面では大変有用です
ターゲットとしている基盤
今回のインターンでは上記の例に上げている音楽を再生した際に発生するログを管理するための基盤をターゲットにします。
従来x86として動作しているECSのタスクをマルチプラットフォームに対応させる必要があります。CPUアーキテクチャを変更するために以下のような手順が必要です
- コンテナイメージを複数のCPUアーキテクチャに対応させる
- Terraformで動作しているタスク定義部分を変更する
x86/ARMの両方で動作するようマルチプラットフォーム対応させる
ログ基盤で使用されているアプリケーションの言語はGoで実装されており、アプリケーション同士がそれぞれ音楽再生に関するログを複数台起動させて収集しています。これらのアプリケーションは既存の状態ではx86でしかランタイムが動作しない設計となっているためマルチプラットフォームに対応する必要性があります。Goではコンパイル時にターゲットとしているアーキテクチャを定義することで、マルチプラットフォームでも動作が可能になります。
特にGoアプリケーションのマルチプラットフォーム対応性は、後方互換性において大きな強みとなっています。単一のソースコードから異なるOS向けにクロスコンパイルできるGoの特性を活かし、コンテナイメージを変更することなく、様々な実行環境に対応することが可能です。これにより、後方互換性を維持しながら、ひっそりとプラットフォームの移行や更新を行うことができます。
この仕組みを利用してECS上で展開されているコンテナイメージを変更するためにDockerfileを変更します。
変更の承認が行われるとCI/CDの仕組みとして、GitHubAcitonsが動作します。Actionsのフローではデプロイまでの動作を全て自動化しており、動いているアプリケーションの動作を止めることなく既存のCPUアーキテクチャを変更する事が可能になります。
Terraformで動作しているタスク定義部分を変更する
Terraformはhasicorp社が開発したInfrastructure as Codeを実現出来るIaCツールです。IaCはマイクロサービスアーキテクチャの考えに準ずるタスクがどういった動作するのか。といった状態を定義する事が簡易的なため近年で注目されています。
AWAではAWS ECSのタスク定義をTerraformで運用しており、Goで開発されたアプリケーションを効率的にデプロイします。
24時間稼働しているサービスでは、このマルチプラットフォーム対応と後方互換性の維持が不可欠です。バイナリは変更せず、Terraformによるインフラ定義のみを更新することで、ユーザーに一切の影響を与えずに移行を完了する事が可能になるのです。
具体的な実装方法としては、Terraformによる抽象化とバージョン管理を活用しています。Terraformコードを使って環境固有の設定を適用できるようにしています。これにより、開発環境での十分なテスト後に、本番環境へ安全に変更を適用できます。
さて、これで全て完了したので実際に変更された箇所を確認します
結果として
AWS ECSの詳細ではアーキテクチャがARM64に変更されているのが確認出来ました。
このDataDogのログではECSのタスクが途中で切り替わっています。このようにCPUアーキテクチャの変更を行っても無事動作する事が確認でき、サービス自体が止まる事なく動作出来ているのが確認出来ました
インターンでの学び
インターン期間中、24時間稼働する音楽サービスの裏側に触れる貴重な経験ができました。実際に運用されているアーキテクチャは非常に緻密に設計されており、インフラからアプリケーションまで、安定性と効率性が追求されていることが理解できました。
ドキュメントやソースコードを調査する機会も多く、普段とは異なる視点でエンジニアリングについて学ぶことができました。特に印象的だったのは、ユーザーファーストの姿勢と安定性を両立させるための設計思想です。例えば、システム更新時でもサービス中断を最小限に抑える仕組みなどは現場でしか味わえないと思いました。
また、管理ツールの開発にも携わり、プロダクション環境の運用改善する経験も積めました。
まとめ
このインターンシップを通じて、実際の商用で使用されているマイクロサービスアーキテクチャの考えがどう生きているのか、24時間365日稼働するサービスの内部構造という、通常では経験できない貴重な知見を得ることができました。
また、開発チームの日々のコミュニケーション方法を間近で見ることができたのも大きな収穫でした。技術的な議論だけでなく、ビジネス目標やユーザーニーズを踏まえた戦略が、高品質なサービス提供につながっていることを実感しました。
この経験は技術スキルの向上にとどまらず、プロダクト開発の全体像を把握する視点を養う貴重な機会となりました。
チームの皆様、ランチに一緒に行ってくださった方々、特に私が何気ない質問でも答えてくださったバックエンドチームの方々には感謝し切れません。本当に一ヶ月間ありがとうございました。