2019-10-24

AWS CLIでIAMユーザとグループ作成

10/23のJAWS-UG初心者支部勉強会でアウトプットが大事だと皆さんおっしゃっていたので、久々のブログです。
JAWS CLIの紹介もあったので、CLIに慣れるという意味でIAMユーザとグループを作ってみます。

まずグループを作ります。今回S3のフルアクセス権限のポリシーを付与したいと思うので、名前は s3-full とします。

$ aws iam create-group --group-name s3-full
{
    "Group": {
        "Path": "/",
        "GroupName": "s3-full",
        "GroupId": "AGPAXRPO5PHWDNVTUOQ3S",
        "Arn": "arn:aws:iam::518581484012:group/s3-full",
        "CreateDate": "2019-10-23T14:15:17Z"
    }
}

作成したグループにポリシーを付与します。

$ aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --group-name s3-full

ちゃんとポリシーが付与されているか確認します。

$ aws iam list-attached-group-policies --group-name s3-full
{
    "AttachedPolicies": [
        {
            "PolicyName": "AmazonS3FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess"
        }
    ]
}

ユーザを作ります。

$ aws iam create-user --user-name satosan
{
    "User": {
        "Path": "/",
        "UserName": "satosan",
        "UserId": "AIDAXRPO5PHWLG4E7I2B5",
        "Arn": "arn:aws:iam::518581484012:user/satosan",
        "CreateDate": "2019-10-23T14:24:24Z"
    }
}

ユーザを先ほどのグループに追加します。

$ aws iam add-user-to-group --user-name satosan --group-name s3-full

最後にグループに作成したユーザが追加されているか確認です。

$ aws iam get-group --group-name s3-full
{
    "Users": [
        {
            "Path": "/",
            "UserName": "satosan",
            "UserId": "AIDAXRPO5PHWLG4E7I2B5",
            "Arn": "arn:aws:iam::518581484012:user/satosan",
            "CreateDate": "2019-10-23T14:24:24Z"
        }
    ],
    "Group": {
        "Path": "/",
        "GroupName": "s3-full",
        "GroupId": "AGPAXRPO5PHWDNVTUOQ3S",
        "Arn": "arn:aws:iam::518581484012:group/s3-full",
        "CreateDate": "2019-10-23T14:15:17Z"
    }
}

ちゃんと追加されてますね。
なんとなくAWS CLIの感じが掴めました。

2019-05-25

N+1問題

最近「Ruby on Rails 5アプリケーションプログラミング」という本でRailsを勉強しています。

Rails チュートリアルを終えて、アプリ開発を進めてみたものの、知識の継ぎ接ぎ感が一向に拭えず、、、
アプリ開発が一区切りついたので、体系的にRailsを学びたいと思いこの本を読み始めました。

前置きはそれぐらいにして、その本の中でビューヘルパーの「grouped_collection_select」が出てきました。
その節では多対多の関係にある「books」テーブルと「authors」テーブルを使って、
各authorごとにグルーピングして本を選択できるようにするという感じです。 f:id:koji-sato1242:20190525165044p:plain
controllerとviewは以下の通り。

def group_select
  @review = Review.new
  @authors = Author.all
end

<%= form_for(@review) do |f| %>
    レビュー対象
    <%= f.grouped_collection_select :book_id, @authors, :books, :name, :id, :title %>
<% end %>

これを動かしたときのターミナルはこんな感じ。
f:id:koji-sato1242:20190525165842p:plain

SQL発行されすぎじゃない？
author増えていったらDB死ぬやつですね。

ググってみるとこの現象が「N+1問題」というやつみたいです。
N+1問題 / Eager Loading とは - Rails Webook

余談ですが、最初「N+1問題」という言葉を見たとき、
『N+1問題』ってクライアントが増えていったときのHTTPサーバのパフォーマンスの問題じゃなかったっけ
と思いましたが、それは「C10K問題」でした。いっぱい問題がありますね。

「N+1問題」の解決方法としては、「includes」メソッドを使って、事前にauthorと関連するbookを取っておくという方法です。
ループの中で毎回bookを取り行くのではなく、ループに入る前にいっきに取っておくといった感じです。

includesを追加してみました。

def group_select
  @review = Review.new
  @authors = Author.all.includes(:books)
end

このときのターミナルはこんな感じ。
f:id:koji-sato1242:20190525172801p:plain

INを使ってSQLが１つにまとめられてます。解決です。

O/Rマッパーは便利な分、こういった問題があるので気をつけないといけないですね。

2019-05-18

Google = 1e100.net

ネットワークの調査をするためにtracerouteを使っていたときに、
ふとあることが思い浮かびました

googleまでいくつサーバを経由して行くんだろう

ということで実際に調べてみました。
Windows環境で調べたのでtracerouteではなく、tracertを使っています。

C:\Users\jicor>tracert www.google.co.jp

www.google.co.jp [172.217.25.227] へのルートをトレースしています
経由するホップ数は最大 30 です:

1 2 ms 3 ms 2 ms speedwifi-next.home [192.168.100.1]
2 * * * 要求がタイムアウトしました。
3 45 ms 39 ms 46 ms 172.25.157.162

・・・

17 55 ms 59 ms 59 ms 108.170.242.129
18 72 ms 57 ms 57 ms 108.170.233.21
19 63 ms 55 ms 56 ms nrt12s14-in-f227.1e100.net [172.217.25.227]

トレースを完了しました。

結果19回ホップして到達しました。
こんなもんなんですね。

そんなことより、googleのホスト名が「nrt12s14-in-f227.1e100.net」であるようなので、ググってみると「1e100.net」はgoogleのドメインのようです。
support.google.com

そして、その名前の由来がおもしろく、以下のように書かれています。

大抵の典型的なインターネットユーザーは1e100.netを見かけることはないと思いますが、念のために我々はグーグルらしい名前をドメイン名にしました（1e100は 1 googol の科学表記です）。

googolという単位があるのは初めて知りましたし、そしてそれがgoogleの由来であるらしいです（諸説あるようですが）。
ドメイン名にこういった工夫をするのもgoogleらしいですね。

2019-05-05

sessionとcookieでのクッキーの使われ方

Rails チュートリアルでsessionとcookieが出てきたがわかりにくかった。
どちらの説明にもクッキーが出てきてわかりにくかった感があるので、
sessionとcookieでのクッキーの特徴をまとめてみる。

sessionで使われるクッキー

セッションID＋セッションデータ（例：ユーザID）で構成
メモリに保存されており、ブラウザを閉じると破棄される

（補足）クッキーの中にセッションデータも入れ込む方式はRailsでは「CookieStore」という。

cookieで使われるクッキー

トークン＋ユーザを特定するデータ（例：ユーザID）で構成
ディスクに保存されており、ブラウザ閉じる閉じないに関係なく、保存期間が切れるまで残る

考察

最初はcookieを使う意味がわからなく、
「セッションクッキーがブラウザを閉じても破棄されないようにすればいいじゃん・・・」
と思っていたが、保存先（メモリorディスク）が違うというので納得した。
セッション張ってるときにサーバにリクエスト送る度にディスクアクセスしてたら遅くなるからメモリに保存するしかない。
ただ、ブラウザを閉じると割り当てられたメモリは解放するしかないから、破棄されてしまう。
一方、cookieで使われるクッキーはセッションを張り始めるときにしか使わないから、ディスクに保存してても速度的に問題ない。

参考HP