2021-01-08

LimtとOffsetでレコード指定して取得する方法

Rails

LimtとOffsetでレコード指定して取得する方法

レコード数を指定して取得したい時に便利な方法を記載します。

limitメソッドは、取り出すレコード数の上限を指定します。

クライアントテーブルから５レコード取得

Client.limit(5)

↓

SELECT * FROM clients LIMIT 5

最初の30クライアントをスキップして31人目から最大5人取得したい場合はoffsetを利用する

Client.limit(5).offset(30)

↓

SELECT * FROM clients LIMIT 5 OFFSET 30

2021-01-03

RDSデータバックアップについて

AWS

RDSデータバックアップについて

AWSのRDSを利用しているのですが、仮に本番データぶっ飛んだ場合はどうなるのか気になったので調査してみました。

先に結論から言うと、RDSでは自動バックアップシステムがあります。

ですので、適切にバックアップ設定をしておれば問題ありません。

RDSについて

RDSはAWSサービスの一種でフルマネージドデータベースサービスになります。

フルマネージドという名前通り、サーバーのプロビジョニング、パッチ設定、セットアップ、設定、バックアップ、または復元などのデータ管理タスクを自動で行ってくれます。

オンプレミスとは違い、クラウドインフラなのでサーバーの手間が楽であるという特徴があります。

RDSバックアップについて

RDS では、DB インスタンスの自動バックアップはデフォルトで Amazon S3 に作成され、指定した期間安全に保存されます。

さらに、スナップショットを作成することも可能です。

スナップショットはユーザー起動型のインスタンスバックアップで、明示的に削除するまで保持されます。

つまり、仮に本番データが飛んだとしても自動バックアップがあるので復元が可能になります。

RDSバックアップ方法について

自動バックアップされることが理解できたのですが、どのようにバックアップされているのでしょうか？

RDSでは２種類のバックアップ方法が用意されています。

自動スナップショット
手動スナップショット

自動スナップショット

毎日決められた時間になると自動的に行う方法です。

初回は全データをバックアップする「フルバックアップ」ですが、 2回目以降は更新データだけをバックアップする「差分バックアップ」となりますので、バックアップデータ量は少なくなります。

手動スナップショット

任意の時間に自分で操作してバックアップを行う方法です。（名前の通りですね）

手動スナップショットは、フルバックアップとなります。

バックアップはどうやって行う？

こちらの記事がわかりやすかったです。

最も効果的なリスク回避策！RDSのバックアップ方法を理解しよう | Tech Dive

保存期間は？

RDSでバックアップされたデータはどのくらいの期間保存されるのでしょうか？

自動バックアップの保持期間は、最大 35 日間まで設定できます。

つまり、約1ヶ月前までのデータであれば復元可能ということですね。

参考

Amazon RDS バックアップと復元 | クラウドリレーショナルデータベース | アマゾンウェブサービス

2020-12-23

Kubernetesさまざまなデプロイ形式について

Kubernetes

Kubernetesさまざまなデプロイ形式について

Kubernetesはさまざまなデプロイ形式をサポートしています。

自動復旧やスケーリング、コンテナ群のアップデートなど、デプロイに関する作業の一部はKubernetesによって自動化されています。

Kubernetesについてはこちら

Deployment

Deploymentは、Pod群を一定数を維持しながらクラスタ上に展開するのに有用なリソースです。

Deployment機能で優秀なのがセルフヒーリングです。

セルフヒーリングは障害の発生などによりクラスタ全体で設定された数のPodが正常に稼動していない場合に、自動的に新たなPodを実行し復旧を試みる機能です。

障害時に自動で修復作業をしてくれるのでサービスの可用性を向上してくれます。

f:id:lhiroki1205:20201222023623p:plain

さらにDeploymentはPod群のスケーリングもサポートしてくれます。

例えば、以下のような設定をします。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hoge-worker
spec:
  replicas: 2  <===== 稼働されるPodの数を1->2に変更

そのあとにkubectlを実行するとPodが自動的にスケールします。

$kubectl apply -f hogehoge.yaml

JobとCronJob

Jobとして、最低限成功する必要のあるPod数、タイムアウトする時間、失敗時の再実行ポリシー、許容される失敗回数などを設定すると、Kubernetesはそれに従ってPodをデプロイして実行し、Podの終了ステータスからその成否を判定して再実行などの処理を行います。

さらにこのJobリソースを制御し、Cronフォーマットで実行開始時間や定期実行などの設定が可能なCronJobというリソースも利用できます。

定期実行したいような処理はCronjobにして実行時間などをセットアップすることでバッジ処理が可能になります。

CronJobとJobの違いについては以下の記事が詳しく書かれていました。 engineering.mercari.com

参考

Amazon.co.jp：イラストでわかるDockerとKubernetes Software Design plus eBook: 徳永航平: Kindleストア

2020-11-23

Docker環境をオーバーライドする方法（Doocker-compose.override.yml）

docker

Docker環境をオーバーライドする方法

Composeファイルを複数利用したいケースがあります。

例えば、異なる環境、異なる作業フローに合わせてカスタマイズするケースなどです。

その時によく利用するのがDoocker-compose.override.ymlファイルを利用する方法です。

前提知識

デフォルトにおいてComposeは２つのファイルを読み込みます。

1. docker-compose.yml
2. docker-compose.override.yml

docker-compose.yml には基本的な設定を含めます。こちらはよく利用するので既に何と無くイメージがつかめると思います。

docker-compose.override.yml ファイルは、オーバーライドという表現が含まれていることから分かるように、既存のサービスあるいは新たに起動する全サービスに対しての上書き設定を行うものです。

利用例

docker-compose.override.ymlが利用されるよくあるケースで、開発環境向けのComposeアプリを各環境で切り替えたい場合です。

例えば、本番環境と開発環境のポート番号を変えたいとかです。

■ docker-compose.yml

web:
  image: example/my_web_app:latest
  links:
    - db
    - cache

db:
  image: postgres:latest

cache:
  image: redis:latest

上記のようにdocker-compose.ymlに基本設定を記載します。

この基本設定にオーバーライドしたい内容をdocker-compose.override.ymlに記載します。

■ docker-compose.yml

web:
  build: .
  volumes:
    - '.:/code'
  ports:
    - 8883:80
  environment:
    DEBUG: 'true'

db:
  command: '-d'
  ports:
    - 5432:5432

cache:
  ports:
    - 6379:6379

docker-compose upを実行すると、上書き用の設定ファイルが自動的に読み込まれます。

参考

docs.docker.jp

2020-11-18

HTTPのキャッシュについて

WEB

HTTPでキャッシュを利用する方法

キャッシュとはサーバーへのアクセスの頻度や通信量を減らすためにクライアント側で一度とった情報を保存しておき、必要になった時にあらかじめ取得してあった情報を利用することを言います。

■ キャッシュを利用するメリット

1. サーバへの通信を減らすことができるため、ユーザーの体感速度を上げることができる
2. ネットワーク接続が切れた状態でもある程度サービスを継続できる
3. サーバへの通信回数、転送量を減らすことでユーザーの通信コストを下げることができる
4. サーバへのアクセス回数が減ることで、サーバの維持費用を抑えることができる

キャッシュの保存場所はプロキシサーバーになるケースが多いです。(プロキシサーバーとは、クライアントとサーバーの間に位置してやり取りを仲介する機能を果たす。)

プロキシサーバーのキャッシュを利用する時には保存期間を意識しましょう。

オリジンサーバーのデータが書き換わっても最新の情報が反映されないケースがあるからです。

f:id:lhiroki1205:20201118141514p:plain

HTTPのキャッシュタイプ

1. Expiration Model
2. Validation Model

Expiration Model

あらかじめ、レスポンスデータに保存期間を決めておき期限が切れたら再度アクセスして取得を行う。

いつ期限が切れるかはサーバーからのレスポンスに含めて返すことで実現できます。

レスポンスはCache-Control レスポンスヘッダを使う方法、もう 1 つが Expires レスポンスヘッダを使う方法です。

Expires: Fri, 01 Jan 2016 00:00:00 GMT 
Cache-Control: max-age=3600

Validation Model

今保持しているキャッシュが最新であるかを問い合わせて、データが更新されていた場合にのみ取得をおこなう。

f:id:lhiroki1205:20201118142246p:plain

キャッシュさせたくない場合

逆にキャッシュをさせたくない場合はCache-Control ヘッダをno-cacheにすればキャッシュされません。

Cache-Control: no-cache

Cache-controlヘッダ一覧

f:id:lhiroki1205:20201118142859p:plain 　

参考

www.oreilly.co.jp

2020-11-17

Raisでバルクインサートする方法

Rails

Raisでバルクインサートする方法

Railsでバルクインサートする方法を記述します。

バルクインサートとは？
↓
qiita.com

では、Railsでバルクインサートするにはどうすれば良いのでしょうか？

フルスタックフレームワークであるRailsであればバルクインサートする時用のメソッドを独自に定義されてそうですね。

Railsではinsert_allメソッドを利用すれば簡単にバルクインサート出来そうです。

edgeapi.rubyonrails.org

具体例

■ハッシュを渡す

users = (1..100).map { { name: 'name', created_at: Time.current, updated_at: Time.current } }

これで、バルクインサートしたいusersの情報を作成出来た。

次にinsert_allの引数にバルクインサートしたいusersを渡して実行します。

User.insert_all(users)

これで引数に渡されたusers情報がUserテーブルにバルクインサートされます。

参考

qiita.com

2020-11-14

エラーの詳細をクライアントに返す方法

WEB

エラーの詳細をクライアントに返す方法

エラーが発生した時はステータスコードをクライアントに返却します。

クライアントサイドに起因するエラーは400番台。
サーバーサイドに起因するエラーは500番台。

しかしステータスコードだけでは、詳細情報がわからないのでエラー詳細情報を返却することが重要になります。

エラー内容を返す方法は大きく分けて２つあります。

1. HTTPレスポンスヘッダーに入れて返却する

HTTPレスポンスヘッダーに返却する場合は以下のように独自に定義したヘッダー項目を用意して情報を入れます。

X-MYNAME-ERROR-CODE: 2013 
X-MYNAME-ERROR-MESSAGE: Bad authentication token
X-MYNAME-ERROR-INFO: http://docs.example.com/api/v1/authentication

レスポンスボディに入れて返却する

レスポンスボディに入れる方法は以下のようにJSONのレスポンスボディをエラーの際の専用のデータ構造を用意して、そこにエラー内容を格納して返却します。

{ 
  "error": { 
    "code": 2013, 
    "message": "Bad authentication token", 
    "info": "http://docs.example.com/api/v1/authentication"
    }
 }

どっち利用すべき？

現時点ではレスポンスボディにエラー内容を格納する方がポピュラーなのでそちらで問題ないでしょう。