How to use AWS S3 in a smaller enterprise

Introducing how to use AWS S3 in smaller interprise.

links that use in this slide below.

https://tntdrive.com/
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/crr.html
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/using-iam-policies.html
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingServerSideEncryption.html
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_identity-management.html#intro-identity-users
http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction_identity-management.html#intro-identhttp://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/object-lifecycle-mgmt.html
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ServerLogs.html
http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/NotificationHowTo.html

Transcript

1. How to use AWS S3 in a smaller enterprise. ある会社のS3のつかいかた。
2. 自己紹介 TiNm’S といいます。 フリープログラマです。 Ruby On Rails、AWSが主戦場です。 好きなAWS サービスは、OpsWorks です。
3. はじめに
4. 今日持って帰ってもらうもの ✓ NASとしてのS3 ✓ デイリーオートメーションとしてのS3 ✓ バックアップとしてのS3 ….. あと少しのアルコール分。
5. パターン1: NASとしてのS3
6. 構成
7. NAS before
8. after !
9. 共有、プロジェクト、個人にわける
10. セキュリティ
11. SSE(Server Side Encryption)でてっとり早く暗号化。
12. 個人単位でIAMユーザーを作って認証情報 を配布。 認証情報は自分でちゃんと管理しろよ。とい う意味も込めて一人ずつに配布。 なくしたり、漏れたらわかってるやろーな ... と いう意味も込めて、あえて自己管理させる。 IAM
13. バケットポリシー Personalフォルダには、バケットポリシーで 個人のユーザーにオブジェクトへの CRUDを 付与。前述したIAMを各フォルダに設定。 Share、Projectは全員が閲覧できるように設 定。
14. ユーザビリティへ
15. ほぼWindowsユーザーだったので、共有 フォルダとして見えて、Explorer上で操作 できるのがよい。
16. tntdrive Explorer上に共有フォルダとしてマウントできる。
18. 変えてみてよくなったこと
19. リモートで管理できる！ (インシデント発生時に自社に帰らなくてよくなった。)
20. HWのこと考えなくていい。 (年末のリプレースを考えなくてよくなった。)
21. 変えてみて悪化したこと
22. 転送速度 (まれに、大きなデータを転送すると、やっぱり時間がかかります。)
23. 結論：こんな人にオススメ(1)。 NASを設置しているが、容量大丈夫か？バックアップ大丈 夫か？経年劣化で交換いるんじゃない？ っていう割に、「古いけどまだ使えるじゃん」ていう人もい て、結局古いのは廃棄もできずに、どんどんNASが増え る、なんて悩みを毎年のように繰り返すことにもう疲れた 人。
24. 結論：こんな人にオススメ(2)。 インフラエンジニアなのに、社外に出稼ぎに出されて、イン シデントが発生するたびに、自社に戻って対応して、「は あ、なんで俺だけ」みたいに土日に少し黄昏てしまいそうな 人。 で、リモートで全部対応できたらいいなあ、なんて思ってい る人。
26. パターン２: 日時処理のオートメーションとして使うS3
27. 構成
28. Web 毎日の勤怠データ 総務、人事のひとびと
29. 勤怠データを社内のレガシーシステムから収集。 収集したデータをS3にアップ アップロードをイベントとしてラムダをキックして RDSへ。 このRDSは勤怠分析のWebシステムのデータベース。
30. ポイント
31. 何回も何回もS3。
32. １回目 ファイル名を英字のみに変換 + 文字コードもUTF-8に変換してput. (レガシーシステムから出力されたデータは、ファイル名に日本語が 混じっていたり、shift-jisだったりして、扱いずらい。） 2回目 データをデータベースのレコードの形に整形して、 S3にput. 3回目 S3にputしたレコードデータを RDSに格納。 put put
33. S3を一時データの格納先として 使い、イベントドリブン、で処理を つなげる。
34. 結論：こんな人にオススメ。 サーバーをできる限り増やしたくない人。 運用コストを下げたい人。 レガシーデータをAWSにアップしたら、綺麗になってほしい 人。
36. パターン3: バックアップとしてのS3
37. 構成
38. AWS CLI で１週間ごとにバックアップ
39. (S3に）置くだけです。
40. 99.999999999%の 耐久性を獲得しています。
41. 直近１週間分だけ保存。
42. 監視
43. S3のログの記録とalertの通知(SNS)
44. 結論：こんな人にオススメ。 バックアップが失敗したらどうしよう。。とか、バックアップ サーバー潰れたらどうしよう。。いつも悩んでしまって仕事 が手につかない人。
45. Cross region replication ミッションクリティカルな方には。。。
46. 結論。 S3は、単純な発想でシンプルに使っても、 結構運用できる。 実際に使ってるところがある！というのを武器に、社内をと ことんAWSにしちゃいましょう！