たいきゅんの日記

ITエンジニアの積み上げ日記

terraform基礎 -Dockerで環境構築とS3バケットを作成-

今回はterraformをDockerで環境構築し、簡単なS3バケットの操作を紹介したいと思います。
「Terraformに入門してみた」という記事も作成しておりますので、良ければ併せて読んでください。
taikyunn-blog.hatenablog.com

環境構築

まずは環境構築からです。
TerraformのDocker imageが公開されているためこちらを使用します。
一つのコンテナだけですが、楽なのでdocker-compose.ymlを使用しています。

docker-compose.yml

version: '3'
services:
  terraform:
    container_name: terraform
    image: hashicorp/terraform:latest
    volumes:
      - .:/terraform
      - ~/.aws:/root/.aws
    working_dir: /terraform/terraform
    entrypoint: ash
    tty: true

TerraformでAWSのリソースを構築する場合、AWSへアクセスができるcredentials情報が必要となります。
今回は~/.aws 配下にcredentials情報が保存されていることを前提として作成しました。
もしご自身のPCのAWS credentialsが別のフォルダーに設定してある場合はそちらに適宜変更していただければと思います。

envファイルを使用してcredentialsを直書きしてgitignoreする方法もありますが、
もしものことがあるためこちらの方がいいかもしれません。

この状態で docker compose up -d --build をしていただくとコンテナが立ち上がるはずです。

S3バケットを作成しよう

S3バケットの作成に関してです。
基本的には公式Docの通りにコーディングすれば作成することができます。
Terraformはバージョンアップするごとに記法が変わったりするので、バージョン情報には注意してください。

公式Doc
registry.terraform.io

main.tfを作成

Terraformを作成する上ではmain.tfファイルが必要でないとエラーになるので注意してください。
main.tfはterraform/terraformフォルダ内に作成してください。

main.tf

# AWSを使用する宣言
provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_s3_bucket" "b" {
  bucket = "test-bucket"
  acl    = "private"

  # バージョニング設定
  versioning {
    enabled = true
  }

  # デフォルトの暗号化
  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

こちらがterraformの初期設定とS3バケットの作成をするtfファイルです。
コメントを記載していますが、詳細は公式Docを参照してください。

リソースの作成

ファイルが作成できたら、terraformを使用するためのセットアップコマンドを実行します。

docker compose exec terraform terraform init

こちらが正常に実行されると自動生成ファイルが作成されます。

次にterraform planを実行し、terraformが実行できるかチェックします。

docker compose exec terraform terraform plan

文法エラーがある場合はエラーが表示されますが、ない場合は下記のように表示されるはずです。

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

上記が表示されたらあとは構築するのみですが、、コードの整形を行ってからにしましょう。

// 整形
docker compose exec terraform terraform fmt
// リソースの作成
docker compose exec terraform terraform apply

リソースの破棄

terraform apply時実行確認がされると思いますので、yes と入力してください。
コマンドが完了すると、S3バケット(バケット名:test-bucket)が作成されるはずです。

リソースを廃棄したい場合は、terraform destroyコマンドを実行すれば自動的に廃棄されます。

// 整形
docker compose exec terraform terraform destroy

まとめ

私はterraformが初めて使用したIaCツールだったのですができた時思った以上に簡単でかつ少しプログラミングができるようになった気がして感動しました!
AWSで手動で構築していると裏側で自動的に構築してくれている時があると思いますが、IaCツールを使用することで自動構築してくれていた箇所を意識することが必要になりさらに理解が深まると思います。
使ったことない方は是非使ってリソース構築を簡単にして欲しいです。導入ハードルは思った以上に高くないと思います!
最後まで読んでいただきありがとうございました!

「誰も教えてくれなかったアジャイル開発」を読んでみた

今回は「誰も教えてくれなかったアジャイル開発」という本を読んだのでアウトプットしていきます。
この本を一言で言うと「アジャイル(以下AG)とは何か?」を理解するために、よく対比される「ウォーターフォール(以下WF)」と対比しながら説明してくれる一冊です。

読む上での注意点

この本を監修している企業はITコンサルタント事業の企業でWF開発をしている企業にAGを導入した経験を元に書かれております。そのため比較的WF開発の内容が多めになっております。その分AGへの理解が深まるという点もあるかと思いますが、AG開発をしている自社開発企業のエピソードではないため注意していただければと思います。
どちらかというとエンジニアよりマネージャー向けの本かもしれないです。

AG開発についての理解の変化

AG開発に関して、読む前まで私は小さく進めながら試行錯誤とリリースを繰り返しながら進めていくものと考えておりました。その反面仕様が決まっていない状態で設計することが多く、PMとエンジニアの役割分担が難しいなぁとも感じたりしていました。

読んだあと改めて考えると今までの理解はあながち間違ってないことを感じました。そしてAG開発自体型が確定しているものではなく、企業風土や担当するPMによって変化するものであると思いました。
この「型が決まっていない」点がAG開発の最大の強みでもあるかなと思います。エンジニアとしてAG開発に携わる際は、過去や型にとらわれず案件ごとにベストな方法は何か?を考えチーム全体で最適の形に常に変化させていくことが大事であると感じました!
極端な考え、例えば「AG=ドキュメントは作らない」「WF=ドキュメントをしっかり作る」といった考えはあまり持たないほうがいいと思いました。

まとめ

AG開発に関しての理解が深まった一冊でした。
そして技術と同じく常にアップデートをかけていかないといけないなとも思いました。アップデートに追いついていかないと企業にとってプラスの存在でいれないかもしれないので、動向をキャッチアップしていこうと思いました。
正解がないのがAGのいいところなので、プロダクトにとってベストの形を常に求めていきたいと思います!

AG・WFの知識に自信がない方の初心者本としてはおすすめなので、よければ読んでみてください。


memcachedに入門してみた

今回は、memcachedについてまとめてみようと思います。
弊社サービスでも採用されているのですが、触る機会があまりなく中身もわからなかったため今回まとめてます!
読み方は「メムキャッシュディー」と読むみたいです。間違っていたら教えてくださいmm

memcachedとは

memory cache daemonの略称になります。
分散メモリキャッシュシステムを構築することができるキャッシュサーバーになります。
メモリ上にデータを保存し、key-value-store方式でデータを保存するNoSQLに分類されるサーバーです。格納できるデータはstring型のみとなっています。

特徴

  • データの読み込み・書き込み速度が速い

メモリ上にデータを保存するためデータの読み込み・書き込み速度が速いです。メモリ上で管理するため再起動するとデータはリセットされてしまいます。そのため消えても問題ないデータを保存することに向いています。
設定した容量を超えると、利用されていないキャッシュから削除されていきます。(LastRecentlyUsed)

  • RDSの負担軽減

サーバーのメインメモリ上にファイルやデータベースの内容を一時保存して、高速に読み出すために使用されます。
またRDSと連携してクエリの実行結果を一時的に保存するために使用されたりもします。
RDSと組み合わせることでRDSの読み込み負担を軽減も期待できます。

  • マルチスレッドで動作

マルチスレッドで動作するため、CPUのコア数を上げるとパフォーマンスも上がります。

  • Redisとの比較

redisほど使えるコマンドが多くなく、シンプルかつスピード重視が特徴です。

Redisとmemcachedの比較

1. 永続化

redisはデータベースであるため、データの永続化が可能。
memcachedキャッシュであるためデータの永続化は不可能。

2. スピード

redisはデータベースであるため、スピードは重視されていない。
memcachedはキャッシュであるため、スピードが重視されている。

3. データの種類

redisはList型Set型等複雑なデータ型が使用できる。
memcachedはkey-value-store型のみとシンプルなデータ型のみ使用できる。

4. マルチスレッド対応

redisはマルチスレッド非対応。
memcachedはマルチスレッド対応。

Redis・memcached共にキャッシュを扱うためのものであるとの認識はあったものの、調べてみると特徴がそれぞれあり、同じキャッシュでも用途が異なるものであることが分かりました。
速度重視の時代なので、開発力がある程度ついたらキャッシュの知識も深めていきたいと思いました!
最後まで読んでいただきありがとうございました!

Amazon Auroraについてまとめてみる。

今回は、Amazon Auroraに関してまとめてみようと思います。
新規開発でAmazon Aurora Serverlessを使用するので、基本から改めてまとめてみようと思います。

Amazon Auroraとは

Amazon AuroraAWSが開発したMySQLおよびPostgreSQLと互換性のあるクラウド向けRDBのことです。
従来のMySQLおよびPostgreSQLは、OSSで安価であるのがメリットの一つですが、一方で性能を十分なものにするには別途スキルが必要になります。こちらをカバーするため、性能面や拡張機能を充実させたものがAmazon Auroraです。

AmazonRDSとAuroraの違い

1. コスト面

  • AmazonRDS: コスト低。
  • Aurora: (RDSに比べると)かかる傾向にある。

2. データベースエンジン

3. データベースバージョン

  • AmazonRDS: あらゆるバージョンを選択できる。
  • Aurora: 選択できるバージョンが限定されている。

(例)PostgreSQLは10・11・12・13・14のみ。

Auroraのアーキテクチャ

Auroraはクラスタという単位で構成されています。
クラスタは、1つ以上のDBサーバーで構成されるインスタンス層とデータを管理するストレージ層で構成されています。

  • インスタンス層: SQLなどの処理を実行する層
  • ストレージ層: データを保存する層。

データを保存するストレージ層は2.3AZにわたりコピーされるため障害が起きた際もデータベースの稼働に影響が出ないようになっています。

https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html
インスタンス

インスタンス層は、プライマリ DB インスタンスAurora レプリカの二つから構成されています。

Auroraの特徴

1. バックトラック
より高速にデータベースの状態をリカバリする機能で、データを巻き戻したり進めたりすることができます。

2. クラスタキャッシュ管理
プライマリインスタンスが持っているキャッシュを特定のAuroraレプリカと共有することができる機能。
障害発生でフェールオーバーが行われた際に、キャッシュがフェールオーバーされないと一時的にDBの処理能力が下がってしまいます。クラスタキャッシュ管理を使用することで、フェールオーバー時のDB処理能力を抑えることが可能となります。

3. 並行クエリ
インスタンス層が実行するクエリ実行等の処理をストレージ層のリソースにオフロードして実行させる機能で、クエリの実行高速化が実現できます。

4. マルチマスター
従来のRDSはシングルマスター構成だが、Auroraは複数のプライマリDBを使用することができます。
よって片方のプライマリDBで障害が発生しても、もう片方のプライマリDBで継続的な書き込みができます。

特徴はまだたくさんあるのですが長くなってしまうため、一部のみの紹介とさせてください。

AmazonRDSかAuroraかの判断基準

1. AmazonRDSを選ぶ理由

  • 最新バージョンを使用したい。
  • Auroraでは利用できないサービスを利用したい。

2. Auroraを選ぶ理由

  • Aurora独自の機能を使用したい。
  • 運用面・性能面で最適化されたサービスを利用したい。
  • 信頼性のあるサービスを利用したい。

Auroraについて改めてまとめてみました。
一つの記事にまとめようとするともっと大きくなってしまうため、一つ一つの機能にフォーカスしてまとめてみようと思います。
最後まで読んでいただきありがとうございました。

2023年のマンダラチャートを作成してみました!

みなさんこんにちは。たいきゅんです。
2023年も引き続きよろしくお願いいたします。
今年はさらなる飛躍のために目標設定から入っていこうと思います

マンダラチャートを導入。

目標設定で有名なマンダラチャートを採用してみました。
大谷選手が高校生時代に作成したものが有名ですね。
詳細はググっていただければと思いますが、真ん中に達成したい目標を設定したのち、それを達成するための目標をマンダラ状に作成していく目標設定方法です。
初めて作成したのですが見た目がすっきりしていて個人的にも満足しています。

作成したマップがこちら


こんな感じになりました。
サウナの目標は急がず見つかったら再度アップデートしようと思います。
目標の中でも特にストレッチな目標を赤色で記載してみました。

マップに関して改めて記載

今年も積み上げていくことを大事に一年間進めていこうと思っています。
目標について改めて考えてみると、常に考えていないと浮かばないものだなと感じました。
今年は目標を考える時間を多く、毎月FBをしてこの目標を達成することを大切に進んでいきます。
皆さんも目標を立てつつ今年を進めていくのはいかがでしょうか?
最後まで読んで頂きありがとうございました。

Redisに入門してみた。

今回は入門記事として、Redisの入門をアウトプットしてみます。
Redisを使った開発が最近初めてだったので、キャッチアップ記事としてまとめていきます。

Radisとは

RedisはRemote Directory Serverの略で、メモリ上でデータを管理するインメモリデータベースです。
メモリ上で動作するため高速で、システムが頻繁に読み出すデータの複製を高速に配信するキャッシュサーバーとして用いられることが多いです。NoSQL型のDBでkey-value型に分類されます。
C言語で開発されており、AWSではAmazonElasticCacheのエンジンにRedisが採用されています。
使用されているサービスとして、slackやPinterestが挙げられます。

インメモリデータベース

データを**メインメモリ上(RAM)**上の領域に格納するように設計されたDB・DBMSで、電源を切ると中身が失われてしまいます。
システムの終了・再起動時や一定時間ごとにメモリ上の内容をストレージに保存して、データの永続性を保持する機能が搭載されています。
ストレージ上に構築するDBに比べてデータの読み書きを**数桁高速に**行うことができる一方、大量のデータを保持するにはコストがかかってしまうのが特徴です。

特徴

1. データ永続化設定
インメモリデータベースのため、データはサーバーの電源を落とすと消えてしまいます。データ永続化のためRDBとAOF二種類の永続化方法があります。
RDBRedis Data Baseの略で、あるタイミングのスナップショットを残す機能です。
AOFはAppend Only Fileの略で、データが更新されるたびに更新履歴を記録していくトランザクションログ機能のことです。
両機能を同時に有効にすることが可能でこれが推奨されています。デフォルトではRDBのみ有効となっています。
AOFファイルとRDBファイルの両方が存在する場合は**AOFファイルが優先**されます。
RDBファイルはRedisの起動時に自動的に読み込まれ、前回終了時のデータが復元されます。


2. 複雑な形のデータを操作し保存できる
一般的なkey-valueデータベースとは違って複数のデータ型が用意されているため、多くのデータ型を扱うことが可能です。
(例: 文字列型・リスト型・ハッシュ型)

3. 不整合が生じない
Redisはトランザクション処理のように複数の操作を一連の流れで実行する際も、全**ての操作が正しく完了しない限り、データが最初の状態に戻る**特徴があります。よって複数の処理が**全て実行されるか、全く実行されないかが保証**されており、データの不整合が生じないです。

4. 各言語のクライアントで取得したデータを使用可能
JavaPythonPHPなどの各種言語で取得したデータが使用可能です。

5. メモリの消費が大きい
メモリ上で動くため、サーバーやPCのコスパが下がる可能性があります。

環境構築(Docker環境)

docker-compose.yml

version: '3'
services:
  redis:
    image: "redis:latest"
    ports:
      - "6379:6379"
    volumes:
      - "./data/redis:/data"
      # redisの設定ファイル
      - "./redis.conf:/etc/redis.conf"


redis.conf

# メモリの最大値を設定
maxmemory 100MB

# Redisのメモリ量がmaxmemoryに達した場合、LRCアルゴリズムに従いどれかのキーを削除
maxmemory-policy allkeys-lru

上記2ファイルを用意してもらい、docker-compose up -dでコンテナを立ち上げます。
その後コンテナに入り、redis-cliコマンドでシェルを起動させることで完了です。

まとめ

Redisの基礎と簡単な環境構築まで紹介しました。
概要は紹介できたと思うので、実際に触りながら学習を進めればRedisを使いこなせるようになるはずです。
最後まで読んで頂きありがとうございました。

minioに入門してみた。

今回は、開発環境でいつも動いているけど何者か分からなかったminio(ミニオ)について調べてみようと思います。



minioとは

分散オブジェクトストレージです。イメージとしてはS3に似たもので、オブジェクトストレージを構成するためのソフトウェアです。最大5TBまで保存できGo言語で実装されています。


特徴

1. S3の代わりをローカルで実現できる。

minioはS3互換のAPIが実装されているため、S3の開発をローカル環境で行う際に代わりにminioを使用することができます。つまり本番環境ではAmazon S3・開発時には、MinIOで開発・テストする。といった開発が可能です。




2. Dockerとの相性

Docker環境で動作確認することが可能でDockerとの相性がいいこともminioの特徴。




3. AWSの動きを確認できる

さらにaws-cliやコンソールから操作することが可能でaws-cliの動きの結果をminioで確認することができるのも特徴の一つです。




4. 分散構成を取れる

Minioは1台でも実行可能だが、分散構成も取れます。分散構成の場合、オブジェクトは自動的に分散・複製されて保存され、ストレージ破損に備えることができます。

一方で後からノードやストレージサイズを増やすことができない。つまり予め決まったサイズで運用をするか、新たなMinioクラスタを構築して、データの保管場所を調整するなどの対応が必要になります。



Docker環境サンプル

Docker環境でminioを動かすためのサンプルを紹介します。



docker-compose.yml

version: '3.9'

services:
  minio:
    image: quay.io/minio/minio:latest
    environment:
      MINIO_ROOT_USER: root
      MINIO_ROOT_PASSWORD: password
    command: server --console-address ":9001" /data
    ports:
      - 9000:9000
      - 9001:9001


この状態でbuild upしてもらいhttp://localhost:9001/ にアクセスします。
上記で設定したMINIO_ROOT_USER MINIO_ROOT_PASSWORDを入力することでログインができます。

AWS CLIの設定

(上記Docker環境でAWS CLIを使用することを想定)

xxxxxxxxxx minio-demo % aws configure
AWS Access Key ID [None]: root
AWS Secret Access Key [None]: password
Default region name [None]: 
Default output format [None]:

上記docker-compose.ymlで設定した値を設定することでAWS CLIを使用することができます。

バケット操作(aws-cli)

1. バケット作成

xxxxxxxxxxxx % aws --endpoint-url http://localhost:9000 s3 mb s3://miniotest
make_bucket: miniotest

(上記docker-compose環境で作成された環境前提)
上記コマンドで`miniotest`というバケットが作成されます。バケットはフォルダとは違って階層的にフォルダを掘っていくことはできないです。
コマンドのエンドポイントは9000番、ページのエンドポイントは9001番になるので注意。


2. バケット一覧

xxxxxxxxxxxx % aws --endpoint-url http://localhost:9000 s3 ls

2022-09-24 16:30:51 miniotest
2022-09-24 16:27:13 test-bucket


3. ファイルアップロード

xxxxxxxxxxxx  % aws --endpoint-url http://localhost:9000 s3 cp testfile s3://miniotest/testfile_from_local
upload: ./testfile to s3://miniotest/testfile_from_local

上記コマンドで、カレントディレクトリにあるtestfileを、miniotestバケットにtest_from_localという名前でアップロードすることができます。


4. ファイルダウンロード

xxxxxxxxxxxx  % aws --endpoint-url http://localhost:9000 s3 cp s3://miniotest/testfile_from_local testfile_from_s3
download: s3://miniotest/testfile_from_local to ./testfile_from_s3

上記コマンドで、miniotestバケットにあるtestfile_from_localを、カレントディレクトリにtestfile_from_s3としてダウンロードできます。

5. ファイルの削除

xxxxxxxxxxxx  % aws --endpoint-url http://localhost:9000 s3 rm s3://miniotest/testfile_from_local
delete: s3://miniotest/testfile_from_local

上記コマンドでminiotestバケットのtestfile_from_localを削除できます。


6. バケットの中身一覧表示

xxxxxxxxxxxx  % aws --endpoint-url http://localhost:9000 s3 ls s3://miniotest1                                                            
2022-09-24 17:02:30      69353 testXxx.png
2022-09-24 16:58:15     189249 test100.png

7. バケットの削除

xxxxxxxxxxxx  % aws --endpoint-url http://localhost:9000 s3 rb s3://miniotest
remove_bucket: miniotest

上記コマンドで、miniotestバケットを削除できます。

まとめ

実際に動作確認してみると、S3と相違ない開発体験を得ることができました。
開発環境でS3を使うことに抵抗がある方にとってminioは良い選択肢になると思いました。
最後まで読んで頂きありがとうございました。