はじめに

こんにちは、2022年度新卒でレバレジーズ株式会社に入社した河原です。

現在私は、若年層領域の事業を展開する『ハタラクティブ』や『キャリアチケット』というサービスで、営業職が使用するSFA開発*1に携わっています。機能の多いSFAでの開発業務や業務・業界理解など難しいことが多いですが、営業職の社員が同じ職場にいて、日々私たちが開発したシステムを使って仕事しているところを見かけると、とてもやりがいを感じられます！

本記事では、先日行われたレバレジーズエンジニア組織テックフェスでのテックトークセッションの内容をご紹介します！また、私が従事しているSFA開発にどうすれば活かせるかを考え、クラウドコンテナサービスの調査・検証してみました。

テックフェス

テックフェスは、レバレジーズのエンジニア組織メンバー全員を対象としたテクノロジーの祭典です。弊社エンジニアの技術力を向上させ、より良いサービスを世の中に提供できるようにするために企画されました。

今回、記念すべき第一回目のテックフェスは、以下のようなタイムスケジュールで行われました。

テックトーク

今回は、テックフェス後半で行われたテックトークでの内容をご紹介したいと思います。

テックトークのコーナーでは、各事業部のシステム開発を行う開発チームリーダークラスのエンジニアが、開発を通じて得られた経験のふりかえりや技術の活用法についての話を5〜10分の時間でプレゼンしました。テックトークのタイトルは以下の通りです。

インフラリソースや関数型言語など技術にフォーカスした話から、事業部側と密に連携する開発体制についてなどレバレジーズの開発組織ならではの話もあり、短い時間ながらもとても役に立つ内容でした！

テックトークの内容を開発に活かしてみたい！

今回のテックトークに刺激を受け、私のチームのシステム開発に活かしてみたい！という気持ちが生まれました。私は様々なトークテーマの中から、現在の私の開発に活かせるものがないかを模索しました。

開発チームリーダーにSFA開発の現状を確認したところ、以下のようなインフラの構想があることがわかりました。

現状：開発環境のみオンプレミスサーバーで作業している
今後：Docker・Github Actions・クラウドコンテナサービスを利用した自動デプロイ環境を構築したい

しかし、この環境構築の担当エンジニアは決まっておらず技術調査もあまり進んでいない状況でした。

そこで、テックトークでの『Cloud Runへのデプロイ自動化が簡単で脳汁が出てしまった話』の内容をさらに深ぼり、クラウドのコンテナリソースについて調査・検証してみました！

技術調査・比較

テックトークは主に以下のような内容でした。 Cloud Runを使えばコンテナの自動デプロイが簡単に行えるそうです。コンテナはベンダーロックインされない特徴を持ち、昨今のマイクロサービスアーキテクチャの実現には不可欠な仮想化技術です。

本当に簡単にデプロイやCI/CDが設定できるのでしょうか？また、他にはどんなコンテナリソースがあり、それぞれの違いは何があるのでしょうか？その違いを知っておきたく思い、クラウドサービスを調査してみました！

テックトークの内容はGCPであり、普段の開発ではAWSを使っていることから、2つのクラウドサービスに対して調査を行います（ちなみに私はコンテナリソースに関してはほぼ無知な状態でした…）。調査した内容をカテゴリ分けすると以下のようになります。

上記のように、同じサーバーレスコンテナリソース同士にも細かな違いが存在するそうですが、それはどのような箇所なのでしょうか？調査を一通り終え、それぞれのコンテナリソースの違いが大まかにわかってきたところでGCP・AWSのコンテナリソースを簡単に検証してみます！

コンテナ自動デプロイ環境構築

今回は、以下の2つのクラウドサービスを用いて検証を行います。

GCP：Cloud Run + Cloud Build
- フルマネージド型コンテナデプロイサービス
AWS：ECR + ECS + Fargate
- フルマネージド型コンテナオーケストレーションサービス

GCPのCloud Runは今回のテックトークで登場し、その手軽さを実感したいと思ったため選択しました。AWSにはCloud Runに似たサービスとしてApp Runnerがあります。App Runnerの設定や機能はCloud Runとほぼ同様のため、コンテナリソース間の違いをあまり実感できないのではないかと思い、今回はApp Runnerより少し複雑な設定や調節が可能な『ECR + ECS + Fargate』を使って検証してみます。

また、今回はクラウドサービスの比較検証がメインであるため、WebサーバーであるNginxを使った簡単なコンテナ環境で動作確認を行います！下記構成でGithubに登録した状態で検証スタートです！

.├── Dockerfile
 └── html
      └── index.html

【GCP】Cloud Run + Cloud Build

まずは、テックトークでも登場したCloud Runを使ってみます。GCPのコンソール上の簡単な操作で自動デプロイ設定が可能なようです。実際に試してみましょう！

GCPにProjectを作成し、Cloud RunとCloud BuildのAPIを有効にします。テックトークで説明された項目を作成したGithubのリポジトリで設定していきます。

次に作成するコンテナの設定をしていきます。今回は検証なのでユーザー認証の設定はせず、リクエストの処理中のみコンテナを起動する設定にしてみます。

設定が終わり、GCPがコンテナの準備を始めます。

作成されたコンテナはhttpsで自動にルーティングされます。 URLにアクセスするとGithubにpushしたコードがデプロイされていることが確認できました。本当に簡単ですね…。

次にCD（Continuous Deployment：継続的デプロイ）の設定をしていきます。コンソールの「継続的デプロイの編集」を押し、以下のように編集していきます。今回はmasterブランチへpushされたイベントでコンテナがデプロイされる設定を行ってみました。

試しにコードに、簡単なcssと画像を追加し、Githubにpushしてみます。すると、そのイベントを検知し、デプロイが始まります。

しばらくするとコンテナが起動し、変更を確認することができました。CDの設定まで非常に簡単にできてしまいます。

【AWS】ECR + ECS + Fargate

次は、AWSのコンテナ用サーバーレス環境のFargateを使って、ECRとECSでコンテナをデプロイしてみます。

ECSはフルマネージド型コンテナオーケストレーションサービスと呼ばれており、Cloud Runよりも設定や導入は複雑ですが、その分高度な設定やコンテナ同士の連携が可能になります。FargateはECSやEKS用のサーバーレス環境であり、AWSユーザーはEC2のようなホストマシンの複雑な設定が必要なくコンテナを運用できます。

GithubとECRを連携させるために、Github Actionsの設定を行います。

初めにAWSのIAMで『AmazonEC2ContainerRegistryPowerUser』のポリシーを設定したユーザーを作成し、アクセスキーを発行します。発行したアクセスキーペアと、あらかじめ作成したECRのリポジトリ名をGithub>Setting>Secrets>Actionsに設定しておきます。

次に作業ディレクトリにて、.github/workflows/main.ymlを以下のような内容で作成します。今回は「tech*」というtagのpushイベントをトリガーにECRにデプロイされるように設定しました。

name: Push and Deploy ECR

on:
  push:
    tags:
      - tech*

jobs:
  build-and-push:

    runs-on: ubuntu-18.04
    timeout-minutes: 300

    steps:
    - uses: actions/checkout@v1    

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-1

    - name: Push to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push image to Amazon ECR
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: ${{ secrets.AWS_ECR_REPO_NAME }}
      run: |
        IMAGE_TAG=$(echo ${{ github.ref }} | sed -e "s#refs/tags/##g")
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

tagをつけてGithubにpushしてみます。するとGithubでBuildされ、AWSへのデプロイが開始します。

ECRにあるリポジトリのイメージURLをECSでタスク定義として設定し、クラスターで作成したサービス内でタスクを実行してみます。

ECRにデプロイされたイメージを、自動でECSコンテナとして起動させるためには、別でさらにAWS CodePipelineを使用して設定する必要があります。今回はそちらは省かせていただきます。

起動したタスクで発行されたパブリックIPにアクセスすると、無事Github Actionsのイベントでpushされたimageのコンテナを確認することができました。

比較

ここまで技術調査・検証をしてきましたが、クラウドサービスにはたくさんのリソースがある中で、結局、どのリソースを使えば良いのでしょうか？

私の感想としては、今回検証に使用したような非常に簡単なアプリケーション構成で「とりあえずコンテナのデプロイやCI/CDを試してみたい！」というニーズにはCloud Runが適しているなと思いました。しかし、本来の開発のような、複数のアプリケーションが連携しているシステムで詳細な設定がしたい場合は、FargateやEC2が選択できるECSも選択肢になると感じました。

また、この疑問に対して、GCPの公式の記事では、以下の図でまとめています。

参考：https://cloud.google.com/blog/ja/topics/developers-practitioners/where-should-i-run-my-stuff-choosing-google-cloud-compute-option

管理工数の少ないコンテナの場合、インフラへの考慮を最小限にとどめることで属人化を防ぎ、エンジニアはアプリケーション開発に集中できる利点により、モダンな開発に浸透している理由がわかります。しかし、サーバーレスで管理の少ない環境であるばあるほど、利用料金は高くなり、カスタマイズの幅が小さくなるといったトレードオフの関係にあります。

開発現場における多種多様なシステム・開発体制に対して、それぞれのケースに適切なリソースを選定するためには、保守運用の人的コストや可用性・移植性等の品質面、また料金面などの複数の観点を考慮し、チームで意見を交え、リソースを選定していく必要があります。