8tako8tako8’s blog

ソフトウェアエンジニア

Rails + React アプリを ECS Fargate にデプロイする【1. IAM編】

これは何？

React と Rails で実装したWebアプリを、AWS環境にデプロイするまでの備忘録の IAM 編です

総集編を読んでいない方は コチラ

本記事でやること

以下のインフラ構成図のように構築する際に必要となる ECS にアタッチする IAM ロールを作成します

ECS に必要な権限

  • ECR からのイメージ取得や、CloudWatchへのログ出力等
  • S3 へのアップロードとオブジェクト取得
  • SES を使用したメール送信
  • Systems Manager Parameter Store から認証情報の取得と、Session Manager によるコンテナへのアクセス許可

作成手順

※ 今回は遊びで構築するだけなので権限はかなり緩く設定していきます

AWSサービス: IAM から「ロール」をクリックします

「ロールを作成」をクリックします

以下のように設定し「次へ」をクリックします

許可ポリシーで以下を追加し「次へ」をクリックします

  • AmazonECSTaskExecutionRolePolicy
  • AmazonS3FullAccess
  • AmazonSESFullAccess
  • AmazonSSMFullAccess

ロール名を入力し「ロールを作成」をクリックします

これで IAM ロールの作成が完了です

最後に

今回は、ECS にアタッチする IAM ロールを作成しました

次は、ネットワーク編 に進みましょう！

Rails + React アプリを ECS Fargate にデプロイする【0. 総集編】

これは何？

SmartHR Advent Calendarシリーズ2の10日目です。

React と Rails で実装したWebアプリを、AWSの ECS Fargate にデプロイするまでの構築手順を全 8 回に分けて紹介します

前提

この記事に書いていないこと

  • ドメインの取得方法
  • 各設定の細かい意図
  • 以下は今後実装予定なので今回は書きません
    • CI/CD
    • Terraform等によるIaC

細かい仕様

  • バックエンドはECS Fargateにデプロイする
  • マルチAZ構成にする
  • ドメインを購入してhttps通信する
  • インターネットからの通信をロードバランサでECSへ振り分ける
  • データベースはRDS PostgreSQLを使用する
  • データベースはプライベートサブネットに配置する
  • 認証情報等はSystems Managerで管理する
  • 画像をS3に保存する
  • メールをSESで配信する
  • フロントエンドはS3をオリジンとしたCloudFrontで配信する

インフラ構成図

以下を構築します

注意点

  • AWSの利用料が発生します
  • 特に明記していない場合、東京リージョン(ap-northeast-1)で構築しています
  • 学習用のため、最小限のリソースで構築しています
  • IAMポリシーなどの権限を厳しく絞っていません
  • 記事内ではリソース名を適当に命名しています(hoge等)

構築手順

最後に

AWS を触るのが久しぶりだったのと、初 ECS だったのもあって若干苦戦した所がありましたが、なんとかWebアプリを動かすことができてホッとしています

今後は、GitHub Actions による CI/CD の構築と、Terraform による IaC に挑戦していきます！

Macを買い換えたのでセットアップしました

はじめに

先日、MacBookを買い換えました！ 必要なアプリをインストールしたり、設定するのに結構時間を使ってしまったので、備忘録として残しておきます。

前提

Macの設定

キーの反応速度をMaxに変更

Finderのサイドバーに表示する項目に「ホームディレクトリ」を追加

Dockを左に表示させる

デフォルトであるアプリをDockから削除

不要なものをDock外までドラッグすれば削除できます

Karabiner-Elementsでキーバインドを変更

エディタ操作以外の時もVimライクに操作したいのでキーバインドを変更しています。個人の好みがあるので、飛ばしてもらって構いません。

CapsLock → Control に変更

Complex Modifications > Add rule から以下のImport 〜をクリック

Left ctrl + hjkl to Arrow Keys Vimをimport

Importしたものを有効化

これで、以下のようにカーソル移動が簡単に行なえるようになります。

key value
Control(CapsLockキー) + j ↓
Control(CapsLockキー) + k ↑
Control(CapsLockキー) + h ←
Control(CapsLockキー) + l →

必須アプリ

Chrome

以下の拡張機能を入れており、概ねデフォルトの設定のまま使用しています。

VSCode

Vimで操作したいので入れています。

また、jkでInsertモードを抜けるための設定や、タブサイズを2に変更するように、settings.jsonは以下のようになっています。

{
  "vim.insertModeKeyBindings": [
    {
      "before": ["j", "k"],
      "after": ["<Esc>"]
    }
  ],
  "vim.hlsearch": true,
  "editor.tabSize": 2
}

Slack

デフォルト設定のまま使っています

Discord

デフォルト設定のまま使っています

便利なアプリ

DeepL

ドラッグし[Command + C] x 2で翻訳できるの便利です。

Clipy

複数件のクリップボードを管理できる優れものです。 デフォルト設定のまま使っています。

Skitch

スクショしたものを簡単に編集できるので、ちょっとした共有に役立ちます。（↓の画像はこんなことができるよ、ってだけで特に意味はありません）

RunCat

CPU使用率が一目でわかるように猫を走らせています。

おまけ

WIP

参考

【入門】ReactアプリをGitHub Pagesに公開してみる

はじめに

Reactに入門したばかりの初心者向け記事です。ReactアプリをGitHub Pagesに公開する方法を解説します。

前提

  • Reactアプリの開発環境が既にセットアップされていること
  • yarnがインストールされていること
  • GitHubアカウントがあり、公開したいアプリのリポジトリが作成されていること

GitHub Pagesとは

GitHub Pagesとは、GitHubが提供している静的なウェブサイトをホスティングするサービスです。

GitHubのリポジトリにHTML、CSS、JavaScript、画像などの静的ファイルをプッシュすることで、ウェブサイトとして公開することができます。

なお、GitHub Pagesは無料で利用することができますが、公開できるウェブサイトの数やトラフィックに制限があるので注意してください。

公開方法

1. 必要なパッケージのインストール

gh-pagesというパッケージをインストールします。以下のコマンドを実行してインストールします。

yarn add gh-pages -D

2. package.jsonの更新

package.jsonファイルにhomepageフィールドを追加します（username, my-appは適宜変えてください）。 また、scriptsセクションにpredeploy, deployを追加します。

例えば、こんな感じ

{
 "name": "my-app",
 "version": "0.1.0",
 "private": true,
 "homepage": "https://username.github.io/my-app/",
 "scripts": {
   "start": "react-scripts start",
   "build": "react-scripts build",
   "test": "react-scripts test",
   "eject": "react-scripts eject",
   "predeploy": "yarn run build",
   "deploy": "gh-pages -d build"
 },
 // 省略
}

3. アプリのデプロイ

アプリをデプロイします。以下のコマンドを実行します。

yarn run deploy

ここまでで公開されているはずです。 https://username.github.io/my-app/を確認しましょう。

4. GitHubリポジトリの設定

3で公開が確認できなかった場合、GitHubリポジトリの設定を確認します。

GitHubのリポジトリに移動し、Settings > Pages > Build and deployment でgh-pagesブランチに変更します。 改めて、https://username.github.io/my-app/を確認しましょう。

まとめ

簡単な手順でReactアプリをGitHub Pagesに公開する方法を解説しました。 制限はありますが無料で公開できるので、ぜひ試してみてください。

【感想】「Everyday Rails - RSpecによるRailsテスト入門」を読んで

はじめに

「Everyday Rails - RSpecによるRailsテスト入門」はRSpecでの基本的なテストから実践的なテストまでのテストの書き方を学ぶのに最適な本です。有料のコンテンツ（数千円）ですが、値段以上に質と量が良いものとなっています。今回の記事は、RSpecを習得するため、本を読んだ感想です。

良かったところ・学んだこと

RSpecを体系的に学べる

RSpecのセットアップから始まり、モデルスペックやリクエストスペック、さらには速いテストの書き方も学ぶことができるので、RSpecを網羅的に知りたい人にとっては最適な本でした。

手元でサンプルコードを使用してテストコードを実装できる

手元でテストコードを実装できるようにソースコードが提供いたり、章ごとにブランチが分けられているので、アウトプットがしやすかったです。

著者の経験に基づいてテストの書き方を学べる

Railsエンジニアとして経験豊富な著者が普段意識してどのようにしてテストを書いているか学ぶことができました。 重要なポイントが随所で解説されるので、覚えておきたい情報の取捨選択がしやすかったです。

最新のRailsに対応している

Rails7や最新のgemの仕様に合わせたサンプルコードで記述されています！ 古い書籍だとRailsのバージョンが低いことがよくあるので、最新のRailsで学べる数少ない教材だと思います！

難しかったこと

スタブやモックの実装方法は少し難しく感じた

スタブやモックを用いたテストの例が紹介されていましたが、普段扱うことのない高度なテストをやっているように見えました。 解説がしっかりしているので理解できたはずです。

初耳のgemがあった

launchy, shoulda-matchersなど触れたことのないgemがいくつかあり、とっつきにくく感じた。

あわせて読むと良いもの

この本を翻訳した伊藤淳一さんが書かれた記事です。要点がまとまってるので先に読むといいかも。

まとめ

RSpecの体系的に学ぶことを目的として読みましたが、著者の経験などからそれ以上のことが学べたり、TDDで開発しよう！という気にさせられたので、得たものは大きかったです。モデルスペックやリクエストスペックについてはもう一度読み直そうと思います。

REST APIを知る

はじめに

この記事では、現代のWebアプリケーションで広く使われているREST APIについて、RESTの基本原則や設計の基本ルールを紹介します。

REST APIとは

REST原則

①クライアント・サーバー構造

  • クライアント（データ利用側）とサーバー（データ提供側）が明確に分かれている

②ステートレス

  • サーバーがクライアントの状態を保存せず、各リクエストは独立している
    • メリット
      • リクエストが独立しているため、追加のサーバーを導入して容易に負荷分散できる
      • 障害が発生したリクエストのみリカバリーすればよいため、容易に障害復旧できる
    • デメリット
      • ステートフル（サーバーがクライアントの状態を保持）と比べてリクエストデータに重複がある

③キャッシュ制御

  • レスポンスデータをキャッシュ可能
    • メリット
      • リソース効率の向上
    • デメリット
      • 古いデータを取得する可能性がある

④階層化システム

  • システムは複数の階層で構成され、各階層は独立して機能する
    • メリット
      • 各システムが分離されているので柔軟性と拡張性が向上
    • デメリット
      • システム間のデータ処理にオーバーヘッド発生

⑤コードオンデマンド

  • クライアントにコードをダウンロードして提供できる
    • メリット
      • 容易にクライアントの機能追加
      • クライアントのリソースを利用できるのでサーバー負荷軽減
    • デメリット
      • 複数のブラウザ（Chrome, Edge）のように評価環境が異なる

⑥統一インターフェース

リソースの識別

  • 各リソースはURIを用いて識別される
    • （例）/users（ユーザー情報の一覧）

リソースの操作

  • リソースのある断面情報を利用してデータを操作する
    • （例）Authorization（認証情報）

自己記述メッセージ

  • レスポンスヘッダーから内容（メタ情報）の意味が理解できる
    • （例）Content-type（メディアタイプ）

HATEOAS

  • リソース間の関連や状態遷移に関する情報が含まれる
    • （例）次のページへのリンク

REST API設計の基本

URI設計

URI(Uniform Resource Identifier): リソースを識別するための文字列

ルール

  • リソースを表現
    • （例）o:/users, x:getUsers
  • 自然と理解できる名詞
    • （例）o:/users, x:/u
  • リソース間の関係性を表現するために階層構造を使用
    • （例）/users/123/orders
  • 複数形を使用
    • （例）/users
  • 小文字を使用
    • （例）o:/users, x:/USERS
  • -を使用（_を使用しない）
    • （例）o:/favorite-users, x:/favorite_users

URIとHTTPメソッドの組み合わせ

usersをリソースとしたCRUD操作の例です。

name URI HTTP method
ユーザーの新規登録 /users POST
ユーザーの取得（複数件） /users GET
ユーザーの取得（1件） /users/1 GET
ユーザーの更新 /users/1 PUT
ユーザーの削除 /users/1 DELETE

クエリとパスの使い分け

  • 省略可能か？
    • YES→クエリパラメータ
      • （例）ユーザーを検索条件で検索: /users?name=8tako8tako8（nameがなくても検索可能）
    • No→パスパラメータ
      • （例）特定のユーザーの注文一覧: /users/1/orders（user_id: 1は省略できない）

まとめ

REST APIの基本原則と設計の基本ルールを紹介しました。今回はレスポンス設計やOpenAPI(Swagger)について含めていないので、機会があればまとめてみます。

【感想】「達人に学ぶDB設計 徹底指南書」を読んで

概要

普段の業務でデータベース設計を行っているので基本的なことはわかっているつもりですが、知識の再確認のため、データベース設計の入門書で有名な「達人に学ぶDB設計 徹底指南書」を読んだ感想です。

良かったところ

  • 複雑なデータベース設計の概念をわかりやすい説明がされており、初心者でも理解しやすい内容となっていること
  • 正規化等のデータベース設計のベストプラクティスを学ぶことができたこと
  • 当たり前のようにやっている正規化について、その名前（第o正規形など）を知ることができたこと

悪かったところ

主キーに「可能な限り自然キーを使う」

主キーに「可能な限り自然キーを使う」という点が引っかかり、「それは状況によるのでは？」と思いました。

主キーに自然キーを採用するデメリットとして、自然キーが変更されると、それに連動して他の関連テーブルも更新する必要があります。

一方、代理キーでは、自然キーと比べ変更される心配がほぼないので、他のテーブルへの影響が少なくてすみます。

絶対に変更されない自然キーなら問題ないかもしれませんが、そうとは言えない自然キーの方が多いかと思うので、代理キーを使うのが無難だと思います。

学んだこと

インデックスが効かないケース

インデックス列に演算を行っている

select *
from users
where point * 10 > 100;

インデックス列にSQL関数を適用している

select *
from users
where substr(name, 1, 1) = 'A';

is nullを使っている

select *
from users
where name is null;

否定形を使っている

select *
from users
where name <> 'tako8tako8';

orを使っている

この場合、インデックスを効かせるためには、in()を使うようにしましょう

select *
from users
where name = 'tako8tako8' or name = '8tako8tako8';

インデックスのデメリット

書き込み性能の低下

データの挿入、更新、削除の際にインデックスも同時に更新する必要があり、書き込み操作のパフォーマンスが低下する可能性がある。

定期的なメンテナンスが必要

テーブルのデータが更新されていくと、長期的には構造が崩れて性能が劣化していくため、インデックスの貼り直しをする等の定期的なメンテナンスが必要になる。

ストレージ容量の増加

インデックスを作成することで、データベースが消費する容量を増加させるため、インデックスの貼りすぎには注意する。

難しかったこと（今後の課題）

本書ではあまり触れられていないが、パフォーマンスチューニングについては、あまり経験（実行計画を見てインデックスを貼り直す程度）がないので、より良いインデックスの貼り方や効率の良いクエリを書けるようになることを今後の課題にしたい。

まとめ

ある程度業務でデータベース設計をやっている人でも学びがある良書でした。特に、インデックスまわりの知識はデータベースを深く知る上で重要となる知識であるため今後も学習していきたい。