今週勉強したことまとめ(2017/12/04 ~ 2017/12/10)

今週はECSの使い方を手を動かしながら学んだ。 細かいドキュメントは読み込めていないので今後読んでいく必要があるが、 最終的にCircleCIでDockerイメージをビルドしECRにpush後、ecs-deployコマンドで開発環境にデプロイするという流れを自動化するまでできた。 作成したリソースを消す際にALB周りでつまったところがあったので、リソース削除時は最新の注意を払う。 今後まとめる際はリンクだけ貼るのではなく、少なくとも中身を一行ぐらいで説明するようにする。

AWS

ECS

  • EC2インスタンスクラスターでDockerコンテナを実行できるサービス

  • ECS CLI

    • ローカル開発環境からのクラスター及びタスクの作成、更新、モニタリングを簡素化する高レベルなコマンド
    • DockerComposeファイルがサポートされている
    • インストール
      • MacOSの場合 sudo curl -o /usr/local/bin/ecs-cli https://s3.amazonaws.com/amazon-ecs-cli/ecs-cli-darwin-amd64-latest sudo chmod +x /usr/local/bin/ecs-cli ecs-cli --version
    • 設定 ecs-cli configure --region us-west-2 --access-key $AWS_ACCESS_KEY_ID --secret-key $AWS_SECRET_ACCESS_KEY --cluster ecs-cli-demo
  • ecs-deploy

  • サービス定義時に紐づけるロードバランサを間違えるとインスタンスがひとつもないターゲットグループをさしてしまうので注意

  • サービスを削除したい場合は以下の三段階の手順が必要
    • クラスター > サービスの設定でタスクの数を0にする
      • これをしないと自動でタスクが起動してしまうため
    • クラスター > タスクでタスクを停止する
    • クラスター > サービスでサービスの削除を実行する
  • クラスター内のインスタンスのリソースで足りない場合はタスクが起動しない

  • ECSでコンテナのrolling update

  • ECS運用のノウハウ
  • マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017

ALB

  • ヘルスチェックを設定しないと503
  • 同じセキュリティグループに関連付けられたインスタンスが相互に通信できるようにするには、そのためのルールを明示的に追加する必要がある
    • 送信元IPにセキュリティグループのidを指定する
  • パスベースのルーティングを変更したい場合は
    • EC2 > ロードバランサ > リスナーtab > ルールの表示/編集を押すと管理画面が表示される
    • まちがってターゲットグループをロードバランサに紐づけてしまった場合はここからパスごとにターゲットグループの紐づけを解除しなければ、ターゲットグループそのものを削除できない

Aurora

  • パラメータグループ
    • 何も指定しなければデフォルトのパラメータグループになる
    • デフォルトのパラメータグループは変更できないため作り直しになるので注意
    • Auroraの場合はクラスターパラメータとDBインスタンスパラメータの2種類がある

Docker

bitrise

  • アプリのビルド専用のCIサービス
  • 50$/月でビルドし放題

SideCI

  • コードレビューを自動でしてくれるCIサービス

SonarQube

SpringBoot

Play framework

MySQL

  • MySQLの文字コード事情
  • charset
    • utf8mb4
      • UTF-8で4バイト文字を扱うためのcharset
      • mysql特有
      • これを選んでおけば良い
  • collation
    • 文字の照合規則・照合順序
    • utf8mb4_general_ci
      • utf8mb4のデフォルトのcollation
      • ASCII大文字小文字を区別しない
      • 絵文字を区別しない
    • utf8mb4_bin
      • 全文字を区別する
    • utf8mb4_unicode_ ci
      • ASCII大文字小文字を区別しない
      • 絵文字を区別しない
      • ひらがな、かたかな、濁点有無、全角、半角を区別しない
  • MySQL Connector/Jプロパティリスト
  • 現在接続しているスレッド数を表示する
    • show status like 'Threads_connected';
    • Max_used_connections これまでに記録された同時接続数の最大値
    • Threads_connected 現在開いている接続の数
    • Threads_created 接続を処理するために生成されたスレッド数
    • Threads_running スリープ状態になっていないスレッド数

Java

英語

  • can be used when
    • ~の場合に使用できる

今週勉強したことまとめ(2017/11/27 ~ 2017/12/03)

今週はAWS re:Inventが開催され様々な新サービスが発表された。 サービス数が多すぎて全部を追うことができていないが、 今回特に気になったのはコンテナ周りのサービスで Managed KubernetesのEKSとFargeteという二つのサービスが発表された。 アプリケーションの実行環境の選択肢が増え、より自社のサービスに適した構成を構築できるようになったが、 AWSのサービスを組み合わせて適切なインフラを設計する難易度がどんどん上がっている気がする。 今後は機械学習で最適なアーキテクチャを提案するサービスが出てきてくるのではないだろうか。 そのほかに今週は、あまりにも忘れていることが多いので システムプログラミング周りやネットワーク周りの基礎を勉強し直し始めた。

AWS

re:Invent

CloudFront

Aurora

  • DBクラスターが作成される
  • DBクラスターは以下の二つから構成される
    • 一つ以上のDBインスタンス
      • プライマリインスタンス
        • 読み込みと書き込みの操作をサポートし、クラスタボリュームに対する全てのデータ変更を実行する
        • Aurora DBクラスターには一つのプライマリインスタンスが存在する
      • Auroraレプリカ
        • 読み取りオペレーションのみをサポートする
        • DBクラスタは15までのレプリカを持つことができる
    • 一つのクラスタボリューム
      • インスタンスのデータを管理する
      • 複数のアベイラリティゾーンにまたがる単一の仮想データベースストレージボリューム
      • SSDドライブを利用する
      • 単一リージョンの複数のアベイラリビリティゾーン間のデータのコピー
      • 3つのアベイラビリティゾーン間で自動的にレプリケートされる
      • データベースのデータ量が増えるにつれて自動的に容量が増加する
      • 最大64TB
  • エンドポイント
    • Amazon AuroraDBクラスターのDBインスタンスに接続するための口
    • ホストアドレスとポートがコロンで区切られたURL
    • クラスターエンドポイント
    • 読み取りエンドポイント
      • Auroraレプリカに接続するためのエンドポイント
      • DBクラスターへの読み取り専用接続のロードバランシングを提供する
      • 接続リクエストを利用可能なレプリカに分散する
    • インスタンスエンドポイント
      • 特定のDBインスタンスに接続するDBインスタンス用のエンドポイント
      • DBクラスターへの接続の直接制御を提供する
        • 例えば、クライアントアプリケーションで接続ではなく読み取りワークロードによるロードバランシングが必要な場合
    • インスタンスエンドポイントを使用する前にクラスターエンドポイントか読み取りエンドポイントが使用できないか確認する
  • 信頼性
    • ストレージの自動修繕
      • ディスクボリュームの障害を自動的に検出し、すぐにそのセグメントを修繕する
      • 修復時に他のボリュームないのデータを使用して、修復されるデータが最新であるようにする
    • キャッシュのウォームアップ
      • データベースがシャットダウン後に起動した場合バッファプールキャッシュをウォームアップする
      • メモリ内のページキャッシュに保存された既知のクエリのページをバッファプールに事前ロードする
      • ウォームアップをしなくて良いのでパフォーマンスが向上する
      • ページキャッシュはデータベースとは別のプロセスで管理される
      • このため、データベースに障害が発生した場合でもページキャッシュはメモリの残り、バッファプールはデータベース起動時に最新の状態にウォームアップされる
    • クラッシュ回復
      • クラッシュから瞬時に回復する
  • クラスターの作成
  • [Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス

コンテナ

システムプログラム

  • http://www.coins.tsukuba.ac.jp/~syspro/2017/
  • http://www.coins.tsukuba.ac.jp/~yas/
  • OSとは
    • OSはハードウェアの違いを隠蔽し、ユーザがプログラムを実行するための使いやすい環境を提供する
    • ハードウェアを抽象化した概念を提供することで、いろいろなコンピュータで共通に使用できる実行環境を提供する
    • OSが提供する抽象概念
      • (ハードウェア機能) -> (抽象概念)
      • プロセッサ、メモリ -> プロセス
      • ストレージ -> ファイル、ディレクト
      • コンピュータ間の通信 -> プロセス間通信
      • 割り込み -> シグナル
      • コンピュータ共有時の保護 -> アクセス制御
  • API
  • シェル
    • CLIを通して、ユーザからのコマンドを受け付け、解釈・実行し、その結果を出力する機能を提供するプログラム
    • コマンドの入出力をファイルや別のコマンドにするリダイレクションやパイプという機能を提供する
      • 比較的単純な機能を持つ複数のコマンドを組み合わせて複雑な機能を実現することが可能
  • コマンド
    • ユーザがコンピュータに与える命令
    • UNIXはシェルから利用できる非常に多くのコマンドを提供している
    • コマンドはシェルとは別のプログラムの場合もあるし、シェルに組み込まれている場合もある
  • システムコール
    • OSカーネルの機能を直接呼び出すためのインタフェース
    • できるだけシンプルになるように設計されている
  • ライブラリ・ミドルウェア
    • プログラムの部品となる関数の集合
  • システムコールもライブラリもCプログラムから呼び出す場合はどちらも関数呼び出しの形態で使用できるため同じに見える
  • UNIXカーネル
    • プロセッサの特権モードというハードウェアの全てを制御できる動作モードで動作し、直接ハードウェアを制御するプログラム
    • UNIX環境で特権モードで動作するプログラムはカーネルだけ
    • その他のプログラムは、ユーザモードと呼ばれるハードウェアへのアクセスが制限された環境で動作する
  • ライブラリ関数とシステムコールの違い
    • 実行時にライブラリ関数はそれを使用するプログラムの一部となるが、カーネルは完全に独立したプログラムとして存在する
    • プログラムとライブラリは同じプロセス空間にある、しかしカーネルは別の場所(カーネル空間)にありプロセスからアクセスできないところで実行されている
    • プロセスはシステムコールを通じてのみカーネルの機能を使うことができる
    • プログラムからの入出力は結局はシステムコールを通じて実行される
    • ライブラリだけで実現される機能もある
      • 文字数を数えたり、文字列を比較したりといった、入出力を伴わないがプログラムでよく使われる部品となるような機能をライブラリは提供している
  • プロセス
    • プログラムを実行中のもの
    • 一つのプログラムを複数実行することができる
    • プログラムは、CPUが実行できる機械語命令とそれにより処理されるデータの集合がファイルに格納されたもの
    • プロセスは実行中の情報
  • manコマンド
    • man -k キーワードでキーワードに関連するコマンドを表示してくれる

Redis

Network

  • CIDR
    • アドレスクラスの概念を気にしないことで、IPアドレスの割り当てや経路選択などの自由度をあげる仕組み
    • IP空間を分割する仕組みの一つ
      • アドレスクラスだとBとCの間で大きさが違いすぎて非効率
      • ブロックの大きさを柔軟に変更できる
    • /16で65536のホスト

Spring Boot

  • Spring Boot外部設定

  • ロック待ち

    • SpringBoot/jUnit/MySQL/DBSetup/AssertDBで単体テスト実行時、テストが終了しなくなることがあった
    • 一つのテストケースだけでは発生しないが、複数のテストケースをまとめて実行した際に発生するためロック待ちをしていると考えられる
    • 参照系のメソッドをテスト時にはテストクラスに@Transactionアノテーションを付与することでロック待ちに陥ることがなくなった
    • 逆に更新系のメソッドに@Transactionをつけてしまうとテストが終了しなくなったのでアノテーションを外しておいた

MySQL

  • private subnetないのDBに接続して操作したい場合、Sequel Proで踏み台サーバ経由でアクセスできる
  • SQLモード
  • IFNULL(expr1, expr2)
    • expr1がNULL出ない場合、IFNULL()はexpir1を返し、それ以外の場合はexpr2を返す
    • expr2もNULLの場合はNULLを返す

キーボード

  • Barroco
    • Fn + Aでレイヤー切り替え

英語

  • presumably
    • おそらく
  • density
    • 密度
  • At the moment
    • 現時点では
  • comes at a cost
    • 高くつく
    • コストが必要となる
  • Elastic
    • 伸縮自在の
  • That being the case
    • それなら、だとすれば、そういうことなら
  • pure play
    • ~を専業とする

その他

  • 年金

    • 厚生年金(国民年金)控除証明書はハガキで送られてくる
      • 年末調整で使用するため捨てないこと
    • 控除証明書を紛失した場合は年金事務所で再発行できる
    • 転職などで途中で支払いが途切れている場合は控除証明書を発行できない
  • Heptio

    • Kubernetesを専業とする起業
  • Entrepreneur in Residence

  • 客員企業制度
    • 起業家が特定の企業に入社し、その企業で起業準備をする

今週勉強したことまとめ(2017/11/11 ~ 2017/11/26)

勉強したことについてメモしたものを一週間ごとにまとめてみることにした。 ブログのネタになりそうなものがあれば、ここから記事にまとめるところまでいけると良い。 初回は2週間分になってしまっている。まとめ方が難しい。

Java

  • Arrays.asListは固定長のリストを生成するのでaddやremoveできない
    • new ArrayList<>(Arrays.asList())を使う
  • lombok@Dataをつけるときは@Builderの後につけないとGetterやSetterが正しく作成されずエラーになる
  • synchronizedブロック
    • 他のスレッドから割り込まれないようにブロックする
  • KeyStore
  • keytool
    • jdkが提供するキーストアを操作するツール
    • キーストアから秘密鍵を抽出する機能は持たない

Spring Framework

  • ErrorControllerインタフェースは@Controllerがエラーのレンダリングに使用されていることを示すためのマーカーインタフェース
    • 主にセキュアにする必要のないエラーパスを知るために使用される
  • SpringBootはデフォルトで全てのエラーをハンドルする/errorマッピングする
    • /errorをハンドリングするコントローラを実装すればそこでエラーレスポンスをいじれる
  • server.error.whitelabel.enabled=falseを設定することでデフォルトのエラーページを非表示にできる
  • @ResponseStatusは返すべきステータスコードと理由とともにメソッドや例外をマークする
  • SpringBoot Actuator
    • アプリのモニタリングや管理機能を提供するSpringBootのサブプロジェクト
  • NamedJdbcTemplate
    • NamedParameterJdbcOperationsをimplementしている
    • JDBCの操作の基本セットをもつテンプレートクラス
    • '?'プレースホルダーそのものではなく名前付きパラメータを使用することができる
    • 実行時に名前付きパラメータの解決を行い、あとはJdbcTemplateにデリゲートしている

CQRS

  • コマンドクエリ責務分離
  • 質問することで答えを変えてはいけない
  • 全ての基本操作がコマンドかクエリになる
    • コマンドはシステムの状態を変更する
    • クエリは状態を変更せず報告する

Editor

mysql

Redis

Test

  • unit test
    • テストの定義「ある条件下においてソフトウェアの振る舞いを記録し、その記録が期待される結果となることを検証するプロセス」
    • テストケース -> ひとつのテスト項目のこと

英語

  • via: ~することで
  • with: 使用して

DNS

AWS

ECS

ECR(EC2 Container Registory)

  • AWSが提供するDockerレジストリサービス
  • レジストリがイメージリポジトリとイメージを管理する
  • Error response from daemon: Get https://.dkr.ecr.ap-northeast-1.amazonaws.com/v2/: proxyconnect tcp: dial tcp : getsockopt: connection refusedが出たらDocker再起動でなおった

AWS Shield Advanced

Docker

  • docker buildコマンドはDockerfileとコンテクストによってイメージを構築する

  • コンテクスト

    • dockerコマンドを実行するディレクトリ、ディレクトリに含まれる内容物
    • ビルドプロセスの初めにコンテクストがDockerデーモンに送信される
    • PATH(ローカルフィル上のディレクトリ)やURL(Gitリポジトリの場所)を指定できる
    • Dockerfile上でCOPYなどを行う場合はコンテクスト外のリソースを指定することはできない
    • dcoker build コンテキストPATH -f DockerファイルでDockerfileが保存されている場所とは別の場所をコンテキストに指定できる
  • tag

    • 同じタグをつけると新しいimageにつけ変わる
  • ネットワーク機能

    • Docker ネットワーク機能の概要
    • ユーザが自分自身でネットワークを定義し、コンテナを接続できる
    • docker network lsでネットワークのリストを表示
    • デフォルトで以下の三つのネットワークが生成される
      • brigdge
      • null
      • host
    • docker run --network=<NETWORK>でコンテナがどのネットワークに接続するかを指定できる
      • このオプションを指定しない限りデフォルトのbridgeに接続される
  • docker-compose

    • depends_onとlinkの違い
      • v2では違いはない、v1ではdepends_onはコンテナの作成順序と依存関係を解決するのに対して linkはそれに加えてエイリアス名を使用してコンテナにアクセスできるようになる

Circle CI

bash

fish shell

  • && はfishでは; andと書く

Code coverage

Mac

  • ipコマンドをインストールする方法

    • brew install iproute2mac
  • KarabinerElementsで外部キーボード接続時に内部キーボード無効化

    • Devices > Disable the buildin....

iPhone

  • iPhone X
    • アニ文字
      • 自分の顔の表情を反映させたアニメーションキャラクターアイコン
      • メッセージAppで作成・共有できる
      • サマーウォーズ的な世界観が実現するかも?

Network

  • ブリッジ

    • レイヤー2で異なるネットワーク間を通信できるようにする装置
  • NIC(ネットワークインタフェースカード)

    • eth0, eth1, eth2...という順番で名前がつく
    • lo0
      • ネットワークのテストに使用できるように用意された仮想インタフェース
      • NICがなくてもこのloは表示される
      • 127.0.0.1IPアドレスとして自動で割り当てられる
    • gif0(generic tunnel interface)
      • IPv6/IPv4トンネリングを行うときに使うインタフェース
    • stf0(6to4 tunnel interface)
      • IPv6パケットをIPv4ネットワークにルーティングするためのインタフェース
      • gifは両方できる
    • p2p0
    • awdl0
      • Apple Wireless Direct Link
      • Apple機器と無線通信を行うためのインタフェース
    • utun0
  • MTU

    • ネットワークにおいて1回の転送(1フレーム)で送信できるデータの最大値を示す伝送単位

高速化

  • dev.to
    • 海外版Qiitaのようなサイト
    • とても早い
    • 理由
      • Fastlyでキャッシュ
      • Cloudinaryで画像をwebpに変換し配信
      • styleのレンダリングをしない

その他

  • C10K問題
    • 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
    • TheC10kProblem

Spring Boot開発時に見ると良い記事まとめ

Spring Boot開発時に参考になるドキュメントのまとめです。

general

トランザクションマネージャ

Bean

Docker

Lombok

  • setter/getterを作ってくれるやつ
  • builderパターンをやってくれる

日付

ログ

Gradle

Config

Controller

アノテーションまわり

DockerでNginxをシュッと構築する

フロントエンドでちょっとした作業があった際に、ぱっと確認するためにWebサーバが必要だったのですが、 そこでDockerを利用したところ大変便利だったのでメモを残したいと思います。

やりたいこと

  • ローカルにコマンド一発でWebサーバーを構築したい
  • 手元のファイルを編集したらブラウザを更新するだけで反映されてほしい
  • ポート番号がかぶらないように80番以外のポートで確認したい

解決策

  • docker-composeを使ってnginxを一コマンドで構築する
  • dockerのvolume機能を使ってホストのディレクトリをマウントしリアルタイムで変更を確認できるようにする
  • envsubstで環境変数をコンテナ起動時に埋め込む

DockerでNginxを構築する

上記の解決方法を実際に試してみます。

ちなみに、今回使用したツールのバージョンは以下のとおりです。
docker: 1.13.1
docker-compose: 1.11.1

まず適当なディレクトリを用意します。

$ mkdir nginx
$ cd nginx

次にdocker-compose.ymlファイルを作成し、保存します。

web:
  # 公式のdockerイメージ
  image: nginx 
  volumes:
   # ホスト側のnginxの設定ファイルのテンプレートをコンテナ側にマウント
   - ./mysite.template:/etc/nginx/conf.d/mysite.template
   # コンテンツを含むディレクトリをマウント
   - <表示したいhtmlを含むディレクトリのパス>:/var/www
  ports:
  # ポートを設定(ホスト:ゲストの順)
   - "8080:80"
  environment:
   - ROOT=/var/www/
  command: /bin/sh -c "envsubst '$$ROOT' < /etc/nginx/conf.d/mysite.template > /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"

volumesでホストのディレクトリをマウントすることで、dockerを再起動せずにローカルファイルの変更を反映できるようにしています。
また、commandenvironmentに設定した環境ファイルをテンプレートに埋め込みnginxの設定ファイルを生成した後、nginxの起動を行っています。 ちなみに、'daemon off;'はデーモン化(background実行)をしないようにするための設定です。 dockerはルート・プロセスをフォアグラウンドで動かさないとコンテナが停止してしまうためこの設定が必要になるようです。

ここまでできたら、同じディレクトリにnginxの設定ファイルのテンプレートファイル(mysite.template)を作成します。

server {
    listen 80;
    server_name localhost;
    root    ${ROOT};
    index index.html; 
}

これで準備完了です。 docker-composeを実行してnginxを起動してみましょう。

$ docker-compose up

これで、nginxが起動しブラウザから確認できるようになったと思います。 ポートを変更したい場合はdocker-compose.ymlのportsのホスト側を変更すれば任意のポートでアクセスできます。

まとめ

dockerを使ってnginxをシュッと構築する方法を試してみました。 一度configファイル・テンプレートを作成しておくと次回からは少し修正するだけで簡単にwebサーバを作成できますので大変便利だと思います。

参考文献

Firebaseでチャットアプリのサンプルを作った

TL;DR

チャット機能があるアプリをAWSで作ろうとしたが意外と難しそうだったのでFirebaseを試してみた

モチベーション

AWS導入事例では ALBの下にEC2やコンテナを並べてRedisのpub/subで…みたいなことをしていて結構大掛かりになりそうでした。 これは大規模な例ですが、AWSでチャット機能を実装しようとするとどうしてもSocket.io・WebSocket等を使うことになります。

今作りたいアプリではチャットはメインの機能ではないしフルスクラッチで開発するのは工数的にも厳しいので、 出来合いのものを埋め込むかPaaSを利用してもうすこし簡単に作りたい。 少し調べたところLayerというものを見つけましたが、 まだ完全にビジネスに耐えれるものでは無さそうでしたので諦めて、FirebaseのRealtimeDBを使ってみることにしました。

やったこと

チャットを実装するチュートリアルが公開されていたのでそれをやってみます。

https://codelabs.developers.google.com/codelabs/firebase-web/index.html#0

このチュートリアルでは以下の内容を網羅できるので今回のアプリにはぴったりでした。

  • Firebaseのプロジェクト作成
  • Googleアカウント認証機能
  • Firebase Realtime DBでメッセージの送受信
  • 画像の送受信
  • notificationの実装
  • デプロイ

所感

ちょっと機能がたりてない感がありますが、思ってた以上に簡単にチャット機能を実装でました。
本当はサーバーサイドでメッセージを受信したらイベントドリブンでプッシュ通知を相手側に送るみたいなことをやりたかったのですが、 Firebaseだけでは完結できませんでした。やるとしたらサーバー立ててRealtimeDBの全トピックをListenしてmessageがあったらプッシュ通知API叩くみたいなことをやらないといけない気がします。
pushイベントをhookできればLambdaでサーバレスできそうなので少し残念。 料金は高いですが初期のフェーズはFirebase Realtime Databaseを使用してスケールしてきたらチャット基盤を構築するということにしておくとそれほど問題にはならなさそうです。
圧倒的な速度でチャット機能を実現できるのでとりあえず迷ったらこれで作ってみるのが良さそうです。

Amazon Cognitoの認証フローを調べた

Amazon Cognitoを使う機会があったので調べたことをまとめました。

Amazon Cognitoとは

Amazon Cognitoはユーザの認証やデータ同期を提供するサービスです。

以下の3つの機能があります。

  • Cognito User Pool
    • AWSが提供する認証システム
  • Cognito Federated Identities
    • 任意の認証システムをつかったサインアップ機能の提供
  • Cognito Sync
    • ユーザデータ同期

今回はFederated Identitiesについて調べました。

Cognito Federated Identities

Cognito フェデレーテッドアイデンティティでは次の様なことができます。

  • ユーザの一意のIDを生成
  • Cognito User Poolや外部の認証システム(Facebook, Twitter等)と連携しユーザを認証
  • 権限が制限された一時的なAWS認証情報をクライアントに提供
  • 未認証ユーザにもIDを発行し一時的な認証を提供することができる

仕組み

Facebookを認証システムとして利用する場合、 iOSAndroidSDKのメソッド名等の細かい部分は異なるが大まかなフローは以下の通りです

https://github.com/takatori/blog/raw/master/entries/20170405/img/Cognito.png

  1. AWS SDKFacebookとの認証を行う
  2. FacebookがOAuthトークンをSDKに返す
  3. 取得したOAuthトークンをパラメータとしてCognitoのGetIdを呼び出す
  4. Cognitoは受け取ったトークンからidを生成もしくは既にある存在するidを取得して返す
  5. SDKが受け取ったidを指定してクレデンシャル情報取得APIを呼び出し
  6. Cognitoが一時的なクレデンシャル情報を返す

他にも認証フローがありますが、上記の方法が最も一般的なやり方のようです。

まとめ

Cognitoは機能がたくさんあり、ドキュメント分量が多いので一見複雑なことをしているように見えますが、 整理してまとめてみると意外とシンプルなフローで認証が行われていることがわかりました。 ドキュメントに書いて有ることを自分でかきなおしてみるのも結構勉強になりますね。

参考