データドリブンな経営戦略を行うこと実現するためには、まずはデータを集めることが、その第1歩になるのではないでしょうか？
集めたとしても、従来のオンプレミスサーバではペタバイト、エクサバイトのデータを保管すること自体が大変なイメージが私にはあります。また、せっかく保管したデータがHDD障害などで吹っ飛んでしまうとそれこそ、集めた努力が水の泡になってしまい、地獄を見ることになると思います。
今回は、こうしたデータ集め、保管する場所として利用される機会の多い S3について見ていきたいと思います。
データレイクに有効なオブジェクトストレージ
データを集める場所のことをデータレイクと呼びます。データには様々な形式があります。csv形式、JSON形式、ログ、parquet形式、excelファイル、画像、動画等などシステムや人によってデータの持ち方は様々です。こうした様々な形式で、且つ大量のデータを保管するのに適しているのがS3に代表されるオブジェクト型ストレージサービスです。
オブジェクトストレージ型サービスって何？
S3はオブジェクトストレージ型サービス（以下オブジェクトストレージ）ですが、従来のファイルストレージと似たようなUIで操作ができるため、直感的にはあまり違いがよくわかりません。ですが、オブジェクトストレージは絵にすると以下のような違いがあります。
ファイルストレージはツリー（階層）構造で整理されて、ファイルが保管されているのに対して、オブジェクトストレージは全てのファイルが同階層（そもそも階層という概念がない）にファイルが配置されています。
オブジェクトストレージだと何が良い？
S3とデータレイクの話の前にもう少しだけオブジェクトストレージについて整理しておきたいと思います。
オブジェクトストレージには階層という概念がないため、システム上管理が容易です。
AAA.docは\\fileserver\directory-a\sub-directory-b\にありませんでしたか？
AAA.docなら\\fileserver\directory-a\sub-directory-b\old\に移動しましたよ。
といったやり取りをしたことがないでしょうか？ファイルを探す際にファイルストレージシステムの場合、階層に依存するため、階層が変わるとファイルを見つけられなくなります。また、階層が深ければ深いほど、移動するディレクトリの数が増えていき、手間がかかります。
オブジェクトストレージにはこの心配がありません、なぜなら全てのファイルが同じ階層に置かれているからです。
オブジェクトストレージのメタデータ
同じ階層にファイルが沢山あると逆に探しにくいことありますよね？オブジェクトストレージにもこの考えが当てはまるかというそうではありません。オブジェクトストレージにはファイル1つ1つにたいしてメタデータと呼ばれる属性情報付与し、そこで管理がされているのです。つまり、オブジェクトストレージを探すときはこのメタデータを指定してあげればすぐにファイルを見つけることができます。メタデータ自体はファイルストレージシステムにもありますが、オブジェクトストレージほど柔軟ではありません。オブジェクトストレージはこのメタデータをカスタマイズすることができ、より柔軟にファイルの管理ができるようになっています。
データレイクとしてなぜS3を選んだのか？
ここからはデータレイクになぜS3を選んだのかを考えていきたいと思います。
大量データを想定する-容量無制限なS3
オブジェクトストレージはフラットな階層にファイルが配置されるため、スケーリングも容易という特徴があります。S3もオブジェクトストレージのこうした特徴をうまく活かして容量、オブジェクト数は無制限で保存が可能という特徴があります。1つ注意点があるとすれば、１ファイルあたり最大５TBという制限があることですが、あまり1ファイルで5TBというのはお目にかかることはないので、制限はないに等しいといえます。
運用の手間を減らすフルマネージドサービスのS3
S3はマネージドサービスと呼ばれるもので、従来のオンプレミスであれば、必要であったHDDの管理といったところが不要です。具体的には以下のことを考えなくて良いということです。
容量がいっぱいになってきたから追加でHDDをふやさないと。
パフォーマンスが悪いのでスペックをあげないと
こうしたスケーリングは全てAWS側が自動で対応してくれます。
データは損失してはいけない-高い耐久性を持つS3（99.999999999％）
分析するための大量データは企業として非常に重要なデータが沢山含まれています。そのデータがHDDなどの障害で損失したなどはあってはならないことです。その点でS3は高い耐久性という特徴を持ちます。
S3に保存されたファイルはリージョン内で3ヶ所以上のデータセンターに自動的に複製し、保持されます。そのため、障害に強く、データ損失も極めて低いことが特徴的です。上記の99.999999999はイレブンナインと呼ばれていて、この確率でデータは損失しないと言われています。
使い方によって料金を選べるS3
S3を使うにあたって、コストは気になるところだと思います。高いのか、安いのかはユーザー次第なとこもあるかと思いますが、S3には利用用途に応じたストレージクラスが用意されており、それぞれ金額も異なります。
S3の料金は以下の4点の要素があります。
- ストレージ料金
- リクエストとデータ取り出しの料金
- データ転送と転送高速化の料金
- データ管理機能の料金
それぞれストレージクラスや利用量によって金額は異なるため、このブログでは利用用途の紹介にとどめておきたいと思います。料金詳細については公式サイトをご確認いただければと思います。
https://aws.amazon.com/jp/s3/pricing/
ストレージクラスの種類
| ストレージ クラス | 主な用途 |
|---|---|
| S3標準 | 標準的なストレージクラス |
| S3 Intelligent- Tiering | アクセスパターンをモニタリングし、低頻度のオブジェクトは標準-IAへ高頻度もオブジェクトは標準に自動で移すことで、効率的に保存コストを効率的に扱うことができます。 |
| S3 標準-IA | S3標準に比べて保管料は安いが、データ取り出しに時間がかかる |
| S3 1 ゾーン-IA | S3 標準-IAと比較して、保存先を1つのAZにする。（標準は3つ）そのため、S3 標準-IAよりもコストが安い |
| S3 Glacier | アーカイブ用途の利用で、取り出しに数分〜数時間を要する。 |
| S3 Glacier Deep Archive | S3 Glacierよりも取り出し時間はかかるが、Glacierよりもコストが安い。 |
S3 バケットを作成し、オブジェクトを配置する
ここまでは概念的な話をしてきましたので、具体的に手順に沿ってS3バケットを作成し、そこにオブジェクトを配置したいと思います。
用語の解説
手順に沿う前に簡単に用語の解説をしておきます。
バケット
オブジェクトの保存場所を指します。バケットの名前はグローバルに一意にしなければならず、この名前空間はすべての AWS アカウントによって共有されています。AWSアカウントあたり最大100個まで作成が可能です。。
オブジェクト
S3に保存されるデータのこと。いわゆるファイルを指します。バケット内にオブジェクトは無制限に格納できる。
キー
オブジェクトの格納URL（バケット＋キー＋バージョン）で一意に特定可能です。
S3のバケットの作成
S3の画面で『バケットを作成する』をクリックする
バケットの作成画面で『バケット名』と『リージョン』を選択し、次へをクリックする。
バケット名
バケットの名前はグローバルに一意の名前にする必要があります。
リージョン
レイテンシーや国によっては規制のことも考慮して選ぶ必要があります。基本的には東京リージョンを選択するでよいと思います。
オプションの設定を選択します。今回はデフォルトの状態で『次へ』をクリックします。
バージョニング
オブジェクトのバージョニングを設定すると、編集や削除をした際のオブジェクトの履歴を持つことができ、指定のバージョンに戻すことが可能になります。
サーバーアクセスログ記録
主に監査目的の利用が多いと思います。バケットへのアクセスログを取得します
Tags
ラベルのようなもので、1 つのキーとオプションの 1 つの値をセットで構成します
オブジェクトレベルのログ記録
AWS CloudTrailを利用してS3 バケットにあるオブジェクトのデータイベント（Get、Delete、Put など）をログに保存します。有料のオプションになります。
デフォルトの暗号化
S3にデータ転送する際にAWSの暗号化方式を使ってオブジェクトを暗号化してくれる設定です。
オブジェクトのロック
オブジェクトロックを使用して、オブジェクトの削除または上書きを防ぐことあができます。。
CloudWatch リクエストメトリクス
CloudWatchを利用してストレージを監視することで、S3操作をするアプリケーションのパフォーマンスの把握につなげます。
アクセスの許可設定をします。今回もデフォルトのままで『次へ』をクリックします。理由はパブリックアクセスを禁止にしているので、管理者によって許可されたものしか、このS3 バケットにはアクセスができないようになるからです。
S3バケットの作成が完了すると、上記のように表示されるはずです。
オブジェクトのアップロード
バケットの中に入った状態から説明をはじめます。
『アップロード』をクリックします
『ファイルを追加』をクリックし、ファイルを選択後、『アップロード』をクリックします。以上でファイルのアップロードは完了です。
S3のデータ整合性について
S3では、保存されたファイルをリージョン内で3箇所以上のデータセンターに自動的に複製して保持しています。この高い可用性を実現するためにデータの更新削除の際は結果整合性が採用されています。詳細は以下の表のとおりです。
| オペレーション | 整合性モデル | 挙動 |
| Create | Consistency Read | 登録後即時にデータが反映される |
| Update | Eventual Consistency Read(結果整合性) | 更新直後はデータ反映に時間がかかる |
| Delete | Eventual Consistency Read(結果整合性) | 削除直後は削除前のデータが参照される可能性がある |
データレイクとしてS3を活用するために
データレイクとしてS3を活用するにあたって、運用のポイントがいくつかあると思います。ここからは、私が思うポイントをいくつかご紹介したいとおもいます。
バケットをどのような単位で作るか
いざバケットを作ってデータレイクを作るぞ！と考えて、まずここでStopするのではないでしょうか？ここでは、私が思うバケット作成単位を紹介したいと思います。
小さく始めて、PoCを繰り返すことを前提とする
最初から様々なパターンを考えて厳格にルールを作ろうとすると、それだけで相当の時間がかかります。そのため、まずは小さく始めて、成長させていくことを前提に考えるほうがよいです。ここで私が紹介した基準もあくまで最初の基準と考えていただければと思います。
用途ごとにバケットを分ける
バケットは1アカウント100個まで作成が可能です。そのためこの100個をうまく活用しない手はありません。バケットは用途ごとに分けることをお勧めます。
簡単な絵ですが、私の場合、データレイクからDWHまでの部分で4つ用意します。SageMakerなどの機械学習で使う場合は、加工前のデータがよかったりするケースもあるため、データレイクとDWHはそれぞれ別のバケットで分けておくほうが良いです。
収集
データレイクを指していて、受信したデータに手を加えずそのまま保管する場所になります。
蓄積
DWHを指します。受け取ったデータに対して何らかの加工が加えられたり、RedshiftやAthenaといったサービス参照される部分としています。
データ受信と処理用
エラー発生時のリカバリーを考え、データの流れを分かりやすくするためのこの2つは設けています。エラー発生時にどこまで処理をしたのか？そして処理途中のデータをどう扱うべきかといった影響調査をした人は多いのではないでしょうか？私も数々のエラーに対して調査・対処をしてきました。
その結果、バケツリレー方式でデータを次の処理に渡していくことが、エラー発生時のリカバリーが比較的容易だと私は感じています。次の処理が全て終わった時点で前段のデータを消すという処理にしておくことで、もし次の処理でエラーが発生しても、ただ再開するだけでリカバリーができます。
オブジェクトのライフサイクルを考える
データレイクに溜め込むデータは基本的に削除を想定しないケースがほとんどだと思います。しかしS3を含めクラウドのストレージサービスは保存するデータ量が増えれば増えるほど、料金は増えていきます。コストは無制限ではないため、費用を少しでも抑える方法も検討が必要です。
ライフサイクル設定を設ける
S3にはライフサイクルの設定をする機能があります。この機能を使い、私の現場では2年間はS3 標準にデータを保持し、2年を経過したデータはS3 Glacierに移すようにしています。2年としている理由はユーザーが前年度比較でデータを参照するケースがあるため、直近2年間のデータはすぐに取り出せる必要があるためです。このライフサイクルは業務ユーザーとコスト面や、データの利用頻度、データ範囲を相談し決める必要があります。
まとめ
データレイクとしてS3を利用するにあたって、オブジェクトストレージの概要やS3バケットの作り方、データレイクとして利用する際のポイントをまとめてきました。データレイクを活用していくためには、AWS Glueなどを使ってデータカタログを用意し、データ利用の促進を促すことが実は重要なポイントなのですが、今回はそこまでの説明は含めませんでした。S3を使う方の少しでも手助けになっていれば幸いです。
