みなさん、こんにちは。開発部エンジニア平木です。 少しレポートまで間が空いてしまいましたが、去る 7/2(月)にソラシティカンファレンスセンターで開催された Developers Summit 2019 Summer にメドレーが協賛させていただきました。 また、弊社の開発部長である田中が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルのセッションでお話をさせていただきましたので、レポートを書きたいと思います。 会場の雰囲気 会場入口の立て看板がステキでした 会場ですがやはり今回も来場者が多く、セッション前には列が出来ていました。休憩時間中のブースにも人だかりといった感じで熱気を感じました。 次のセッション待ちで長蛇の列が ブースも人が切れませんでした しかしながら、運営が大変にスムーズだったので大きな混乱もなく次々と快適にセッションが見られるのは、やはり今までの経験によるものだろうなーと感じました。 印象に残ったセッション 色々とセッションを見ましたが、個人的にはやはり、 @t-wada さんのセッションは何度見ても惹き込まれるなと今回も拝見して感じました。 今回の内容を聞くと例え、全くテストを導入していないようなプロジェクトだったとしても「明日からちょっとずつやっていこう」と勇気をもらえるような内容でした。 エンジニアのキャリアパス いよいよ、弊社田中のセッションです。残念ながら、資料は非公開とさせていただいています…。申し訳ありません。 内容としては、少し前まではいわゆる SIer と Web 系という 2 つの領域で結構明確に壁を感じることもあったと思います。しかし、近年 X-Tech などの文脈では、関連省庁の法令やガイドラインなどを遵守しつつ、使いやすい UI への落とし込みやマネージドサービスを使用したインフラの構築などを設計する必要があります。これらの設計の上で、Web サービスとして高速に PDCA を回しサービスを改善していくという能力も他方で必要になります。 こういった背景により、きっちりとした要件定義や設計する能力を求められる SIer 的な要素と手を動かして早くサービスを改善するサイクルを回す能力が必要な Web 的な要素という、それぞれの得意領域をミックスしたエンジニアが求められているのではないかというお話をさせていただきました。 途中田中のキャリア変遷や、弊社の CLINICS を例に取り具体的にどのような能力を求められるのか?ということをお話させていただきました。 終了後のアンケートなど拝見する限り、やはり業界の括りに囚われがちなところも多いなか、キャリアパスの一つの実例として、ご好評をいただいたのは嬉しい限りでした。 まとめ メドレーのエンジニアやデザイナーは、きっちりと法令やガイドラインを守りつつ、その概念をプロダクトの設計に落しこみ、出来るだけ早く PDCA を回し、早く確実に実装することを目指しています。Developers Summit 2019 Summer のような多種多様なキャリアの方々が来場するイベントで、このようなお話をさせていただいたのはとても有意義だったと感じています。 セッションが無事終了し、ほっと一息付きながらメドレーロゴと一緒に ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

はじめに こんにちは。開発本部の阪本です。 今回は私が社内勉強会(TechLunch)にて Amazon Redshift(以下 Redshift)についてお話した内容を紹介させていただきます。 Redshift とは 概要 Redshift とは AWS サービスが提供しているデータウェアハウスで、高可用/高パフォーマンス/柔軟なスケーラビリティを実現しているのが特徴です。 競合としては BigQuery や Hadoop 、また同じ AWS サービスでは Amazon Athena も同様の位置付けになると思います。 データベースとしての特徴 Redshift の特徴として、列志向型データベースという点があります。 MySQL のようなリレーショナルデータベースはデータを行（レコード）単位で保持している事に対し、Redshift は列単位で保持しています。 列単位でデータを持っているため集計クエリのような特定の列に対して大量の行を精査するのが高速である反面、行を特定してのアクセスは MySQL や PostgreSQL のような行志向のデータベースに比べてのクエリに比べて遅い傾向にあります。 またデータには SQL でアクセスすることができ、構文も PostgreSQL と互換性があります。 最近スキーマレスなデータベースなどが多く出てきていますが、Redshift は事前にテーブルを作成する必要のある従来型の RDBMS の形となっており、テーブル作成時は CREATE TABLE といったデータ定義言語(DDL)を使うことになります。 機能面の特徴 先にも書きましたが、データアクセス時に使う SQL は PostgreSQL の構文と互換性があります。 よって PostgreSQL 用ドライバ(JDBC 含む)さえ使えれば、後は特別に意識することなく Redshift に対して接続やクエリ発行が行えるということになります。 この恩恵はプログラムだけではなく他社が展開しているサービスにも受けることができ、BI ツールの Tableau や Redash などもそのままデータソースとして利用することが出来ます。 次に、一般的な RDBMS との差についてです。 RDBMS にはあり Redshift には無いものとしては UNIQUE 制約 外部キー制約 インデックスが無い などがあります。 インデックスに関しては遠い意味での代用品(Sort Key)があるものの、基本的には使うことが出来ません。 注意点としてクエリ自体は PostgreSQL 互換なのでこれらを作る DDL 構文を受け入れてくれるますが、Redshift では無視されますのでご注意ください。 逆に、Redshift 固有のものとしては Sort Key 分散キー 列圧縮 などがあります。 これらについては以下で少し掘り下げて説明します。 Sort Key テーブルをソートする際に使うインデックスのようなものです。 列単位で指定することができ、 ORDER BY や GROUP BY 句などの精査速度に影響します。 分散キー MySQL でいうパーティショニングキーに近いものとなります。 Redshift のデータ分散方法は 均等に分散 キー値による分散 全コピー Auto（負荷状況による自動選択) の 4 つで、データ量や特性によって使い分けることが出来ます。 分散キーは Redshift を上記の方法でクラスタリングした際に、どのノードにどのデータを保持するかを決定する判断材料となるキーです。 運用面の特徴 AWS コンソール Redshift は AWS コンソール上からも詳細な情報を確認することが出来ます。 Amazon RDS にあるような一般的なメトリクスに加えてクエリ単位での実行状況や実行計画、そしてクエリの強制停止もコンソールから実行することができます。 データ取り込み Redshift はインポート元となるデータ取り込み選択肢が豊富ということも特徴の一つです。 取り込み可能な形式 CSV/JSON/AVRO/PARQUET/ORC + これらの形式を圧縮したもの(BZIP,GZIP など) 読み取り元 Amazon S3 / Amazon EMR / Amazon DynamoDB など 特にデータ配置元として S3 がサポートされているので、各種サービスが出力するログや、 Amazon CloudWatch Logs からの S3 や Amazon Kinesis Data Firehose からの S3 ・・など、組み合わせ次第で可能性がとても広がります。 また S3 に配置しているデータはインポートせずに外部テーブルとして直接クエリを実行する機能 Amazon Redshift Spectrum があります。データ量がとても多い場合などにはこちらを利用するのも有効な手段です。 ワークロード管理 負荷に関する運用については WLM(Work Load Management)という機能があります。 これは Redshift に接続するユーザをグループ単位で負荷制御を行うことが出来る機能です。 制御できる項目としては 並列クエリ実行数 同一グループ内でのクエリ同時実行数。上限に達すると待ち行列に入って詰まる。 クエリ実行時間 クエリ実行時間の上限。 メモリ使用量 クエリ実行時に使うメモリ使用量の上限。 などがあります。 可用性について Redshift はクラスタリングをサポートしており、クラスタにはクエリの待受を行うリーダー(Leader)ノードと実処理を行うコンピューティングノードが作成されます。 AWS も推奨しているように、Redshift はマルチノード運用を基本としています。 これは Redshift の個々のデータノードは RAID5 のような形で各ノードに分散しているため、ノード障害が発生した場合でも生存ノードからノード復旧を自動で行ってくれます。 （同時に障害が発生しても復旧可能なノード数については、クラスタ内のノード数に依存します） 将来性について 過去１年半の間でもこれだけの新機能が追加されており、まだまだ進化しています。 UNLOAD コマンドの CSV 対応 Concurrency Scaling ALTER 文で VARCHAR の桁数変更 Elastic Resize UNLOAD コマンドのヘッダ行出力対応 コンソールにてクエリ実行環境追加 ネスト化されたデータのサポート 自動バージョンアップ方式の設定／予告確認可能 Parquet、ORC からの IMPORT サポート Amazon Redshift Spectrum 東京サポート 新ノードタイプ DC2 Query Editor の追加 PL/SQL プロシージャのサポート Vacum コマンドの自動化 New!!(2018/12 リリース) WLM ワークロード管理の自動化 New!!(2019/06 リリース) 実際の使い勝手 では、実際のところ Redshift の使い勝手がどういったものなのかを実例を含めて紹介します。 ここでは dc2.large ノード数 2 のサンプル環境を使用します。 データのロード クエリを発行するにも、まずは元になるデータが必要です。 ここでは 日本語 Wikipedia の目次ダンプデータ を 100 セット分用意し、その内容を Redshift にロードしてみます。 まずは目次データをこちらの画像の様に加工し、100 セット分のファイルとして分割し S3 へとアップロードします。 今回のロードするデータ量は 235,732,000 レコードの 11.9GB となりました。 S3 にファイルが配置出来たら、それを格納するテーブルを Redshift に作ります。 この際 PostgreSQL の CREATE TABLE によってテーブルを作成します。 テーブルの作成が完了したら、次はデータのロードです。 これも SQL クエリの COPY コマンドによって取り込みが行われます。 今回このロード処理は 8 分 55 秒 で完了しました。 データ量から考えるとかなり早いと感じますが、これはロード処理において並列処理の恩恵を最大限に受けているということが理由と考えられます。 Redshift のロード処理は分割されたファイルを使って並列処理を実行するため、巨大な単一ファイルを取り込むより短時間で取り込むことができます。 クエリ発行 次に、クエリ発行についてですが、これはそのまま PostgreSQL のクエリを実行することになります。 今回は先のステップで取り込んだ目次ページをタイトルごとに DISTINCT する集計クエリを発行してみます。 すると 49 秒 で結果が帰ってきました。 最低限のスペックで 235,732,000 レコードを精査するクエリの実行時間としては良いスコアではないでしょうか。 不便に感じたこと ここでは私が Redshift を運用していて不便に感じた事をいくつか紹介します。 料金が高い これだけの機能とスペックが含まれているので仕方が無いかもしれませんが、AWS の他のサービスと比較して高価な印象があります。 さらにマルチノードとなると料金が掛け算で増えることになり、スペックの選択肢が他のサービスと比べても少ないため運用の際にはよく見積もりされることをおすすめします。 更新クエリが遅い 列志向型のせいなのかランダムアクセスが苦手で、特定の行を探して更新する UPDATE や DELETE は遅いです。 そもそも Redshift は頻繁に UPDATE / DELETE する用途には向いておらず（後述）、 INSERT のみの積み上げ型や全レコード洗い替えが基本の用途になります。 また、 UPDATE / DELETE を繰り返すとパフォーマンスが低下します。 これは内部的に保持している SortKey の状態が更新するたびに劣化し、連動してパフォーマンスが低下するためです。 解消するためには SortKey の再構築（ VACUM / OPTIMIZE コマンド)により回復しますが、そもそもコマンド実行時間が長く、負荷も大きいので実行タイミングは検討が必要となります。 (追記) 2018/12 の アップデート で自動実行機能が追加されました！ AWS コンソールが機能しないことがある 先に多くの便利な機能を紹介しましたが、なぜかこれらが AWS コンソール上で機能してくれないことが割とあります。 WLM の設定次第なのか不明ですが、実行中のクエリが出なかったりクエリの強制停止が効かないなど、イザという時に限って使えないことがよくありました。 メンテナンスが高頻度 新機能が続々追加されていると紹介していますが、この度にメンテナンスが発生するものとなります。 タイミングは事前に設定したメンテナンスウインドウの週一の曜日/時間帯ですが、経験から 2 週間に 1 度ぐらいの頻度で発生していました。 この時間帯は再起動を伴う場合もあるため、Write どころか Read すら出来ない状態になることもあります。 そのため日中は社内業務。夜間はバッチでといった２４時間ずっと稼働する要件を満たす事は少し厳しいものとなります。 まとめ まとめととなりますが、Redshift は特徴をふまえると下記のような場面で利用すれば良いかなと感じています。 BI ツール等のデータソースとして メンテ頻度や負荷の問題があるので、自分達のアプリから直接は繋げない。 履歴やマスタデータのような大量の積み上げ型データの集計 UPDATE が発生するなら、全件入れ替えが可能なデータ。 １日の利用頻度がそれなりにあること 頻度が高く無いのであれば、Athena の方が安い。 どのサービスにも言えることですが、要件の合ったサービス選びをすることが一番大事です。 Redshift についても特徴がはっきりしているタイプのサービスなので、使い所を間違えないように、上手く使っていければと思います。

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら https://www.medley.jp/team/

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部エンジニアの平木です。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどに、積極的に協賛させていただきたいと考えています。7 月以降のイベントも積極的にスポンサードさせていただきますので、ぜひ皆様にもお越しいただきたく、このエントリではメドレーが協賛するイベントの魅力をご紹介します。 Developers Summit 2019 Summer 公式サイト 2019/07/02(火) @ソラシティカンファレンスセンター ブロンズスポンサー 一番最初にご紹介するのは、ご存知 Developers Summit 2019 Summer(以降デブサミ夏)です。 本家である Developers Summit 2019 冬でも協賛させていただきましたが、今回のデブサミ夏ではブロンズスポンサーとして 執行役員である田中 が SI × Web の総合力で切り拓く新しいエンジニアのキャリアパス というタイトルでお話します。 ここ数年で X-Tech や DX の必要性が一気に叫ばれるようになってきましたが、メドレーでも 医療におけるデジタルトランスフォーメーションの推進 を目指して日々プロダクトの開発を進めています。X-Tech や DX を推進する上で、いわゆる「Web 系エンジニア」と「SI 系エンジニア」という垣根を越えた、ハイブリッドな新しいエンジニア像が求められるようになってきたと感じます。「課題を解決するために必要とされるようになったハイブリットな能力とは?」「これからのエンジニアはどう成長していくのがよいか?」ということをお話させていただきます。 おかげさまで、現時点でセッションは満員になっていますが、ぜひご覧いただければ幸いです。 CloudNativeDays Tokyo 2019 / OpenStack Days Tokyo 2019 公式サイト 2019/07/22(月) ~ 23(火) @虎ノ門ヒルズフォーラム ノベルティスポンサー(トートバッグ) 今年はイベントの統合もされ、名称も一新された日本最大級のコンテナ技術を始めとしたクラウドネイティブとオープンインフラの祭典である、こちらのイベントにも協賛させていただきます。 当日会場で配られるトートバッグに公式ロゴと共にメドレーのロゴを入れていただきました。実際にどんなデザインになるかは当日にご来場していただくまでのお楽しみとさせていただきますが、とても良いものになっているかと思います。 builderscon tokyo 2019 公式サイト 2019/08/29(木) ~ 31(土) @東京電機大学(東京千住キャンパス)1 号館 バックパネルスポンサー 2016 年から毎年開催されている、色々な分野のエンジニアの様々なセッションが一気に聞けるイベント「builderscon tokyo」ですが(去年は電子名札バッジがインパクトありましたね)、今年は初めてスポンサーとして参加させていただくことになりました。 会場である東京電機大学千住キャンパスの部屋の一つ、100 周年記念ホールでセッションするスピーカーさんの後ろに設置されるバックパネルのなかに、メドレーのロゴが入ることに。 こちらのイベントでは弊社エンジニアもお邪魔する予定ですので、会場でお気軽にお声がけしていただければと思います。 CODE BLUE 2019 公式サイト 2019/10/29(火) ~ 30(水) @ベルサール渋谷ガーデン ブロンズスポンサー 今年で 7 回目の開催となる情報セキュリティの国際会議「CODE BLUE 2019」に初めてスポンサーをさせていただいています。 メドレーでも取り扱っている情報の重要性から、会社としての取り組みで ISMS 認証 / ISMS クラウドセキュリティ認証を取得 していますが、このようなセキュリティに関するイベントにも業界の発展に少しでも寄与できればと今年から協賛させていただくことになりました。 DesginShip 2019 公式サイト 2019/11/23(土 ) ~ 24(日) @東京国際フォーラム B7 ・ B5 シルバースポンサー 去年から開催されているデザインカンファレンス「DesignShip 2019」に、去年から続きスポンサーをさせていただきます。 今年は会場も東京国際フォーラムになるということで、メドレーも去年よりもさらにアクティブな形でイベントに参加させていただくことになりそうです。 まとめ ここまでご紹介させていただいたイベント以外にも現在、スポンサーの打診をさせていただいているイベントがいくつかありますが、こちらも決定次第おしらせできればと考えています。 メドレーでは、技術や業界の発展に少しでも寄与できればという考えから、エンジニア・デザイナーの技術イベントなどにこれからも積極的に協賛させていただくスタンスを取っています。 全てのイベントに協賛できるわけではありませんが、スポンサーを探しているイベント運営者の方がいらっしゃいましたら、一度お気軽にお問い合わせいただければと思いますので、よろしくお願いします。 ▼ メドレーってどんな会社？気になった方はこちら メドレーで働く | 株式会社メドレー メドレーの組織文化や募集要項をご紹介します www.medley.jp

こんにちは。開発本部のエンジニアの鶴です。 今回は先月に行った社内の勉強会 TechLunch の内容をご紹介させていただきます。 イントロ Web サービスでは、ユーザーにアカウントを作ってもらい、ログインをしてサービスを利用してもらう、というユーザー認証を利用するサービスも多いかと思います。 Web サービスを開発する側としては、サービスごとに都度ユーザー認証の仕組みを構築する必要がありますが、セキュリティ対策の観点から考慮することが多く、地味に開発の工数がかかってしまいます。 また最近では、 Amazon Cognito や Firebase Authentication 、 Auth0 など、ユーザー認証サービスがいくつかリリースされ、ユーザー認証の機能をこれらの外部サービスに任せて開発の手間を省くという選択肢も取れるようになってきています。 自分自身、かつて担当したプロジェクトでユーザー認証の仕組みを Amazon Cognito にまかせてシステムを構築したことがありました。 しかし、当時は特にユーザープールの機能がリリースされて間もないこともあり、SDK の動作やサービスの仕様の理解にかなり手間取ったことを覚えています。 ユーザー認証サービスでは OpenID Connect という仕様に準拠していることが多いのですが、おそらく自分にとってこの仕様の理解が疎かだったことが原因の一つだったと思います。 そこで今回は、ユーザー認証と OpenID Connect の仕組みについて改めて勉強し直したので、その内容を簡単に解説をさせていただこうと思います。 ユーザー認証とは ユーザー認証の前に、そもそも認証とはどういう操作のことを指すのでしょうか。 みんな大好き Wikipedia 先生 によると、以下のような記載があります。 認証（にんしょう）とは、何かによって、対象の正当性を確認する行為を指す。 認証行為は認証対象よって分類され、認証対象が人間である場合には相手認証（本人認証）、メッセージである場合にはメッセージ認証、時刻の場合には時刻認証と呼ぶ。 単に認証と言った場合には相手認証を指す場合が多い。 ユーザー認証は Web サービスにとってリクエストを送信してきた相手の正当性を認証することなので、相手認証の 1 つですね。 さらに相手認証の認証方法として 2 通りの方法があります。 第 1 の方法は、被認証者が認証者に、秘密鍵をもっていることによって得られる何らかの能力の証明を行う方法である。第 2 の方法は、被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法である。 ユーザー認証の場合、多くはこの第 1 の方法での認証で、ログイン時にユーザー ID に加えて、この「秘密鍵」としてアカウント作成時に登録しておいたパスワードを入力することでユーザー認証を行っているかと思います。 Web サービスでのユーザー認証 Web サービスで扱う情報の秘匿性が高くなればなるほど、この「秘密鍵」が本当にそのユーザーにしか提供できない情報であることが求められます。 上述のようなパスワードによる認証の場合、パスワードが推測されるなどして悪意のある第三者にアカウントが乗っ取られてしまう事件はよく耳にします。 よりセキュリティを高めるため、パスワード以外の認証や多要素認証などを用いる事が増えてきました。 また、セキュリティの観点だけでなく利便性の観点からも、パスワード入力の代わりに指紋認証や顔認証によるログインや、あるいは各種 SNS アカウントによるログインも増えてきています。自社の複数のサービスを連携できるようユーザーに共通 ID を提供したい、といったケースもあるかもしれません。 最近ではパスワードレス認証や WebAuthn も注目されていますね。今回は紹介は割愛しますが、パスワードレス認証の一つである FIDO 認証 は、前述の「被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法」を利用した認証方式のようです。（ ref1 , ref2 ） このように、セキュリティの観点やユーザー利便性の観点などにより、Web サービスにおけるユーザー認証機能は 1 回作ったら終わりではなく、時流に応じて適宜改修する必要が出てくることもあるかと思います。 しかし、特にユーザー認証がメインのサービスと密結合している場合などでは、認証の前後など認証処理そのものだけでなくその周辺の処理への影響範囲も無視できない場合もあり、ユーザー認証の改修に工数が思ったよりかかってしまったり、対応が滞ってしまうこともあるかもしれません。 そんなとき、認証サービスをメインのサービスと切り離すことでより柔軟なユーザー認証手段を提供できるよう、OpenID Connect の導入を検討してみても良いかもしれません。 OpenID Connect とは OpenID Connect(以降、OIDC)について、本家サイトでは以下のように説明されています。 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のためにクレームを用いる認証機能を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する. （ 日本語 , 英語 ） 個人的には、メインのサービスと認証サービスを切り離して運用することを想定して仕様が規定されている点が重要と考えます。 OIDC を利用することで、ユーザー認証をより柔軟に改修したり新しい認証方法に対応したりすることがしやすくなることが期待されるからです。 なお、OIDC の仕様には認証手段自体（パスワード認証や多要素認証など）に関しては規定されておらず、あくまで認証サービスによる認証結果の取得方法や扱い方についてが規定されています。 また、様々なユースケースに対応できるよういくつかの処理フローやオプショナルな設定が提供されていますが、その反面セキュリティの確保は実装者に委ねられており、ユースケースに応じて適切な実装を行う必要があります。 前述したユーザー認証サービスである Amazon Cognito や FirebaseAuthentication などは、認証手段が標準でいくつか提供されており、加えてバックエンドと SDK に OIDC 固有のセキュアな実装が施されてあるため、開発者は最小限の設定だけでユーザー認証機能が利用できるようになります。便利ですね。 処理フローの解説 さて、OIDC の具体的な処理について解説していこうと思います。 まず登場人物です。 OpenID Provider（OP）：認証認可を行うサービス。ユーザー認証情報（識別子やパスワードなど）を管理したり、認証に関するユーザー属性情報（氏名やユーザー名など）を保持する。 RelyingParty（RP）： アクセス元のユーザーの認証とユーザー属性情報を要求するサービス。ユーザーからのリクエストに対し OP による認証結果を信頼（rely）してリソースへのアクセスを許可する（例えばマイページを表示するなど）。 EndUser：ログインをしてサービスを利用しようとしているユーザー。 基本的な用語も先に簡単に紹介しておきます。 クライアント ID：OpenID Provider で管理する、RelyingParty の識別情報。 クライアントシークレット：OpenID Provider が RelyingParty ごとに発行する秘密鍵。 認証コード：後述する AuthorizationCodeFlow で OpenID Provider が発行する短命のパスワードのようなもの。 ID トークン：OpenID Provider から発行される、ユーザーによる認証を行った証明情報。 JSON Web Token(JWT) で表現され、検証により改ざん検知することができる。認証の内容（OpenID Provider、ユーザー識別子、RelyingParty のクライアント ID、有効期限など）やユーザー属性情報が格納される。 アクセストークン:OpenID Provider が保持するユーザー属性情報に対しアクセスするための OAuth2 の認可トークン。 OIDC の処理フローは大きく分けて 3 種類が規定されています。 AuthorizationCodeFlow：認証成功時に OpenID Provider が RelyingParty に対し認証コードを発行し、RelyingParty はこれを用いて OpenID Provider から ID トークン等を取得する。RelyingParty がサーバーサイドアプリケーションで、OpenID Provider から発行されるクライアントシークレットを安全に管理することができる場合などに用いられる。 ImplicitFlow：認証コードを使わず認証結果のレスポンスで ID トークン等を取得する。RelyingParty がクライアントアプリケーションの場合など、クライアントシークレットが安全に管理できない場合などに用いられる。 HybridFlow：AuthorizationCodeFlow と ImplicitFlow の組み合わせ。 これらのフローの違いは以下の表のとおりです。 （ 公式より引用 ） 今回は、 公式 や こちらの解説記事 などを参照しながら、基本の処理フローである AuthorizationCodeFlow について解説します。 簡略化のため、イメージ重視で登場人物は「 ユーザー 」「（ユーザーにサービスを提供する） Web サービス 」「 認証サービス 」と表現することにします。 大まかには以下のステップで処理が行われます。 ユーザー からのアクセスに対し、 Web サービス は 認証サービス にユーザー認証を要求する 認証サービス はユーザー認証を行い、認証コードを発行して、 ユーザー を Web サービス にリダイレクトさせる Web サービス は 2 で取得した認証コードを用いて 認証サービス に ID トークン等をリクエストする Web サービス は 3 で取得した ID トークンを検証し、 ユーザー の識別子を取得する Step.0 : 事前準備 あらかじめ Web サービス は 認証サービス からクライアント ID とクライアントシークレットを取得し保持しておきます。 Step.1: ユーザー認証の要求 ユーザー が Web サービス に対し一般的なログインの流れでログインを要求すると、 Web サービス は 認証サービス にリクエストをリダイレクトします。 Web サービス から 認証サービス へのリダイレクトの URL は以下のような感じです。 HTTP / 1.1 302 Found Location: https://server.example.com/authorize? response_type=code & client_id = s6BhdRkqt3 & redirect_uri = https%3A%2F%2Fclient.example.org%2Fcb & scope = openid%20profile & state = af0ifjsldkj response_type で OIDC のどの認証フローを使うかを指定します。 redirect_uri は、 認証サービス での認証が成功したときの Web サービス にコールバックする URL です。これは事前に認証サービスに登録しておく必要があります。 scope には認証の内容を設定します。openid は必須で、他には OAuth2 のアクセストークンを使って取得できるユーザー属性情報を指定します。 scope で指定できるユーザー属性情報は以下のとおりです。 （ 公式より引用 ） ユーザーの認証でよく使われそうな「氏名」や「メールアドレス」など基本的な属性情報が定義されています。 state は CSRF 対策などのためのランダム値です。認証フローを開始するたびに Web サービス が発行し、リクエストとコールバックの間で値が維持されます。 他にもいくつかのパラメータ（nonce など）が定義されており、必要に応じて利用します。 Step.2: ユーザー認証と認証コードの発行 認証サービス では認証手段に応じてログイン ID ・パスワードの入力フォームなどを表示し、 ユーザー から認証情報を取得して認証処理を行います。 認証サービス はユーザーの認証に成功すると、認証コードを発行し、 ユーザー を Web サービス にリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA & state = af0ifjsldkj リダイレクト先について、 認証サービス は Step.1 で受け取った redirect url を 認証サービス に予め登録されている URL と合致することを検証する必要があります。_Web サービス のなりすましを防ぐためです。 また Web サービス 側で 認証サービス からのレスポンスであることを確認できるよう、state もパラメータに含めます。 なお、認証に失敗した場合は下記のように認証エラーした内容をパラメーターに加えて Web サービスにリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? error=invalid_request & error_description = Unsupported%20response_type%20value & state = af0ifjsldkj Step.3: 認証結果の取得 Step.2 で Web サービス は 認証サービス からのリダイレクトを受け、認証コードを取得すると、この認証コードを利用して 認証サービス に対して認証結果情報（ID トークンなど）を取得します。 Web サービス から 認証サービス への認証結果取得リクエストは以下のような形式になります。 POST /token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA & redirect_uri = https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 認証コードを送信する必要があるため、POST メソッドでリクエストします。またクライアント ID とクライアントシークレットによる BASIC 認証を行います。 このリクエストでクライアントシークレットが必要になるのですが、これは 認証サービス にとって Web サービス の正当性を検証するための重要なパラメータであり、安全に管理される必要があります。 SinglePageApplication のようにユーザー側にあるアプリケーションで OIDC を処理する場合には、このクライアントシークレットが安全に管理される保証がないため、AuthenticationCodeFlow ではなく ImplicitFlow などを利用する必要があります。 Web サービス からのリクエストを受け取った 認証サービス は grant_type に Step.1 で指定した処理フローに該当する情報を渡し、認証コード（ code ）と合わせて 認証サービス にリクエストの検証をさせます。 認証サービス はリクエストの検証に成功すると、 Web サービス に対し認証結果として ID トークン等を返却します。 HTTP / 1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store Pragma: no-cache { "access_token" : "SlAV32hkKG" , "token_type" : "Bearer" , "expires_in" : 3600 , "refresh_token" : "tGzv3JOkF0XG5Qx2TlKWIA" , "id_token" : "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" } access_token は 認証サービス で管理しているユーザー属性情報を取得するための OAuth2 トークンです。 refresh_token は 認証サービス から access_token を再発行する際に利用します。 Step.4: 認証結果の検証 Web サービス は 認証サービス*から取得した ID トークンを検証します。ID トークンは前述の通り JWT で表現されており、*認証サービス_の公開鍵を用いて検証することができます。 手順は こちら をご確認ください。他にも参考リンクを紹介しておきます。 https://qiita.com/bobunderson/items/d48f89e2b3e6ad9f9c4c https://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06 下記は ID トークンに含まれる認証情報の例です。 { "iss" : "https://server.example.com" , "sub" : "24400320" , "aud" : "s6BhdRkqt3" , "exp" : 1311281970 , "iat" : 1311280970 } このうち sub が 認証サービス で管理されている ユーザー の識別子です。 iss は 認証サービス 、aud は Web サービス のクライアント ID になります。 exp、iat はそれぞれ認証の有効期限と認証したタイムスタンプです。 Web サービス は ID トークンが正しい内容であることが確認できれば、これをログインセッションと紐づけて保管します。 以上で認証処理は完了です。 ユーザー属性情報の取得 ユーザー認証後、 Web サービス がユーザー名などのユーザー属性情報が必要になった場合、Step.3 で取得した access_token を利用し 認証サービス に対してユーザー属性情報をリクエストします。 GET /userinfo HTTP / 1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG このリクエストにより、Step.1 の scope で指定したユーザー属性情報が取得できます。 まとめ 以上少し長くなりましたが、ユーザー認証と OpenID Connect、特に基本の AuthenticationCodeFlow について解説しました。限られた発表時間の中での解説のため厳密さより雰囲気を重視した内容となりましたが、お気づきの点などあればお知らせいただければと思います。 サービスの要件やフェーズによって OIDC を取り入れるかどうかは様々ですが、ユーザー認証の実装を自前で実装、メンテナンスしていくだけでなく、Amazon Cognito などの便利な認証サービスを利用していくことも選択肢の一つとして検討してみても良いかもしれません。 そしてそれら便利な認証サービスをうまく使いこなすためにも、その背景にある OIDC の仕様や思想、そもそも認証の仕組みについて立ち返ってみると、理解が一段と深まるかとおもいます。 www.medley.jp www.medley.jp

こんにちは。開発本部のエンジニアの鶴です。 今回は先月に行った社内の勉強会 TechLunch の内容をご紹介させていただきます。 イントロ Web サービスでは、ユーザーにアカウントを作ってもらい、ログインをしてサービスを利用してもらう、というユーザー認証を利用するサービスも多いかと思います。 Web サービスを開発する側としては、サービスごとに都度ユーザー認証の仕組みを構築する必要がありますが、セキュリティ対策の観点から考慮することが多く、地味に開発の工数がかかってしまいます。 また最近では、 Amazon Cognito や Firebase Authentication 、 Auth0 など、ユーザー認証サービスがいくつかリリースされ、ユーザー認証の機能をこれらの外部サービスに任せて開発の手間を省くという選択肢も取れるようになってきています。 自分自身、かつて担当したプロジェクトでユーザー認証の仕組みを Amazon Cognito にまかせてシステムを構築したことがありました。 しかし、当時は特にユーザープールの機能がリリースされて間もないこともあり、SDK の動作やサービスの仕様の理解にかなり手間取ったことを覚えています。 ユーザー認証サービスでは OpenID Connect という仕様に準拠していることが多いのですが、おそらく自分にとってこの仕様の理解が疎かだったことが原因の一つだったと思います。 そこで今回は、ユーザー認証と OpenID Connect の仕組みについて改めて勉強し直したので、その内容を簡単に解説をさせていただこうと思います。 ユーザー認証とは ユーザー認証の前に、そもそも認証とはどういう操作のことを指すのでしょうか。 みんな大好き Wikipedia 先生 によると、以下のような記載があります。 認証（にんしょう）とは、何かによって、対象の正当性を確認する行為を指す。 認証行為は認証対象よって分類され、認証対象が人間である場合には相手認証（本人認証）、メッセージである場合にはメッセージ認証、時刻の場合には時刻認証と呼ぶ。 単に認証と言った場合には相手認証を指す場合が多い。 ユーザー認証は Web サービスにとってリクエストを送信してきた相手の正当性を認証することなので、相手認証の 1 つですね。 さらに相手認証の認証方法として 2 通りの方法があります。 第 1 の方法は、被認証者が認証者に、秘密鍵をもっていることによって得られる何らかの能力の証明を行う方法である。第 2 の方法は、被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法である。 ユーザー認証の場合、多くはこの第 1 の方法での認証で、ログイン時にユーザー ID に加えて、この「秘密鍵」としてアカウント作成時に登録しておいたパスワードを入力することでユーザー認証を行っているかと思います。 Web サービスでのユーザー認証 Web サービスで扱う情報の秘匿性が高くなればなるほど、この「秘密鍵」が本当にそのユーザーにしか提供できない情報であることが求められます。 上述のようなパスワードによる認証の場合、パスワードが推測されるなどして悪意のある第三者にアカウントが乗っ取られてしまう事件はよく耳にします。 よりセキュリティを高めるため、パスワード以外の認証や多要素認証などを用いる事が増えてきました。 また、セキュリティの観点だけでなく利便性の観点からも、パスワード入力の代わりに指紋認証や顔認証によるログインや、あるいは各種 SNS アカウントによるログインも増えてきています。自社の複数のサービスを連携できるようユーザーに共通 ID を提供したい、といったケースもあるかもしれません。 最近ではパスワードレス認証や WebAuthn も注目されていますね。今回は紹介は割愛しますが、パスワードレス認証の一つである FIDO 認証 は、前述の「被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法」を利用した認証方式のようです。（ ref1 , ref2 ） このように、セキュリティの観点やユーザー利便性の観点などにより、Web サービスにおけるユーザー認証機能は 1 回作ったら終わりではなく、時流に応じて適宜改修する必要が出てくることもあるかと思います。 しかし、特にユーザー認証がメインのサービスと密結合している場合などでは、認証の前後など認証処理そのものだけでなくその周辺の処理への影響範囲も無視できない場合もあり、ユーザー認証の改修に工数が思ったよりかかってしまったり、対応が滞ってしまうこともあるかもしれません。 そんなとき、認証サービスをメインのサービスと切り離すことでより柔軟なユーザー認証手段を提供できるよう、OpenID Connect の導入を検討してみても良いかもしれません。 OpenID Connect とは OpenID Connect(以降、OIDC)について、本家サイトでは以下のように説明されています。 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のためにクレームを用いる認証機能を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する. （ 日本語 , 英語 ） 個人的には、メインのサービスと認証サービスを切り離して運用することを想定して仕様が規定されている点が重要と考えます。 OIDC を利用することで、ユーザー認証をより柔軟に改修したり新しい認証方法に対応したりすることがしやすくなることが期待されるからです。 なお、OIDC の仕様には認証手段自体（パスワード認証や多要素認証など）に関しては規定されておらず、あくまで認証サービスによる認証結果の取得方法や扱い方についてが規定されています。 また、様々なユースケースに対応できるよういくつかの処理フローやオプショナルな設定が提供されていますが、その反面セキュリティの確保は実装者に委ねられており、ユースケースに応じて適切な実装を行う必要があります。 前述したユーザー認証サービスである Amazon Cognito や FirebaseAuthentication などは、認証手段が標準でいくつか提供されており、加えてバックエンドと SDK に OIDC 固有のセキュアな実装が施されてあるため、開発者は最小限の設定だけでユーザー認証機能が利用できるようになります。便利ですね。 処理フローの解説 さて、OIDC の具体的な処理について解説していこうと思います。 まず登場人物です。 OpenID Provider（OP）：認証認可を行うサービス。ユーザー認証情報（識別子やパスワードなど）を管理したり、認証に関するユーザー属性情報（氏名やユーザー名など）を保持する。 RelyingParty（RP）： アクセス元のユーザーの認証とユーザー属性情報を要求するサービス。ユーザーからのリクエストに対し OP による認証結果を信頼（rely）してリソースへのアクセスを許可する（例えばマイページを表示するなど）。 EndUser：ログインをしてサービスを利用しようとしているユーザー。 基本的な用語も先に簡単に紹介しておきます。 クライアント ID：OpenID Provider で管理する、RelyingParty の識別情報。 クライアントシークレット：OpenID Provider が RelyingParty ごとに発行する秘密鍵。 認証コード：後述する AuthorizationCodeFlow で OpenID Provider が発行する短命のパスワードのようなもの。 ID トークン：OpenID Provider から発行される、ユーザーによる認証を行った証明情報。 JSON Web Token(JWT) で表現され、検証により改ざん検知することができる。認証の内容（OpenID Provider、ユーザー識別子、RelyingParty のクライアント ID、有効期限など）やユーザー属性情報が格納される。 アクセストークン:OpenID Provider が保持するユーザー属性情報に対しアクセスするための OAuth2 の認可トークン。 OIDC の処理フローは大きく分けて 3 種類が規定されています。 AuthorizationCodeFlow：認証成功時に OpenID Provider が RelyingParty に対し認証コードを発行し、RelyingParty はこれを用いて OpenID Provider から ID トークン等を取得する。RelyingParty がサーバーサイドアプリケーションで、OpenID Provider から発行されるクライアントシークレットを安全に管理することができる場合などに用いられる。 ImplicitFlow：認証コードを使わず認証結果のレスポンスで ID トークン等を取得する。RelyingParty がクライアントアプリケーションの場合など、クライアントシークレットが安全に管理できない場合などに用いられる。 HybridFlow：AuthorizationCodeFlow と ImplicitFlow の組み合わせ。 これらのフローの違いは以下の表のとおりです。 （ 公式より引用 ） 今回は、 公式 や こちらの解説記事 などを参照しながら、基本の処理フローである AuthorizationCodeFlow について解説します。 簡略化のため、イメージ重視で登場人物は「 ユーザー 」「（ユーザーにサービスを提供する） Web サービス 」「 認証サービス 」と表現することにします。 大まかには以下のステップで処理が行われます。 ユーザー からのアクセスに対し、 Web サービス は 認証サービス にユーザー認証を要求する 認証サービス はユーザー認証を行い、認証コードを発行して、 ユーザー を Web サービス にリダイレクトさせる Web サービス は 2 で取得した認証コードを用いて 認証サービス に ID トークン等をリクエストする Web サービス は 3 で取得した ID トークンを検証し、 ユーザー の識別子を取得する Step.0 : 事前準備 あらかじめ Web サービス は 認証サービス からクライアント ID とクライアントシークレットを取得し保持しておきます。 Step.1: ユーザー認証の要求 ユーザー が Web サービス に対し一般的なログインの流れでログインを要求すると、 Web サービス は 認証サービス にリクエストをリダイレクトします。 Web サービス から 認証サービス へのリダイレクトの URL は以下のような感じです。 HTTP / 1.1 302 Found Location: https://server.example.com/authorize? response_type=code & client_id = s6BhdRkqt3 & redirect_uri = https%3A%2F%2Fclient.example.org%2Fcb & scope = openid%20profile & state = af0ifjsldkj response_type で OIDC のどの認証フローを使うかを指定します。 redirect_uri は、 認証サービス での認証が成功したときの Web サービス にコールバックする URL です。これは事前に認証サービスに登録しておく必要があります。 scope には認証の内容を設定します。openid は必須で、他には OAuth2 のアクセストークンを使って取得できるユーザー属性情報を指定します。 scope で指定できるユーザー属性情報は以下のとおりです。 （ 公式より引用 ） ユーザーの認証でよく使われそうな「氏名」や「メールアドレス」など基本的な属性情報が定義されています。 state は CSRF 対策などのためのランダム値です。認証フローを開始するたびに Web サービス が発行し、リクエストとコールバックの間で値が維持されます。 他にもいくつかのパラメータ（nonce など）が定義されており、必要に応じて利用します。 Step.2: ユーザー認証と認証コードの発行 認証サービス では認証手段に応じてログイン ID ・パスワードの入力フォームなどを表示し、 ユーザー から認証情報を取得して認証処理を行います。 認証サービス はユーザーの認証に成功すると、認証コードを発行し、 ユーザー を Web サービス にリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA & state = af0ifjsldkj リダイレクト先について、 認証サービス は Step.1 で受け取った redirect url を 認証サービス に予め登録されている URL と合致することを検証する必要があります。_Web サービス のなりすましを防ぐためです。 また Web サービス 側で 認証サービス からのレスポンスであることを確認できるよう、state もパラメータに含めます。 なお、認証に失敗した場合は下記のように認証エラーした内容をパラメーターに加えて Web サービスにリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? error=invalid_request & error_description = Unsupported%20response_type%20value & state = af0ifjsldkj Step.3: 認証結果の取得 Step.2 で Web サービス は 認証サービス からのリダイレクトを受け、認証コードを取得すると、この認証コードを利用して 認証サービス に対して認証結果情報（ID トークンなど）を取得します。 Web サービス から 認証サービス への認証結果取得リクエストは以下のような形式になります。 POST /token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA & redirect_uri = https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 認証コードを送信する必要があるため、POST メソッドでリクエストします。またクライアント ID とクライアントシークレットによる BASIC 認証を行います。 このリクエストでクライアントシークレットが必要になるのですが、これは 認証サービス にとって Web サービス の正当性を検証するための重要なパラメータであり、安全に管理される必要があります。 SinglePageApplication のようにユーザー側にあるアプリケーションで OIDC を処理する場合には、このクライアントシークレットが安全に管理される保証がないため、AuthenticationCodeFlow ではなく ImplicitFlow などを利用する必要があります。 Web サービス からのリクエストを受け取った 認証サービス は grant_type に Step.1 で指定した処理フローに該当する情報を渡し、認証コード（ code ）と合わせて 認証サービス にリクエストの検証をさせます。 認証サービス はリクエストの検証に成功すると、 Web サービス に対し認証結果として ID トークン等を返却します。 HTTP / 1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store Pragma: no-cache { "access_token" : "SlAV32hkKG" , "token_type" : "Bearer" , "expires_in" : 3600 , "refresh_token" : "tGzv3JOkF0XG5Qx2TlKWIA" , "id_token" : "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" } access_token は 認証サービス で管理しているユーザー属性情報を取得するための OAuth2 トークンです。 refresh_token は 認証サービス から access_token を再発行する際に利用します。 Step.4: 認証結果の検証 Web サービス は 認証サービス*から取得した ID トークンを検証します。ID トークンは前述の通り JWT で表現されており、*認証サービス_の公開鍵を用いて検証することができます。 手順は こちら をご確認ください。他にも参考リンクを紹介しておきます。 https://qiita.com/bobunderson/items/d48f89e2b3e6ad9f9c4c https://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06 下記は ID トークンに含まれる認証情報の例です。 { "iss" : "https://server.example.com" , "sub" : "24400320" , "aud" : "s6BhdRkqt3" , "exp" : 1311281970 , "iat" : 1311280970 } このうち sub が 認証サービス で管理されている ユーザー の識別子です。 iss は 認証サービス 、aud は Web サービス のクライアント ID になります。 exp、iat はそれぞれ認証の有効期限と認証したタイムスタンプです。 Web サービス は ID トークンが正しい内容であることが確認できれば、これをログインセッションと紐づけて保管します。 以上で認証処理は完了です。 ユーザー属性情報の取得 ユーザー認証後、 Web サービス がユーザー名などのユーザー属性情報が必要になった場合、Step.3 で取得した access_token を利用し 認証サービス に対してユーザー属性情報をリクエストします。 GET /userinfo HTTP / 1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG このリクエストにより、Step.1 の scope で指定したユーザー属性情報が取得できます。 まとめ 以上少し長くなりましたが、ユーザー認証と OpenID Connect、特に基本の AuthenticationCodeFlow について解説しました。限られた発表時間の中での解説のため厳密さより雰囲気を重視した内容となりましたが、お気づきの点などあればお知らせいただければと思います。 サービスの要件やフェーズによって OIDC を取り入れるかどうかは様々ですが、ユーザー認証の実装を自前で実装、メンテナンスしていくだけでなく、Amazon Cognito などの便利な認証サービスを利用していくことも選択肢の一つとして検討してみても良いかもしれません。 そしてそれら便利な認証サービスをうまく使いこなすためにも、その背景にある OIDC の仕様や思想、そもそも認証の仕組みについて立ち返ってみると、理解が一段と深まるかとおもいます。 www.medley.jp www.medley.jp

こんにちは。開発本部のエンジニアの鶴です。 今回は先月に行った社内の勉強会 TechLunch の内容をご紹介させていただきます。 イントロ Web サービスでは、ユーザーにアカウントを作ってもらい、ログインをしてサービスを利用してもらう、というユーザー認証を利用するサービスも多いかと思います。 Web サービスを開発する側としては、サービスごとに都度ユーザー認証の仕組みを構築する必要がありますが、セキュリティ対策の観点から考慮することが多く、地味に開発の工数がかかってしまいます。 また最近では、 Amazon Cognito や Firebase Authentication 、 Auth0 など、ユーザー認証サービスがいくつかリリースされ、ユーザー認証の機能をこれらの外部サービスに任せて開発の手間を省くという選択肢も取れるようになってきています。 自分自身、かつて担当したプロジェクトでユーザー認証の仕組みを Amazon Cognito にまかせてシステムを構築したことがありました。 しかし、当時は特にユーザープールの機能がリリースされて間もないこともあり、SDK の動作やサービスの仕様の理解にかなり手間取ったことを覚えています。 ユーザー認証サービスでは OpenID Connect という仕様に準拠していることが多いのですが、おそらく自分にとってこの仕様の理解が疎かだったことが原因の一つだったと思います。 そこで今回は、ユーザー認証と OpenID Connect の仕組みについて改めて勉強し直したので、その内容を簡単に解説をさせていただこうと思います。 ユーザー認証とは ユーザー認証の前に、そもそも認証とはどういう操作のことを指すのでしょうか。 みんな大好き Wikipedia 先生 によると、以下のような記載があります。 認証（にんしょう）とは、何かによって、対象の正当性を確認する行為を指す。 認証行為は認証対象よって分類され、認証対象が人間である場合には相手認証（本人認証）、メッセージである場合にはメッセージ認証、時刻の場合には時刻認証と呼ぶ。 単に認証と言った場合には相手認証を指す場合が多い。 ユーザー認証は Web サービスにとってリクエストを送信してきた相手の正当性を認証することなので、相手認証の 1 つですね。 さらに相手認証の認証方法として 2 通りの方法があります。 第 1 の方法は、被認証者が認証者に、秘密鍵をもっていることによって得られる何らかの能力の証明を行う方法である。第 2 の方法は、被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法である。 ユーザー認証の場合、多くはこの第 1 の方法での認証で、ログイン時にユーザー ID に加えて、この「秘密鍵」としてアカウント作成時に登録しておいたパスワードを入力することでユーザー認証を行っているかと思います。 Web サービスでのユーザー認証 Web サービスで扱う情報の秘匿性が高くなればなるほど、この「秘密鍵」が本当にそのユーザーにしか提供できない情報であることが求められます。 上述のようなパスワードによる認証の場合、パスワードが推測されるなどして悪意のある第三者にアカウントが乗っ取られてしまう事件はよく耳にします。 よりセキュリティを高めるため、パスワード以外の認証や多要素認証などを用いる事が増えてきました。 また、セキュリティの観点だけでなく利便性の観点からも、パスワード入力の代わりに指紋認証や顔認証によるログインや、あるいは各種 SNS アカウントによるログインも増えてきています。自社の複数のサービスを連携できるようユーザーに共通 ID を提供したい、といったケースもあるかもしれません。 最近ではパスワードレス認証や WebAuthn も注目されていますね。今回は紹介は割愛しますが、パスワードレス認証の一つである FIDO 認証 は、前述の「被認証者が認証者に、被認証者の公開鍵に対応する秘密鍵の知識の証明を行う方法」を利用した認証方式のようです。（ ref1 , ref2 ） このように、セキュリティの観点やユーザー利便性の観点などにより、Web サービスにおけるユーザー認証機能は 1 回作ったら終わりではなく、時流に応じて適宜改修する必要が出てくることもあるかと思います。 しかし、特にユーザー認証がメインのサービスと密結合している場合などでは、認証の前後など認証処理そのものだけでなくその周辺の処理への影響範囲も無視できない場合もあり、ユーザー認証の改修に工数が思ったよりかかってしまったり、対応が滞ってしまうこともあるかもしれません。 そんなとき、認証サービスをメインのサービスと切り離すことでより柔軟なユーザー認証手段を提供できるよう、OpenID Connect の導入を検討してみても良いかもしれません。 OpenID Connect とは OpenID Connect(以降、OIDC)について、本家サイトでは以下のように説明されています。 OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のためにクレームを用いる認証機能を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する. （ 日本語 , 英語 ） 個人的には、メインのサービスと認証サービスを切り離して運用することを想定して仕様が規定されている点が重要と考えます。 OIDC を利用することで、ユーザー認証をより柔軟に改修したり新しい認証方法に対応したりすることがしやすくなることが期待されるからです。 なお、OIDC の仕様には認証手段自体（パスワード認証や多要素認証など）に関しては規定されておらず、あくまで認証サービスによる認証結果の取得方法や扱い方についてが規定されています。 また、様々なユースケースに対応できるよういくつかの処理フローやオプショナルな設定が提供されていますが、その反面セキュリティの確保は実装者に委ねられており、ユースケースに応じて適切な実装を行う必要があります。 前述したユーザー認証サービスである Amazon Cognito や FirebaseAuthentication などは、認証手段が標準でいくつか提供されており、加えてバックエンドと SDK に OIDC 固有のセキュアな実装が施されてあるため、開発者は最小限の設定だけでユーザー認証機能が利用できるようになります。便利ですね。 処理フローの解説 さて、OIDC の具体的な処理について解説していこうと思います。 まず登場人物です。 OpenID Provider（OP）：認証認可を行うサービス。ユーザー認証情報（識別子やパスワードなど）を管理したり、認証に関するユーザー属性情報（氏名やユーザー名など）を保持する。 RelyingParty（RP）： アクセス元のユーザーの認証とユーザー属性情報を要求するサービス。ユーザーからのリクエストに対し OP による認証結果を信頼（rely）してリソースへのアクセスを許可する（例えばマイページを表示するなど）。 EndUser：ログインをしてサービスを利用しようとしているユーザー。 基本的な用語も先に簡単に紹介しておきます。 クライアント ID：OpenID Provider で管理する、RelyingParty の識別情報。 クライアントシークレット：OpenID Provider が RelyingParty ごとに発行する秘密鍵。 認証コード：後述する AuthorizationCodeFlow で OpenID Provider が発行する短命のパスワードのようなもの。 ID トークン：OpenID Provider から発行される、ユーザーによる認証を行った証明情報。 JSON Web Token(JWT) で表現され、検証により改ざん検知することができる。認証の内容（OpenID Provider、ユーザー識別子、RelyingParty のクライアント ID、有効期限など）やユーザー属性情報が格納される。 アクセストークン:OpenID Provider が保持するユーザー属性情報に対しアクセスするための OAuth2 の認可トークン。 OIDC の処理フローは大きく分けて 3 種類が規定されています。 AuthorizationCodeFlow：認証成功時に OpenID Provider が RelyingParty に対し認証コードを発行し、RelyingParty はこれを用いて OpenID Provider から ID トークン等を取得する。RelyingParty がサーバーサイドアプリケーションで、OpenID Provider から発行されるクライアントシークレットを安全に管理することができる場合などに用いられる。 ImplicitFlow：認証コードを使わず認証結果のレスポンスで ID トークン等を取得する。RelyingParty がクライアントアプリケーションの場合など、クライアントシークレットが安全に管理できない場合などに用いられる。 HybridFlow：AuthorizationCodeFlow と ImplicitFlow の組み合わせ。 これらのフローの違いは以下の表のとおりです。 （ 公式より引用 ） 今回は、 公式 や こちらの解説記事 などを参照しながら、基本の処理フローである AuthorizationCodeFlow について解説します。 簡略化のため、イメージ重視で登場人物は「 ユーザー 」「（ユーザーにサービスを提供する） Web サービス 」「 認証サービス 」と表現することにします。 大まかには以下のステップで処理が行われます。 ユーザー からのアクセスに対し、 Web サービス は 認証サービス にユーザー認証を要求する 認証サービス はユーザー認証を行い、認証コードを発行して、 ユーザー を Web サービス にリダイレクトさせる Web サービス は 2 で取得した認証コードを用いて 認証サービス に ID トークン等をリクエストする Web サービス は 3 で取得した ID トークンを検証し、 ユーザー の識別子を取得する Step.0 : 事前準備 あらかじめ Web サービス は 認証サービス からクライアント ID とクライアントシークレットを取得し保持しておきます。 Step.1: ユーザー認証の要求 ユーザー が Web サービス に対し一般的なログインの流れでログインを要求すると、 Web サービス は 認証サービス にリクエストをリダイレクトします。 Web サービス から 認証サービス へのリダイレクトの URL は以下のような感じです。 HTTP / 1.1 302 Found Location: https://server.example.com/authorize? response_type=code & client_id = s6BhdRkqt3 & redirect_uri = https%3A%2F%2Fclient.example.org%2Fcb & scope = openid%20profile & state = af0ifjsldkj response_type で OIDC のどの認証フローを使うかを指定します。 redirect_uri は、 認証サービス での認証が成功したときの Web サービス にコールバックする URL です。これは事前に認証サービスに登録しておく必要があります。 scope には認証の内容を設定します。openid は必須で、他には OAuth2 のアクセストークンを使って取得できるユーザー属性情報を指定します。 scope で指定できるユーザー属性情報は以下のとおりです。 （ 公式より引用 ） ユーザーの認証でよく使われそうな「氏名」や「メールアドレス」など基本的な属性情報が定義されています。 state は CSRF 対策などのためのランダム値です。認証フローを開始するたびに Web サービス が発行し、リクエストとコールバックの間で値が維持されます。 他にもいくつかのパラメータ（nonce など）が定義されており、必要に応じて利用します。 Step.2: ユーザー認証と認証コードの発行 認証サービス では認証手段に応じてログイン ID ・パスワードの入力フォームなどを表示し、 ユーザー から認証情報を取得して認証処理を行います。 認証サービス はユーザーの認証に成功すると、認証コードを発行し、 ユーザー を Web サービス にリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA & state = af0ifjsldkj リダイレクト先について、 認証サービス は Step.1 で受け取った redirect url を 認証サービス に予め登録されている URL と合致することを検証する必要があります。_Web サービス のなりすましを防ぐためです。 また Web サービス 側で 認証サービス からのレスポンスであることを確認できるよう、state もパラメータに含めます。 なお、認証に失敗した場合は下記のように認証エラーした内容をパラメーターに加えて Web サービスにリダイレクトさせます。 HTTP / 1.1 302 Found Location: https://client.example.org/cb? error=invalid_request & error_description = Unsupported%20response_type%20value & state = af0ifjsldkj Step.3: 認証結果の取得 Step.2 で Web サービス は 認証サービス からのリダイレクトを受け、認証コードを取得すると、この認証コードを利用して 認証サービス に対して認証結果情報（ID トークンなど）を取得します。 Web サービス から 認証サービス への認証結果取得リクエストは以下のような形式になります。 POST /token HTTP / 1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA & redirect_uri = https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 認証コードを送信する必要があるため、POST メソッドでリクエストします。またクライアント ID とクライアントシークレットによる BASIC 認証を行います。 このリクエストでクライアントシークレットが必要になるのですが、これは 認証サービス にとって Web サービス の正当性を検証するための重要なパラメータであり、安全に管理される必要があります。 SinglePageApplication のようにユーザー側にあるアプリケーションで OIDC を処理する場合には、このクライアントシークレットが安全に管理される保証がないため、AuthenticationCodeFlow ではなく ImplicitFlow などを利用する必要があります。 Web サービス からのリクエストを受け取った 認証サービス は grant_type に Step.1 で指定した処理フローに該当する情報を渡し、認証コード（ code ）と合わせて 認証サービス にリクエストの検証をさせます。 認証サービス はリクエストの検証に成功すると、 Web サービス に対し認証結果として ID トークン等を返却します。 HTTP / 1.1 200 OK Content-Type: application/json Cache-Control: no-cache, no-store Pragma: no-cache { "access_token" : "SlAV32hkKG" , "token_type" : "Bearer" , "expires_in" : 3600 , "refresh_token" : "tGzv3JOkF0XG5Qx2TlKWIA" , "id_token" : "eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso" } access_token は 認証サービス で管理しているユーザー属性情報を取得するための OAuth2 トークンです。 refresh_token は 認証サービス から access_token を再発行する際に利用します。 Step.4: 認証結果の検証 Web サービス は 認証サービス*から取得した ID トークンを検証します。ID トークンは前述の通り JWT で表現されており、*認証サービス_の公開鍵を用いて検証することができます。 手順は こちら をご確認ください。他にも参考リンクを紹介しておきます。 https://qiita.com/bobunderson/items/d48f89e2b3e6ad9f9c4c https://qiita.com/TakahikoKawasaki/items/8f0e422c7edd2d220e06 下記は ID トークンに含まれる認証情報の例です。 { "iss" : "https://server.example.com" , "sub" : "24400320" , "aud" : "s6BhdRkqt3" , "exp" : 1311281970 , "iat" : 1311280970 } このうち sub が 認証サービス で管理されている ユーザー の識別子です。 iss は 認証サービス 、aud は Web サービス のクライアント ID になります。 exp、iat はそれぞれ認証の有効期限と認証したタイムスタンプです。 Web サービス は ID トークンが正しい内容であることが確認できれば、これをログインセッションと紐づけて保管します。 以上で認証処理は完了です。 ユーザー属性情報の取得 ユーザー認証後、 Web サービス がユーザー名などのユーザー属性情報が必要になった場合、Step.3 で取得した access_token を利用し 認証サービス に対してユーザー属性情報をリクエストします。 GET /userinfo HTTP / 1.1 Host: server.example.com Authorization: Bearer SlAV32hkKG このリクエストにより、Step.1 の scope で指定したユーザー属性情報が取得できます。 まとめ 以上少し長くなりましたが、ユーザー認証と OpenID Connect、特に基本の AuthenticationCodeFlow について解説しました。限られた発表時間の中での解説のため厳密さより雰囲気を重視した内容となりましたが、お気づきの点などあればお知らせいただければと思います。 サービスの要件やフェーズによって OIDC を取り入れるかどうかは様々ですが、ユーザー認証の実装を自前で実装、メンテナンスしていくだけでなく、Amazon Cognito などの便利な認証サービスを利用していくことも選択肢の一つとして検討してみても良いかもしれません。 そしてそれら便利な認証サービスをうまく使いこなすためにも、その背景にある OIDC の仕様や思想、そもそも認証の仕組みについて立ち返ってみると、理解が一段と深まるかとおもいます。 www.medley.jp www.medley.jp