この記事は BASE Advent Calendar 2023 の9日目の記事です
ごあいさつ
はじめましての人ははじめまして、こんにちは！BASE BANK Divisionのフロントエンドエンジニアのがっちゃん（ @gatchan0807 ）です。テックブログに出てくるのは半年ぶりぐらいですね。お久しぶりです
ちょっと大それた感じのタイトルを付けてしまいましたが、今回の記事では、先日 BASE BANK Divisionに社内公募という制度で異動して感じた BASE 組織との違いと、オンボーディングタスクでAWS ECSと格闘した記録をご紹介していこうと思います！
また、20日の記事では私も含む、実際に社内公募制度を使って異動したメンバーの体験談や感想などをまとめたものが公開される予定ですので、そちらもぜひご覧ください！
BASE組織とBASE BANK組織の違い
まずはBASE BANKの組織構造や使用技術を簡単に紹介し、その上で、いくつか自分が関わってきたBASE組織と比べて感じた違いについてお話します
ざっくりまとめると、BASE BANKの組織の特徴として主に以下のようなものが挙げられます👇
- フルサイクルエンジニアを目指すという志向がより強い
- 関わる技術領域がより広く、Go / Pythonを使ったAPIの開発を行いながら、BASE側のPHP製アプリケーションとの連携やフロントエンドの対応も行っている
- チーム全体の人数がまだ少ないので、より全体感を持ってプロダクトの成長方法を考えながら、さらに打ち手を増やしていくための取り組みを行っている
また技術的には、今後組織とプロダクトが大きくなってもスケールできるよう、以下のような仕組みで作られています
- 責務で分かれた複数のAPIを使った分散システム
- レイヤードアーキテクチャベースで整理されたバックエンドコード
- FE / BE間の連携を容易にするためにOpenAPIを使ったスキーマベースでのやり取り
これらの仕組みは、1人で複数領域を担当する場合にはBASE側のリポジトリも含めて複数のリポジトリを開いたエディタ反復横とびすることが必要になることもあります（このあたりは絶賛練習中…）
ここに関しては慣れが必要で大変なこともありますが、それでも依存関係やコードの責務が細かく分かれており、より見通しがしやすいという余りあるメリットがあります
より詳しい内容についてはSpeaker DeckにあるBASE BANKチーム紹介資料とBASEチームのエンジニア向け会社紹介資料を見比べていただくと、もっとイメージしていただきやすくなるかと思いますのでそちらもぜひご覧ください！
異動後初タスクでAWS周りでハマったポイント
ここからは、実際にBASE BANKチームに異動して1つ目のオンボーディングタスクで学んだこと、ハマったことについて書いていこうかと思います🕳🏃♂️💨
BANKチームに異動して新しい環境でコードを書き始めたところ、いくつかの問題に直面しました
これらの問題をどのように解決したか、ケーススタディとして共有していきます
オンボーディング時に開発用AWS環境を使用している場所があることに気づいた
自分の異動時には、昨日の @glassmonkey さんの記事（LocalStack/MinIO を導入して開発者体験が捗った話 - BASEプロダクトチームブログ）で紹介された minio / localstack 環境がすでに整っていました
しかしながら、一部のGo製アプリケーションはまだそれを利用していない部分がありました
これ自体は即座に問題が発生するものではありませんが、今後開発環境を新メンバーが構築するたびにAWSクレデンシャルを登録する必要があるため手間がかかってしまう状態になっていたため、オンボーディングタスクとしてDockerとアプリケーションの構成を修正してminio / localstackに対応することになりました
ローカル環境での動作確認は問題なかったが、動作検証用環境へのデプロイで問題が発生した…
BASE / BASE BANKには 「ローカル環境 / 動作検証用環境 / ステージング環境 / 本番環境」という4つのアプリケーション実行環境があり、今回はローカル環境での動作確認後、リリース前に動作検証用環境で問題なく動くことを確認しました
とはいえ、動作検証用環境 自体はステージング環境ほど頻繁には使われておらず、基本的に各エンジニアのPCから直接 ecspresso のコマンドを実行する形でのデプロイが行われており、CIを介したデプロイは行われていませんでした（ステージング環境 / 本番環境へのデプロイはCIを介して行われます）
しかし、エンジニア全体に支給されるPCが去年から少しずつARMアーキテクチャ（M1系 Macbook）に切り替わったことにより、ビルドをおこなう開発機とアプリケーション実行をするECSインスタンスのCPUアーキテクチャが異なってしまい、コンテナが起動しないという問題が発生するようになってしまいました（たまたま、このタイミングでこれに気づき、ハマってしまった形）
さらに、その問題の確認中に、ECS側で何度もリビジョンを作成しようとしてしまっている（絶対に起動できないコンテナを起こそうとし続けてしまう）ことに気づかず、そのリビジョン内で同時に使用しているサービス監視ツールのコンテナをDocker Hubから取得する部分でレートリミットがかかるという問題も併発させてしまいました…😵💫
ECSのリビジョン設定を変更して問題を解決
対応としては、BANKチームで使用しているECSのタスク定義の設定ファイル（ ecs-task-def.json ）でデプロイ先のCPUアーキテクチャ設定を変更したり、本番用構成では使用しているログ用コンテナやサービス監視用コンテナを一時的に外したりして、まずはアプリケーションがECS上で単独で動作することを目的としてフォーカスしました
その結果、アプリケーションの実装に問題はないことがわかったため、最終確認のためにステージング環境を使用し、最終的には問題なくBANKチームへの異動初のタスクを完了させることができました🎉
フルサイクルエンジニアへの第一歩が進みました
このような経験を異動直後からすることができたので、これは自分もフルサイクルエンジニアへの第一歩を踏み出せたんだな…と噛み締めながら作業していました
これまでのBASEチームでは主にフロントエンドの業務が中心であり、インフラ領域については仕様や実現したいことの相談メインで、実際の作業はSREチームにお願いするという形で進めることが多かったため、自分で手を動かせるようになったことは、とても学びがあり、非常に楽しかったです
とはいえ、まだまだ勉強中ですので重大な問題などが発生しないようにしながら頑張っていきたいなと思います
BASE BANKでは一緒にフルサイクルエンジニアリング目指して頑張っていく人も募集しています！
自分自身はBASE組織で2年半の間に身につけた知識を活用しながら、BASE BANKをさらに発展させていけるように頑張っていきたいと思います💪
とはいえ、BASE BANKを発展させていくためにはまだまだ人が足りていません…
先述の通り、BASE BANKチームにはスケーラブルな技術構成や組織構造の土壌があり、様々なプロダクトの改善を進めつつ、それらをより良くするための活動を行っているため、多くの学びがあってとっても面白いチームです
ぜひ、カジュアル面談などにお越しください！お話しましょう！
明日は10日目、 @x86_64 さんの記事です！お楽しみに！
