読者です 読者をやめる 読者になる 読者になる

日々充実

毎日が充実したと思えるようになるためのブログ

【Report】雲勉 in 名古屋 vol.2 その2

こんばんわー!ヒサユキです。
今日は昨日の続きを書いていきたいと思います(´ω`)

↓昨日の記事
yuki-dev.hatenablog.com

AWSの提唱する10の設計原則(5〜10)

サーバーではなく、サービスの利用(マネージドサービスの活用)

オンプレもそうですし、レンタルサーバなどもそうなのですが、
サーバ管理すらもう手放してしまうということも出来てしまいます。

マネージド・サービスを使うことによって、管理部分をAWSに移管することが出来ます!
極端な話、物理サーバの面倒を見なくていいというのは運用コストがかなり下がりますよね。
Auto Scaling等のサービスもただサーバを買ったり借りたりするだけではついてこないサービス。
回線部分もそうですし、それこそ負荷分散するためのデータセンターを複数保つ必要もないです。
磁気テープにバックアップとって遠隔地に持っていく等の作業もなくなりますね。

EC2などのコンピューティングサービスはそれでいてroot権限を貰えるので、
ほぼ制限なくやりたいことはやれると思います。
ただし、責任の共有としてAWSが面倒を見るのはあくまでインフラ部分のみ。
OS以上の部分のセキュリティ担保はユーザ側でしなきゃいけないです。

それであっても、物理的な運用部分はすべてAWSが賄ってくれるだけでも、
アプリケーション開発などのコア業務に専念できるのは素晴らしいです!

そして最近はEC2すら使わない、サーバレスアーキテクチャもコレに当たりますね!!
もはやコードしか書かない、実行環境はすべてAWS側の管理!
今後、習得したい技術の一つです(´ω`)

データベースの使い分け

データベースといえば、RDBが今まで主流でしたが最近ではNoSQLもいい感じです。
AWSではどちらも選択できますヽ(=´▽`=)ノ

NoSQL
  • DynamoDB
    • NoSQLのサービス、三拠点でレプリケーションを常に行っている。
    • SSDにデータは格納され永続化されています。
  • ElasticCache
    • インメモリ型のDB
RDB
  • RDS
  • RedShift
    • データ・ウェアハウス型のDB
    • 大量データの集計、分析に便利!

このように、複数のDBサービスが有り用途によって使い分けが可能です。
またRDSについては各データベースのメジャーアップロードの面倒も見てくれます!
バックアップもデフォルトで1日1回自動で取得しており、
そこからはトランザクションログを取り続けているため、最短5分前の状態にリカバリできます。

単一障害の排除

障害が1箇所で起こったとしても、それに耐えられる設計にしましょうということです。
影響を小さく、1箇所で何かあったくらいではシステム停止につながらないように、
このあたりは疎結合の考え方にも近いものがあります。

単一障害点排除のためのポイント
  • 冗長化
    • 常に2箇所以上の場所でデータを保持
  • 障害検知
    • 発生した障害をいち早く検知できる仕組みを!
  • 堅牢なデータストレージ
    • S3も常に冗長化しており、堅牢性:99.999999999%を誇っています
  • Multi-AZの利用
    • 同じ地域で別のデータセンターにサーバを配置することが出来る!
  • 疎結合な構築に寄る障害分離
    • こちらは疎結合でお話したとおり!

コストの最適化

スケーリングや固定資産の話でもしましたが、既存のシステムをAWSに移行するだけでも
初期投資を抑えることが出来き、Amazon規模のインフラが低額で使えます!

オーバープロビジョニングも、サイジングミスで結局追加購入なんてことも、
AWSではいつでも調整が効くため心配いりません(´ω`)

また、CloudWatchによるメトリクス監視で今のスペックが適正なのかを運用後からでも確認可能。
そこからのスペックや台数の微調整も可能です!

キャッシュの利用

繰り返しアクセスのあるデータはキャッシュにいれましょう!ということで、
CloudFrontを使うといいよってことでした。

主に性能改善につながることで、CloudFrontを使うことでエッジロケーションという、
リージョンやアベイラビリティゾーンより更に細かい単位のデータセンターがあります。
そこにコンテンツを配布することで、実際のサーバにあるデータに毎回アクセスせずに、
一番近いエッジロケーションにアクセスをするようになるためレスポンスが早くなります。

エッジロケーションにない場合はオリジンサーバーに取りに行きますが、
一度取りに行ったコンテンツデータはエッジロケーショに配布されるので、
2回目からはエッジロケーションにアクセスする仕組みになっています!
レスポンス向上とオリジンサーバーの負荷軽減にもなります(´ω`)

セキュリティ

最後にセキュリティ、様々なセキュリティ対策は設定できます!
ですが、大事なのはデフォルトではなっていないことも多々あります。

IAMによるアクセス管理、保管データの暗号化、
サブネットをPublicとPrivateで分けたりもできますし、
サーバにはセキュリティグループ、VPCにはネットワークACLと、
設定さえちゃんとすれば、かなり強固なセキュリティが担保されます。

セキュリティ確保のためのポイント
  • AWSの機能の活用
  • AWSへのセキュリティの担保をオフロード
  • 最小権限の原則
  • Security as Code
  • リアルタイム監視

まとめ

以上になります!!
1日で結構基礎的な所をがっちりやってもらえたのは嬉しかったです!
何より、話の内容についていけるようになった事が嬉しかったですヽ(=´▽`=)ノ

これで構築とか実際にやっていけたらもっとスキルアップできるんだろうなって感じました!

次回の雲勉は最近入ったばかりのサービス、StepFunctionについてです!
もしご興味のある方は一緒に勉強しましょー!ヽ(=´▽`=)ノ

kumoben.doorkeeper.jp