AWSの学習記録まとめ

スポンサーリンク

何故今AWSの需要・必要性が出てきているのか?

この辺の話が不要だったり、各サービスについていきなり読みたい場合は↓の方に飛んでください。

クラウド化・マイクロサービス化はこれまでも言われてきましたが、今はますますやらないといけない。必須的な感覚に代わってきているように感じます。クラウド化っていう言葉も凄い抽象的なのですが、AWSはお任せ(マネージド)、自動化、拡張性、マイクロサービス化とかのメリットも色々ありますが、メリットのまとめとして全部「クラウド化」として書いていきます。

スタートアップ企業では先ずお金を回収する事が第一なので、クラウド化が特に言われるのは、ビジネスがある程度成功している企業です。(もちろんスタートアップ時点からしっかりと出来ていれば余計な負債を抱え込まないで済みますが。でもお金がかかるので、ビジネスがしっかり見通せていて先にお金を投資してもらう必要があります。)成功したばかりというより、作り始めてから5年・10年経過しているからそろそろという企業がそうだと感じます。

そんなわけで、対象企業はシステム的に負債を多く抱えていて、利益を更に伸ばそうとしつつも、レガシー環境から抜け出そうとしています。レガシー環境とは、クラウド化していないオンプレ(自前でサーバを建てたり)・古いバージョン・その場しのぎで肥大化したサービス全体が一枚岩(モノリシック)となっていて簡単に修正出来なくなっている、というケースが多く見受けられます。

これはビジネスとして利益が出るかわからない状態で、とにかく利益を優先していった結果なので、仕方のない事だと思います。サービスを利用する側からすれば、中身の事なんてそうそうわかる事ではありません。例え中身が汚かったとしても、ユーザに良いと思ってもらえるサービスであれば、伸びていくからです。

AWS化するメリットとは?

というわけで、今レガシー環境を改善したい。そういった企業がAWS化していくわけなのですが、AWS化するメリットについて補足しておきます。

クラウド化

これは本来のクラウド化の意味でです。自前でサーバ機を買ってきて会社に置いて、インストールしたり、冷却の電気代を払ったり、土地的なコストがかかったり、というコストから解放されます。もちろんAWSに対してのコストはかかりますが、人件費を考えるとクラウド化した方が良くなる為、メリットがあるレベルの値段になっています。

マイクロサービス化

大きな一枚岩(モノリシック)なサービスとなってしまうと、修正しようにも全体の仕様を把握しないと怖くて手をつけられないという事になってしまいます。これがマイクロサービス化する事によって、サービスが分割されて、小サービス毎に責務も分割されるので、仕様を把握する範囲が狭くなり、修正がしやすくなります。プログラムのメソッドと同じで長いメソッドより細かいメソッドの方が影響度が限定的になり、修正しやすいのと同じです。

また、マイクロサービス化する事により、今後この小サービスだけを別サービスに入れ替えたりする事も可能になるので、拡張性もあがります。

ただし、マイクロサービス化は小サービス毎に環境や言語が異なったりして、新しい挑戦が組み込まれている事がほとんどだと思うので、移行や構築するのがそれなりに大変だと感じています。後々にメリットがある分、軌道に乗るまでは逆にコストがかかると思います。

自動拡張(オートスケーリング)

例えば、サービスに大量アクセスが来た時に、webサーバであればサーバ台数を増やせば落ちないように・レスポンスも遅くならないように出来るとします。それを手動(自前プログラム)でやるには作るのも大変ですし、ノウハウも必要になってきます。これをやってくれるのがAWSのマネージド型サービスというわけです。負荷がかかれば勝手にサーバを増やしてくれたりします。

節約

レガシー環境時代には、大量アクセスを予期して予めサーバをスタンバイさせておく必要がありました。そうすると、普段は使わないのにチェックする時間・仕組みやサーバ代が余計にかかったりしました。これが必要になった時だけ自動拡張する事によって普段は余分なコストが発生しなくなりました。

バージョン管理

セキュリティ的にバージョンアップする必要が出てきたりする事があると思います。いざ実施するとなると、手順・開発など色々なコストがかかってきてしまいます。これを自分でやらずにAWSに任せられるのであれば、本来やりたかった利益を追う作業に集中出来ます。

専門的な技術を必要としない

web画面からポチポチウィザードに従って設定していくだけでインフラが構築出来るので、アプリ側の開発に専念出来ます。

ただ、これはまだまだ完全にそうではないです。専門的な知識がないとこのポチポチが出来ない箇所もあったり、構成を考えられなかったり、AWSが記載している説明の意味が理解出来なかったりしますので、現状では専門的な知識の概要だけは最低限知っていないとAWSを良い感じには使えません。

その他

なんて書いたら良いかわからなかったので、雑に他とします。復旧もそうですね。何か意図せぬ事故があって落ちてしまった場合でも、それを何もせずに自動的に検知して勝手に立ち上げてくれれば助かりますよね。仕組み開発だけでも大変ですので。

前説のまとめ

というわけで、AWS化する理由やメリットは以上になります。

ざっくりとまとめると、コスト・便利・利益追求に専念したい。という感じだと思います。

お待たせしました。以下からAWSの各サービス毎についてコメントしていきます。

勉強中のものも多いのですが、触った事ない人でもサービス毎に概要が把握出来れば幸いです。

AWS AppSync

https://aws.amazon.com/jp/appsync/

GraphQL というAPI向けの言語がポピュラーになってきた事で、導入しようとするとサーバに GraphQL 環境を構築する必要がありましたが、AWSにマネージド型サービスとして登場したので、サービスとして利用するだけで良くなりました。 GraphQL サーバをたてる必要がなくなり、サーバレスで運用出来るようになります。

AWS GraphQLというサービス名の方がわかりやすいのにと思いました。

GraphQLを単に実行というだけでなく、実行前処理、後処理がここに乗せられますので、これだけで色々やろうと思えば出来そうです。

API の DBとして、Elasticsearchと連携してみましたが、対応具合から見るに、AuroraMySQLやDynamoDBがAmazonとして連携させるのを推奨しているのではと感じました。普通に考えてそのユースケース (RDS・Dynamo)に使う事 が多いと思いからだと思います。

Amazon Elasticsearch Service

https://aws.amazon.com/jp/elasticsearch-service/

検索DBのOSSである Elasticsearch がポピュラーになってきた事で、導入しようとするとサーバに Elasticsearch をインストールして管理しなければいけなかったのですが、AWSにマネージド型サービスとして登場したので、サービスとして利用するだけで良くなりました。 Elasticsearch 用のサーバをたてる必要がなくなるので、 サーバレスで運用出来るようになります。

更新や参照はリクエストに json パラメータを渡してあげます。結果も json で受取ます。

検索DBはSQLで取得する結果と同じになるわけではないという点が難しく感じました。仕様に合った使い方を実装するにはアルゴリズム設定・選定が必要になってきます。大量のデータから高速で文字列検索する用途に使われる事が多いと思われます。

Elastic Load Balancing

Application Load Balancer

概要

L7レベルのLBになります。最近 ALB から Lambda をターゲットとして接続できるようになりました。パブリックDNSにアクセスすればブラウザから確認出来ます。L7レベルなので、プロトコルやURLでの振り分けが可能です。簡単なレスポンスも返せますので、メンテナンス時などにわざわざサーバの設定をしなくても、一律503にしてメンテナンス案内が書かれたHTMLを返す事も可能です。そう、このALBならね。

LBからのヘルスチェック機能( 死活監視 )も存在します。

LBのターゲットが落ちていれば、CloudWatchにログ出力をして、それをトリガーにしてRoute53を切り替えたり、ALBのターゲットグループを変更したりフェールオーバーの対応も出来ます。

これまでhttps対応をする際はnginxなりapacheのconfにSSL証明書の設定を記載して、毎年更新してやる必要がありましたが、ALBにAWS Certificate Managerで生成したSSL証明書をつける事が可能となりました。その場合、ALB⇔EC2はhttpでの通信となりますが、これまでの運用がAWSマネージド型となり、毎年の面倒だったSSL更新も不要となります。

Route53で設定した複数ドメインを、1つのALBに設定する事も出来ます。入り口に集約してという感じで出来ます。もちろんその際にSSLのACMも1つのALBに設定可能です。手順は簡単でhttpsリスナーに複数のACMを選択するだけです。

ログはS3に出力するという設定が出来て、それをAthenaで分析可能です。標準でCloudWatchで監視されているのでメトリクスを確認出来ます。

後述のAWS Global Acceleratorを使用すれば、ALBにも固定IPを割り当てる事が出来ます。使う事もあるかと思いますので、覚えておいて損はないです。

料金について

待機含む稼働時間料金と通信料金の合計です。ですので、少ないアクセスでもずっと立ち上げていると料金がかかってしまうタイプです。

注意点

ALBはhttpとhttpsだけになります。

AWS Lambda

以下の記事にまとめました。

【まとめ】AWS Lambdaポイント・どのようなサービスか?
概要 トリガー、処理、後処理を組み合わせて作れる機能です。AWSマネージド型の為、サーバレスでスケーラブルに使用出来ます。 ...

Amazon SQS (Simple Queue Service)

非同期通信でキューに溜め込んで処理していく事が出来ます。一度に大量の処理が発生して、即時に実行しなくても良いのでやるような処理に向いていると思われます。

※まだ使った事はないので見た感じです。

注意点

同期通信ではなく非同期通信での処理という点と、キューに溜まった処理は複数回実行される事があったり、キュー順に処理されないという仕様だそうです。

https://qiita.com/tomoya_ozawa/items/dc0286cdb30763eab174

料金について

件数から料金計算されます。

AWS Certificate Manager

ALBの箇所に記載した通り、ALBにも設定出来ます。

これまで毎年サーバで更新していたSSL証明書の設定の手間が省けます。

AWS Global Accerator

これもALBの箇所に記載した通り、これを使用すれば、ALBにも固定IPを割り当てる事が出来ます。2019/8時点ではまだ東京リージョンはありませんが。

AWS IAM

ユーザ、ロール、ポリシーの権限を管理出来ます。権限は必要最小限にする事で、意図しない事故やセキュリティのトラブルを限定的にする事が出来ます。

一見地味な機能ですが、AWS 全般にまたがる基本機能な為、細かい使い方にも慣れておいて損はないと思います。

2段階認証の設定が必須なユーザにしたり、ユーザをグループに所属させたり、どのサービスのどのリソースのどの機能だけを使うかなど細かく決められたりします。

AssumeRole

この機能では、別アカウントに権限を委譲する事が出来ます。しかも期限付きで委譲出来る為、リスクを限定的にする事が出来ます。

権限が必要最小限のユーザに、必要最小限の権限を委譲するという使い方が出来ます。

Amazon CloudFront

以下の記事にまとめました。

【まとめ】Amazon CloudFront CDNサービス
AWSのCDNである強力なサービスCloudFrontを色々と使用してみました。そもそものCDNについての概要から、CloudFrontの...

Amazon Athena

以下の記事にまとめました。

【まとめ】Amazon Athenaとは
ELBやCloudFrontのログはどうされてますか?S3に入れている方が多いと思います。 S3に指定バケットを作ってそれを指定する...

以下の技術はまだ検証中です

ECS

AWS Fargate

未使用ですが認識を記載しておきます。

サーバやクラスターの管理がなくなります。と結果だけ言ってもやってないと良くわからなくなるので、EC2、ECS、Fargateと歴史で順を追って考えてみます。

先ず、EC2でサーバをたてる場合、サーバの管理が必要になります。立ち上がっているか、落ちていれば立ち上げないといけないですし、落ちないようにする必要があります。リソースは適切に配分されているか、配分されていない場合は自分で変えないといけないです。

次に、コンテナ技術が出てきてECSでEC2を立ち上げるようになりました。便利になりましたが、まだクラスターの管理が必要です。

そして、Fargateです。EC2は内部で立ち上がっていますが、立ち上がっているとは外からは見えず、管理は不要です。クラスターの管理も必要なくなりました。リソースの配分も勝手にやってくれて減らしたり増やしたりしてくれます。

?認識あってる?

EKS

コンテナオーケストレーションサービスとしてポピュラーのKubernetesのAWSマネージド型サービスです。現在、Fargateは使用できませんが、対応中との情報です。