5903227 ランダム
 HOME | DIARY | PROFILE 【フォローする】 【ログイン】

GMの抵抗ワショーイ

全7件 (7件中 1-7件目)

1

サーバ

2018.08.08
XML
カテゴリ:サーバ
今日はネットワーク周り回、ということで用語の整理など。
後半では試験直前に視ておきたいリストを作ってみます。


DNS(Route53)

Route53はAWSマネージド型のDNSサービスです。
53番ポートを使っての(SSHは22番ポート)正/逆引き名前解決をすることからそういわれてます。
A(Adress)レコード(ドメイン名:IPアドレス=1:n)やCNAME(Cannonical Name)レコード(IPアドレス:ドメイン名=1:n)辺りの話。
CNAMEはリダイレクトとかに使われたりもする。

Route53に登録すると、4か所のエッジロケーション(CloudFrontのキャッシュサーバやAWS WAFなどが動作してる)というデータセンターに共有されます。

サポートされているレコードタイプは様々で、Aレコード(Ipv4が返ってくる)やAAAAレコード(IPv6)、CNAME(hostname.example.com)みたいなのが返ってきたりなど。
CNAMEで登録できるのはZoneApexという最上位のパスのみで、その下の/redstoneteikou/みたいなレコードは作成できません。

後使いそうなのはメールの配送先指定でよく用いられるMXレコードや
ドメインのネームサーバを指定するNS (Name Server) レコード
辺りかな。
example.comならexampleとcomを分割する感じ。
[参考]DNSの勉強ノート【その2】A/CNAME/NS/MXレコード
[参考]DNSとかネームサーバとかRoute53とかAレコードとかCNAMEとかがわからない人のためのまとめ

Route 53では、これらの他に独自拡張である「エイリアス(ALIAS)レコード」という特殊なレコードがあります。
CNAMEレコードと似た挙動をするもので、CNAMEレコードと比べてパフォーマンスが良く、zone apexに対するマッピングに対応してくれたりします。
ただし、AWS内のELBやCloudFrontといった限定されたリソースのみでしかエイリアスは使えないで注意。
(AWS Trusted Advisorでも使える場面ではエイリアスレコードをレコメンドしてくれます。)


レコード作成時にどのような応答をするのか、色々なパターンが指定できます。
・シンプルルーティング:通常の設定
・位置情報ルーティング:近い位置のリソースを指定
・レイテンシールーティング:遅延が発生しにくい場所を指定(≠近い位置)
・フェイルオーバールーティング(アクティブ/アクティブ):複数のリソース
通信をルーティング
・フェイルオーバールーティング(アクティブ/パッシブ):普段利用してるDNSが落ちてる時は待機系に通信をフェイルオーバーする
アクティブ/パッシブ(ON/OFF)スキルみたいなもんやな

Route53で行える設定(レイテンシ・加重ラウンド・位置情報など)と大体同じ。
2つのリージョンで同じWEBシステムを構築したい時はレイテンシや果汁ラウンド・位置情報のルーティングポリシーを使うと良いです。
フェイルオーバールーティング(アクティブ/パッシブ)はヘルスチェック機能のことです。


ELBでは増減するIPアドレスでなくDNS名を使用します。
WEBサイトホスティングもIPアドレスでなくエンドポイント名を指定します。
CNAMEのZoneApexで別名返す機能を利用するときはAWS用のエイリアスレコードを使う、と覚えておくとよさげ。
例えば「S3の静的ウェブサイトホスティングを利用したWebページをexample.comで返したい」時はエイリアスレコード。


AWS Aurora
RedShiftなどと同様にRDBサービス。
PostgresSQLやMySQLと互換性があります。
データはS3などと同様に3か所のAZに自動で格納されて、さらに1つのAZにつき2か所のディスクに書き込まれるため、全部合わせて6か所に保存してくれます。
Auroraを使うメリットとしては
・セキュリティパッチ適用の負荷軽減(時間指定で自動適用)
・バックアップと復元が自動化できる
・マルチAZ対応
・リードレプリカも対応

ちなみに、RDBの性質上オートスケールについてはAutoScalingを活用してのスケールアップ(エンハンス)することはできても、スケールアウト(分身)することはできません。
NoSQLのDynamoDBならAutoScalingのグループ組んでできます。
RDBならリードレプリカとかマルチAZで頑張ってください。


MySQL から Amazon Aurora に移行するには
1.mysqldumpを使ってエクスポート
2. mysqlimportを使ってAuroraにインポート

逆でも同じコマンドで1時間ぐらいで終わるらしい。
PostreSQLの場合はpg_dumpでエクスポート、pg_restoreでインポートできます。
[参考]Amazon Aurora のよくある質問

SSLでつなぐときは--ssl-caのオプションを忘れずに。



用語の整理

「この2つの用語、違いは何?」「同じものはどれ?」のコーナー。

・インバウンド通信:受信
・アウトバウンド通信:送信

・スケールアウト:分身増加
・スケールイン:分身減少
※AutoScalingと関連性が深い

みたいなキーワードベースで用語の違い(対義・類義的なもの)を見ていきます。
試験でキーワード拾えたら後は選択肢から絞れるようにするために。

1. AWS Trusted Advisorの5項目
・コスト最適化
・セキュリティ
・パフォーマンス
・フォールトトレランス(耐障害性)
・サービス制限

アクセス制限や可用性はセキュリティグループ・NACLや別の監視サービス使ってください。


2. Kinesisサービスの種類
Amazon Kinesisとはトリーミングデータをリアルタイムで収集、処理、分析するためのもの。
Youtube動画配信みたいなことしたり連携して機械学習やモニタリング・分析したい時に。

・Data Stream
 ・LambdaやEMRなどのアプリと連携してストリームを実現
・Firehose
 ・S3やRedShiftなどのストレージに保存して分析用に使う
・Data Analytics
 ・SQLやJavaでデータストリームを分析

後ろに繋がってるサービスが異なるのが肝。
Analyticsは常に末端でDataStremはEC2などの揮発性ある方でとっておき、
Firehoseはビッグデータとして保管しておきたい場合に使います。



3. プロビジョニングツール
・Elastic Beanstalk
 ・コードデプロイ
・CloudFormation
 ・YAMLやJSON、一番カスタムできるプロビジョニング
・OpsWorks
 ・ChefやPuppet使ったりOSの設定見直したい時に。

CloudFormationのパラメタは【CloudFormation入門1】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築
を読んで頭の中でまとめた。



4. CloudWatchのデフォルトメトリクス

CloudWatchは、AWSリソース、アプリケーション、オンプレミスのモニタリングツール。
【AWS】CloudWatchでの監視項目まとめがわかりやすい。

カスタムメトリクスが対象なのはEC2やEBSが中心で、「ディスク利用率」はカスタムメトリクス。
CPU使用率はデフォルトメトリクス。

RDSやS3だとそもそもカスタムメトリクス利用できなかったりメトリクスなかったりします。
CloudWatchサービス一覧が参考になります。

ざっくり解説すると、
・CloudWatch Metrics
 ・各AWSサービスからメトリクスを収集できる
・CloudWatch Alarms
 ・メトリクスを監視して通知したり、トリガとしてLambda実行やEC2の再起動もできる
・CloudWatch Logs
 ・ログの監視・S3への保存・アクセスなど
・CloudWatch Logs Insights
 ・ログ可視化
・CloudWatch Dashboards
 ・別リージョンもまとめて監視できるよ
・CloudWatch Events
 ・AWSサービスのトリガをもとに別のAWSサービスでイベント処理。
  ・ピタゴラスイッチ的なことも(やろうと思えば)できそう


5. Auto Scaling
・Launch Configuration
 ・インスタンス起動にあたっての設定、スペック、セキュリティ設定
・Auto Scaling Group
 ・どこのサブネットやELBの下なのか、最小台数は?
・Auto Scaling ポリシー
 ・どのタイミングで増減させるか?のフラグ
  ・アラームが発生したときや猶予時間など

AutoScalingがスケールインするときのルーチンは以下の通り。

1. 起動してる台数が最も多いAZ
2. 起動設定(Launch Configuration)が最も古いもの、一番長く起動してるもの
3. 次の課金タイミングが最も近いインスタンス

6. S3の整合性

・新規追加は即時反映(PUTでもできるよ)
・更新・削除(PUT,UPDATE,DELETE)は結果整合性
 ・結果さえ合ってればいいので、一貫性は保証されてない

→NFSとしては利用できず、静的WEBサイトホスティングなどに便利


7. NATゲートウェイとNATインスタンス

公式ドキュメントより。
NATインスタンスとNATゲートウェイの違い

・NATインスタンス
 ・実体はEC2インスタンスのこと
 ・プライベートサブネットにあるS3やDynamoDBからのアクセスをできるようにする
 ・S3やDyanamoDbなどにパッチをあてられる
・NATゲートウェイ
 ・NATインスタンスがSPOF(単一障害点)にならないように、EIP割り当ててNATインスタンスと似たことできるようにする
 ・インスタンスでなく、GWなので停止できない→料金が発生し続ける

つまり、
【冗長化や障害対策などの運用管理】
 NATインスタンス:必要
 NATゲートウェイ:マネージドサービスなので不要
【セキュリティグループ】
 NATインスタンス:使える(実体がEC2なので)
 NATゲートウェイ:使えない(ネットワークACLで制御する)
【料金】
 NATインスタンス:EC2の料金体系に従う
 NATゲートウェイ:NATゲートウェイの料金体系に従う


ということになります。

8. ゲートウェイ関連用語

・VPCピアリング接続
 ・VPC間の接続に使う。ネットワークアドレスが違うAWSアカウント同士でも通信可能
・VPCエンドポイント(AWS Privatelink)
 ・NATデバイス不要で、インターネットを経由せずにプライベート接続可能
 ・NATの場合はインターネットと接続する違いがある
・Direct Connect
 ・オンプレ鯖とAWSを専用線でつなぐ
・バーチャルプライベートゲートウェイ(VGW)
 ・Direct ConnectやインターネットVPN接続用ゲートウェイ
・インターネットゲートウェイ(IGW)
 ・VPCリソースからインターネットにアクセスするためのもの。セキュリティグループで0.0.0.0/0を設定するとインターネットに自由に繋がるよ






・その他メモ
 ・S3のライフサイクルについて
  ・移行アクションと有効期限アクションがある
 

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|






Last updated  2019.08.30 06:58:13
コメント(0) | コメントを書く


2018.08.07
カテゴリ:サーバ
今日はリソースの最適化など、コストパフォーマンスの向上周りについて書いてみる。

インスタンスタイプ

AWSのインスタンスタイプについて一度まとめてみたいなーと思ったのでまとめてみます。

基本的には
r5.xlargeみたいな構成で成り立っていて
[インスタンスファミリー][バージョン].[インスタンスサイズ]の法則性があります。

インスタンスファミリーによって得意な分野が異なり、
バージョンが新しいほど高パフォーマンス・低コストなモデルが提供されています。
インスタンスサイズが大きいほどスペックが高いですが、その分コストもかかります。

バージョンは公式ページみて最新のバージョン調べるのが最速です。
3だけでなく、3aみたいなものもあります。(汎用型とか)
a型はインスタンスストレージがEBSのみで、加えてdシリーズ(adやdnシリーズ)になるとSSDも選択できます。
ただし、ストレージ最適化系(I,D,Hから始まるもの)はデフォルトでSSD使ってそうです。

現時点では旧世代インスタンスもサポートが継続されており、EBSインスタンスなら途中でインスタンスタイプをコンソールから再起動時に変更できます。
データのスナップショットを取って変更するだけ。
ちなみに現時点の無料インスタンスはt2.microが対象。


まずはインスタンスサイズについて。
大きな数の単位(億,兆,京...無量大数...)みたいな感じで覚えていくといいかと。
服のサイズみたいなものだと。
RSで覚えたいならブロとかの「DX, LX, GDX, XLS」みたいな感じで。
大体のインスタンスタイプは以下の大小関係で定義されてる模様。
nano < micro < small < medium < large < xlarge < 2xlarge < (N)xlarge < metal
vCPU数はlargeなら2、xlargeなら4、2xlargeは8、4xlargeなら16(個)と増えていきます。



そして、インスタンスファミリーについて。
適切なインスタンスを選択できるよう、パフォーマンス測定してからの選定が推奨されてます。
(開発環境ならこのサイズまででいいけど、本番環境ではこのサイズ欲しいよね、みたいな。この辺りはサービスの規模やトラフィックを見積もって予算を立てる必要あり。)

細かいバージョンの違いまで訊かれることはないと信じたいですが、基本的には「新しくて用途とサイズが適切なもの」をレコメンドすればいいんじゃないかな。
計算問題が出るとするなら、1つ上の資格試験(SAAじゃなくてSAPのほう)な気がする。



汎用
* ウェブサーバやコードリポジトリなどのバランス重視タイプ
* a, t, mからスタートする
* aやmは定常パフォーマンス、tはバーストパフォーマンスが可能
* mシリーズなら追加料金なしのデフォルトでEBS最適化が使える

* バーストパフォーマンス:普段はベースラインだけど、混んでる時は高いパフォーマンスを出してくれる
* ただし、ゲームで言う所のブースト(CP)ゲージみたいにチャージした後でないと使えず、一定量消費するとベースラインまでしか発揮できなくなります。


バーストできる状態



バーストするクレジットが足りない状態

EBS最適化インスタンスとは、EBSのパフォーマンスを最大限に発揮するための仕組みです。
具体的にはプロビジョニングIOPSをEC2インスタンスで利用できます。
また、EBSとEC2間の通信を専用ネットワークにすることで他のトラフィックに妨害されることなくEC2やEBSのパフォーマンスを維持できます。
※通常だとEBSもネットワークも同じ帯域を使うため、ネットワーク側の通信量が膨大だとパフォーマンスが落ちます。


コンピューティング最適化
* コストの高いCPU処理に特化
* Cインスタンスタイプが該当
* C5nタイプになるとネットワークも強化される

主にヴバッチ処理や科学シミュレーション、専用ゲームサーバや機械学習など負荷の高い処理を行うのにおすすめ。


メモリ最適化
* 大容量のメモリに特化
* r,x,zから始まる
* 768GBのメモリ、なんてスペックもある

高パフォーマンスDCやリアルタイムビッグデータ解析、ERPなど、多数のデータを同時に処理するのに向いてます。
量子コンピュータみたいだなぁ


高速コンピューティング

* GPUやFPGAに特化
* ハードウェアアクセラレータを使用してるので、グラフィック処理が得意
* F,P,Gから始まる

ストレージ最適化

* I,D,Hから始まる
* I/O性能が高いリソースが欲しいならこれ
* NoSQLデータベース(CassandraやMongoDB)やインメモリDB,ElasticSearchなどに向いてます


------------------------------

他にも、以前紹介したストレージオプション(汎用 (SSD)、プロビジョンド IOPS (SSD)、マグネティックなど)も選択できます。

EBSについても最適化インスタンスが存在してC5、C4、M5、M4、P3、P2、G3、および D2 の各インスタンスの場合、この機能はデフォルトで有効です。



実運用ではELB+AうとScalingによる可変サイズのリソース供給を行ったり、
SQS(Siple Queue Service)による非同期分散処理を用いたバッチ処理や
Kinesisによるストリーミングデータの収集・リアルタイム解析なども併用したりします。

リソースの使用状況・請求金額はAWS Cost and Usage Reportによる詳細リポートや分析をしてくれます。この辺りは請求額を算出するAPI呼んでWEBサーバ立てて計算、なんてこともできたりする。
実運用していてコストに問題があるか、最適化できる所がないか探す時はTrusted Advisorを使ったりします。
具体的には、以下の観点でチェックしてくれる
* 14日間で使用率10%・ネットやI/Oが5MB以下が4日以上のような使用率の低いEC2インスタンス
* EC2におけるリザーブドインスタンスの最適化
* 稼働中のEC2に関連づいてないEIP

他にもELBやEBS、RDSなどのリソースをリリース(解放)することで最適化が図れることもあります。


ということで、今日は設計にあたってのリソース最適化周りの話でした。


   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|






Last updated  2019.08.29 16:37:01
コメント(0) | コメントを書く
2018.08.05
カテゴリ:サーバ
ユースケースから勉強してみる。
試験でも問われるのは最新の知識や運用に関する情報だろうし、そもそも純知識が問われるだけの試験なら受けるメリットって少ない気もする。
最近のAWS資格の問題は実運用に伴う問題も多かったりするので、勉強目的で読み漁ってみるのもよさげです。
特に、「サーバ設計のベストプラクティスってあるの?」「運用に必要な構成とかってどう考えればいいの?オンプレでもいいんだけど」などなど、他のGCPなどにも活かせるサーバサイド設計の勉強にもなるので、AWS SAAで勉強しておくのはオススメ。
個人的にはGCP派



・ビットコイン採掘用に悪用されて請求書180万
AWS で不正アクセスされて凄い額の請求が来ていた件
・ SECRET KEY を見える場所に貼っていた事が原因で大量に処理が回される
・基本的には自己責任だが、AWSさん側は最大限サポートしてくれる
・免除申請なるものが必要らしい

対策としてはReceive Billing Alertを手動でオンにして異常検知をしたり、
侵入テスト(※事前申請が必要)を行ったりなどなど。
ちなみにマルチテナント環境(公園のようにみんなでリソース使うタイプの環境)で動いてるインスタンス(t1.microやm1.smallなど)は侵入テストに対応してません。

通知にあたってSNS(ソーシャルのほうじゃなくて、Simple Notification Serviceっていう通知システムの方)を使って「HTTP/S、Eメール、SMS、lamdb」などを経由して通知するのもおすすめ。メールやHTTPが人気そう?
後はCloudWatch使ってAPIの監視をするのもオススメですね。
メッセージの暗号化にはAmazon ATS証明書(Amazon Trust Service)を使うのが推奨されてます。
ATSってのは認証局(CA)サービスで、無料でデジタル証明書を使えます。
同じタイミングで「AWS Certificate Manager」(ACM)の提供も始まったらしく、SSL/TLS証明書も対応してるそうです。
SQS使ってキューにメッセージを蓄えて送信すると可用性の高いサービスが作れそうですね。





・途中でアップロードを中止した場合
 S3へマルチパートアップロード(API実行)を行った場合大容量のオブジェクトをパートという単位(IDは1~10000、連続していなくてOK)に分けてアップロードできます。
このアップロードの途中で中止した場合、料金が発生しないって話。
同時に途中までアップロードしたデータはS3側からも削除されます。
中止にあたって、バケットライフサイクルルール(<LifecycleConfiguration><Rule>...)のDaysAfterInitiationフィールドにて○日以内にアップロードが出来なかった場合中止する、といった指定もできたりします。

ちなみに、これを実行するときに打ち込むコマンドはput-bucket-lifecycleと呼ばれていますが、サンプル用のlifecycle.jsonを使ってコマンドが動作するかテストすることもできるんだとか。
サンプルの設定を上げてget-bucket-lifecycleで取得すれば設定が入ってるかテストできるそうです。
putで設定を置いて、getでless的なことをする感じ。

マルチパートアップロードには制限もあるので、色々押さえておくとよさげ。
オブジェクトサイズが5TBで、1000や10000が上限ってことを覚えておく感じで。
パートのサイズは5MB~5GB。(最後のみ5MB未満)分割するには最小でも5MBのファイルが必要なので、動画とかアップロードするとき向けか。
40GBのピカチュウ画像をやり取りするには便利そうですね。(ここでのピカチュウはBox使ってますが)

上限系って、AWS サービスの制限に大体のことがまとまっているんですね。
こういう資料を頑張って書いてるカスタマーサポート担当の方がいるんだろうなあ、と。
(APIの仕様を調べてドキュメントに書き起こす人)




【おまけ】オンライン上で見つけたサンプル問題達
解き甲斐のある問題をまとめてみた。
・【徹底解説】AWS 認定ソリューションアーキテクト - アソシエイト資格のサンプル問題を解いてみよう
解説がわかりやすい。
Amazon AWS 資格取得のための演習問題集(完全無料、オリジナル)
問題数がなんと238問。知識チェックとしてオススメ。

AWS認定ソリューションアーキテクト・アソシエイトを1週間で合格した必勝法【2019年最新】
一読しておくとAWS試験対策になりそう。
要点絞って勉強するのがコツ。派生する知識はたくさん押さえておき、それ以外の分野は経験から解いた方がよさげ。
後、1ヶ月は見積もったほうが良いかと。

AWS クラウドサービス活用資料集
スライド使って勉強したい人向けに。

AWS 認定ソリューションアーキテクト – アソシエイト
WEBにもサンプル問題があります。
サンプル問題の解説を作られた方もいます。


今のところ、教科書を何周もする+WEBで調べて情報を補足して体系的にしていく
ってプロセスがオススメ。
教科書に出てきてる単元ごとに自分の中でまとめノート作ったりして勉強してまーす。


問題調べるにあたって試験には3パターンあり、
Solution Architect
 ・可用性のあるシステムが設計できるかどうか
 ・AWSのベストプラクティスに沿ってEC2,VPC,S3,Glaciar,Elasticache,ELB,RDS,EBSなどを正しく構成できるか、説明できるレベルになってるか
Developer
 ・AWSを利用したプロダクトの開発
 ・SDKかAPI名が問われやすい
Sysops Administrator
 ・上記2つを組み合わせたような分野


初見ならSolution Architectが一番とっつきやすい気がする。
Developerは実運用経験がないとAPI名やパラメタ名覚えてないとキツいし、SysOpsが総合力が問われるので。

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|






Last updated  2019.08.26 05:40:02
コメント(0) | コメントを書く
2018.08.04
カテゴリ:サーバ
ちょっとサーバ1台立ててみる、ってことで、10分間チュートリアルを試してみる。
こういうのは動画のほうが映えるのですが、今回は文字で書き起こし。
「AWS立ててみた 実況プレイ」なんてジャンルの動画、Youtubeかどこかで探せばありそうな予感。





まずはLinux仮想マシンの起動から試してみる。
手順はここ

Amazon Machine Image (AMI) には何十種類(これ書いてる時点で38)ものスタンダードなのがあるのですが、今回はAmazon Linux AMIを選択。

AMIの起動には以下の2種類があります。
・Amazon EBS-Backed
・Instance Store-Backed

Amazon EBS スナップショットから作成される場合はEBS-Backed、
Amazon S3 に格納されたテンプレートから作成される場合はInstance Store-Backed
EBS(Elastic Block Store)はEC2の永続化ストレージとして利用されます。
これ使うことでEC2が再起動してもOS上のデータが保存された状態で利用できます。

EBSにも色々と種類があって、安い順に並べると(※東京リージョン2018の場合)
EBSマグネティック:旧世代のHDD
Cold HDD(ct1):アクセス頻度低いワークロードなどで利用。
スループット最適化HDD(st1):ビッグデータやデータウェアハウス、ログ処理などでHDDを使いたい時
汎用SSD(gp2):コスパのいいSSD(大体これ)
プロビジョンド IOPS SSD(io1) :低レイテンシ、高パフォーマンスのSSD
 ・10,000(IOPS)が求められるならこれ。(MongoDBとかCassandraをDBとして採用したい時など)

こういう比較一覧って、押さえとくと試験とかで役立ちますよね。
対比とか言い換え、定義的な所を整理するだけでも用語問題は対応できたりなど。

当たり前だけど、HDD<SSDだよね。
話を戻して、AMI起動するなら「Amazon EBS backed」のほうが起動が速いのでおすすめ。
無料枠だとt2.micro(可変 ECU, 1 vCPU, 2.5 GHz, Intel Xeon Family, 1 GiB メモリ, EBS のみ)が使えるとのこと。
12ヶ月間、1ヶ月750時間までマイクロインスタンスを試せます。
現行の全インスタンスタイプがIPv6をサポートしてた。

家の鍵を作るかのようにSSHキーを作成。.pemをダウンロード。
.sshフォルダを作成。


雑学助かる

公式ではGitbash推奨されてるけど、個人的にはWSL使ってるのでsudoつけて起動。
(sudo無しだとPermission Denyされちゃう)

まるでVMwareで仮想マシンを立てるかのように簡単に起動できた…。
終了はexitコマンドです。
最後にシャットダウンして完了。お疲れ様でした。

この手順使うとWordPress使ってブログ立てたりすることもできます。
Webアプリ立ててAPIベースでアクセス、赤石の民衆の裏側でnode.jsサーバ立ててシミュレータを作ってやろうか…なんてこと考えたりしましたが、アクセス数からして費用が洒落にならない感じがしたので遊びでやるのはやめた。
そのうち、超絶マイナーページでAWSにサーバ立てたりするかもしれない。そのうち。

次のコースではAWSのプロビジョニングツールの1つであるElastic Beanstalkが指定されてた。かなり起動簡単だったし、更新も手順通りにいけた。
後はドメイン名の取得なんてのもチュートリアルとしてあった。
つい最近だと、reiwaドメイン(令和)とかは取得合戦になってそう。笑

AWSの10分チュートリアルにはより実践的な項目(テキストの感情を分析、動画分析、深層学習など)もあるので、その辺りのチュートリアルも受けられます。
大体の汎用フレームワークはAMIにひっついているので、それ使うだけでも使い甲斐がありそう。



以上、10分チュートリアルを体験してみたのコーナーでした。

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|
10分ノシショボテン






Last updated  2019.08.25 23:42:06
コメント(0) | コメントを書く
2018.08.03
カテゴリ:サーバ
つい最近(といっても2019/8/23)にAWSの東京リージョンで接続障害がありましたね。

原因は過熱だったとのことですが、ShingleAZが止まっていたとのアラートが飛んできていたそうで。
MultiAZにしてればパフォーマンスや色々な面で劣化起きたとしても大丈夫だった可能性があるとかないとか。
ということで、今日は設計的な話とかをメモ。

・複数階層サブネットの話
 ・基本的に1~3階層サブネットとあるが、DDD(ドメイン駆動設計)に即して考えるとわかりやすそう。
  ・1層ならルータとEC2のやりとり
  ・2層ならルータからWEB(EC2的な)のにいって、ルータ経由でDBへ
  ・3層ならELB経由したりBastion(踏み台サーバ)経由してEC2やDBにアクセスする

ELBがコントローラ層、EC2がビジネス層、DBがDAO層と考えるとそのままかなーと。

Bastion(要塞)は管理者によるメンテナンスのためのSSHの受け付けとかを行うためのサーバ。
管理者用サーバとも言う。ユーザが使うAPIから直接アクセスできても困るものね。
なので、「セキュリティグループの設定」によって踏み台サーバの権限を調整できるようにし、証明書などによる認証もあると良いかと。(BASIC認証ぐらいはつけといたほうが内部犯防止にはよさげ)

[参考]
20160929-bastion-3
[5分で]AWSベストプラクティスにのっとって踏み台(Bastion)サーバを構築する – Linux編 –

[参考][5分で]AWSベストプラクティスにのっとって踏み台(Bastion)サーバを構築する – Windows編 –
(ネットワーク周りの用語、整理したさ…)


この辺りはAWS CloudFormation(CFn)用のJSON/YAMLなどを記述して自動的に環境構築・起動できるようにすると良いかと。
証明書の設定とかリモートデスクトップ(RD)の設定が楽になりそう。

CFn の構文とプロパティ(EC2インスタンス)
ref. http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/template-formats.html

基本は以下の入れ子構造です。詳細はこちら

Resources
 {リソース名}
  Type
  Properties
   {各プロパティ}

設計のコツは以下。
・踏み台は2つ以上のAZに配置(今回みたいな障害に対応できるように)
・踏み台はパブリックサブネットに配置
・踏み台専用のEIPやセキュリティグループ・FWを設置
・ポート番号はSSHなどの22番のみを許可

※パブリックサブネット
・インターネットゲートウェイ(IGW)をVPCやルートテーブルアタッチすることでインターネットとの出入りができる
※プライベートサブネット
・VPCやDirectConnet間での通信のみの場合はこっち
 パブリックサブネットとは逆に、IGWの設定などはしません。

DirectConnectを使うとAWS VPCと自社のデータセンターをセキュアに繋げます。
但し、VPNよりもコストがかかる模様。
VPNはコストが安い分、インターネットを経由する故の通信品質の安定性は下がったりします。
管理用やメンテナンス経路(Bastion)とかならこっちでいいかも。

一方、VPC同士の接続でいいならVPCピアリングを使ったルーティングが良さげ。
EC2からS3やDynamoDBにアクセスする時などに便利。

他にもAWS Private Linkなんてのもあります。
こいつはVPC EndPointやNetwork Load Balancer(NLB)辺りに相当して、VPCエンドポイントとも呼ばれたりします。

使い分けとしては、以下のケースでPrivateLinkを使います。
独自サービスにクローズドな環境で通信をしたい場合
Direct Connect接続経由のエッジツーエッジルーティング
VPCのCIDRブロックが重複している

他にも、以下のようなことができます。
・インターネットに出ずにEC2からKinesisに繋ぐ
・EC2やELBのAPIをインターネットに出ずに叩く

つまり、ネットワーク構成上VPCでは困難な場合はPrivateLinkを使える可能性を検討すると良さげです。
通信経路の可視化や構成図がシンプルになるメリットもPrivateLinkにはあります。
ただ、NACLなどで詳細な制御が必要ならVPCピアリングのほうがおすすめ。

VPCピアリングの台数上限は50、VPCエンドポイントの上限は20らしい。
[参考]:AWS PrivateLinkの使い方と注意点 ~VPCピアリングとの使い分け~

ちなみに、WindowsUpdateやyum、apt-getなどでインターネットにアクセスしたい場合はNATゲートウェイのルーティングをさせることでネットサーフィンできたりします。
NATゲートウェイの反対が踏み台サーバに当たります。VPNとかDirectConnet、あるいはセッションマネージャとか使いながらネットからプライベートサブネットにアクセスする感じ。
IGWは双方向にネットを張れますが、NATゲートウェイや踏み台・セッションマネージャだと片道しか張れないですね。
つまり、「NATゲートウェイを踏み台サーバ」なんてのはできないです。



今日はAWSの障害から派生してネットワークの設計周りのお話などについてまとめてみた。
実運用的なことも取り扱っていきたいですね。
画像をもっと配置したい、、

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|
3日坊主…?






Last updated  2019.08.25 22:55:47
コメント(0) | コメントを書く
2018.08.02
カテゴリ:サーバ
気になったトピックのまとめなどなど。
体系的にまとめられた情報を参照したい場合は教科書など買って読んだ方が100倍勉強になります。

AWSの中では「AWS Well-Architected フレームワーク」というのがあって、「Design for Failure」という考え方が推奨されてます。
平たくいうと、「どこが故障しても復旧できるようにしようね」ってこと。
以下の5本柱が中心となってます。

1. セキュリティ
2. 信頼性
3. パフォーマンス効率
4. コスト最適化
5. 運用性


この「コスト最適化」ってのが試験問題の新しい方(2018~)ではよく出るらしく。
いわゆる「その場で考えさせる問題」ってのが新試験からは出る用に。
ポイントは
* 使わないリソースは止めましょう
* 規模の経済(スポットインスタンスなど)が効いてくる
* データセンターへの投資が必要最小限になる
* 監視システム(CloudWatchなど)を活用してリソースの分析を行う
* DB保守やコンテンツ配信(Cloud Front)のマネージサービスを使う


などなどで管理していくそうです。
この辺りの設定失敗するとクラウド破産なんていう事態が起きるそうです。

例えば、S3(Simple Storage Service)の1つであるAmazon Glacierでクラウド破産しないためになどなど。
こいつは「低頻度アクセスで」「大量のデータを保存したい」時に使えるのですが、いわゆるアーカイブ的な役割が強いんですよね。
なので、バックアップサーバとして使って、いざというときにフルダンプしようとするととんでもない請求金額が飛んできます。

料金表を見ると、

* 無料枠は1 か月につき 10 GB(スタンダード取り出し)
* 使用した分だけ支払い

以下、標準設定の場合は

* 0.01USD/GB
* リクエスト 1,000 件ごとに 0.05USD
* 標準だと復旧するときに3~5時間かかる
* (迅速)だと1~5分、大容量クエリの場合は5~12時間もかかる


などなど。具体的な料金部分はリージョンによって異なるので覚えなくてもよさそうですが、概算として。
つまり、Glacierを使う時は「監査データの保管」や「ログの保管」みたいないざというときに出したいデータを置いておく感じです。

glacierは「氷河」って意味らしく、氷河みたいにデータを安全な場所に保存しておくイメージってことですね。

こういうユースケースは勉強になる。実際に会社で運用してます、個人で使ってます、みたいな人のほうが有利なのは間違いない。
赤石の民衆もやってみたさあるけど、リクエスト数からしてgit上で管理できる範囲なのでやめた。
(AWSで運用するってなったら消費金額分回収する何かを考えないといけなくなるので)

ちなみにS3は以下のような時に使います。
* ストレージ
* コンテンツ配信や保管
* プロビジョニング(運用自動化)のconfig保存して実行(ChefやDB接続変数など)
* ログ補完
* バックアップやバージョニング、災害対策
* 秘密情報の保管


最後の秘密情報の保管がユーザ側でセキュリティ対策として必要そう。
セキュアなアクセス方法を実現するためには、以下の要件があると良いです。

* バケットポリシー
* どのファイルに対してどのAPIを誰から許可/拒否するかの設定用
* JSONベースで記載(20KBまで)
* 参考
* 制御できる権限一覧
* ユーザポリシー
* IAM ユーザーポリシーの方
* ロギング
* CloudTrail(運用・監査支援ツール。監査ログ保管庫)使ってAPI単位で何をGETやPOSTしたのか記録

s3:GetObject(常に最新のデータが取れる権限)やs3:PutObject(データ更新)などがよく使いそう。大体はDBやLinuxシステム系と似た感じのに+Objectや+Bucketした感じ。

セキュアファイルにアクセスさせる時は、
「S3にアクセス権限が付与されたIAMロールをEC2に付与して、S3にアクセスする」
が推奨。

IAMユーザの方のアクセスキー・シークレットキー(共通鍵みたいなもん)を使うと鍵が漏れた時にどこからでも誰でもアクセスできてしまう。
IAMロールとは、「AWSサービスやEC2上のアプリに対してAWSリソースの操作権限を付与する」もの。
EC2(サーバ)にも付与できるので、ユーザ→EC2→S3って流れでアクセスできるようになる。
ちなみにS3にはパブリックアクセス(誰でもアクセスできる機能)がありますが、機密情報には使えない、、

認証情報(クレデンシャル)を取得するAPIはcurl -w '\n' http://169.254.169.254/latest/meta-data/iam/security-credentials/<role name>っていうのがあるそうな。
これをEC2内から叩いてjqでパースしてあげるとよさげ。
これ叩いて出てくるのは今有効なクレデンシャルで、Session情報みたいに内容が入れ替わることがあります。

参考:クレデンシャルの適切な扱い方 ー AWS SDK for Goの場合










今日はこの辺で。ネットワークや権限周りも勉強してこんな感じのノートでまとめようかな。

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|






Last updated  2019.08.20 06:18:19
コメント(0) | コメントを書く
2018.08.01
カテゴリ:サーバ
需要は後から考えていくスタイル

AWSの勉強したこととかをまとめるページにしようかなーと。

教材としてこれ使ってます。

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ

教科書として。公式サイト読んで勉強するとなると、どうしてもとっつきにくいのでこの手の本を1冊用意したほうがよさげ。
申し込み手順から始まり、システム寄りな話まで結構幅広く書かれています。
真正面から読んで全部理解しようとすると骨が折れる印象があるので、
1周目 問題を読む → 前のページから答えを探して解く
2周目~ 実際にAWS触ってみて、辞書として使う

ぐらいの感じがいい気がする。
こういう使い方したいので、個人的にはKindle版で買っといてよかった。
電子書籍読むための端末なら家に大量にあるので。(少なくとも3つ(!?))


最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本

練習問題が多いのでおすすめ。特に実務に近い問題が多い印象。
テクニカルな問題演習も他所併せてしておくと万全な対策になるんじゃないかと。
個人的には最初の1冊として取り組みやすかった。
問題数が合計100問以上あるので、実戦形式で練習したい人向けに。


AWS WEB問題集
大量に問題が載っている。無料なら50問程度、有料会員なら650問以上。
システム寄りな問題も色々あるので、1回解いてみる価値はありそう。


合格対策 AWS認定ソリューションアーキテクト -アソシエイト

全体像を把握するのには使えそうだけど、2018~2019年現在となった今ではやや古い情報の印象。「AWSって何ですか」レベルなら読み甲斐ありそう。


後は公式のオンライン動画「Black Belt」も講義形式がウケ良い人にとってはオススメ。
自分は問題演習中心で行きたかったので、それに適した本選びました。
この辺りは人によって学習方法が違ってくると思います。


本を買ったら全体像の把握。
AWSの最新サービスにみるクラウド市場の次なる“激戦区” に掲載されているような図をもとに全体像を把握。
AWSの抽象アイコンは公式サイトから落としてこれます。
システム設計図として使う分には自由に使ってよさそう。
パワポとかにも貼り付けやすいPNG形式のファイルもあったりする。

このアイコンの中で主要サービス系は教科書読みながら一通り体系立てていく感じで。

例えば、ゲームプラットフォーム on AWSみたいな使い方をしたりする。
初見だとここに書かれてる用語が何なのかわからないと思う。そういう時は教科書とかで勉強してから読みなおすとわかるようになってくる。




Qiitaみたいなテクニカルなブログ書くのに適したサービスでもよかったけど、たまにはブログで書いてみたくなったので。
ブログをノート代わりに使うスタイルで勉強してみようかなと。
(IAMってのはLinuxにおけるuseraddみたいなユーザの追加と似たシステムで、100万人単位ならAWS STS使って一時的な権限振った方がいいよー!みたいなことを書くのが大半になるかもしれない。笑)


ちなみに、試験の流れがかなり特殊なので一読しといたほうがいいです。

(K)ってマークのついた試験会場が該当します。
AWS SAA再認定のために5日間頑張ったことによると、(K)がついてない会場なら普通に受験できるので、個人的にはそちらの受験環境推奨です。

事前に試験会場にアクセスしやすいか調べておくのもよさげ。
試験会場は東京都内なら10か所程度選べました。


AWS認定 PSIシステムでエラーが起きた場合の問い合わせ方法にあるように、システムトラブルが色々な箇所で起きる可能性もあるので、何か困ったことがあったら問い合わせしてみたほうがよさそうです。

試験の規約とかも読んでおきましょう。
一般的な試験とは少し違った印象受けたので。TOEFL受けてる人からすると割と普通なのかな?
(TOEFLの試験会場受験と似たような空気になるんじゃないかなと思ってます)





勉強してった内容のノートとかは次の記事からで。

   ww
 ,,#´ω`#,,
 #´・_・`#ノシ
 #´・ρ・`#ノシ
 #´・▽・`#ノシ
 #´・w・`#ノシ
 #´・ω・`#ノシ
 #´・∀・`#ノシ
 #´・Д・`#ノシ
 #´・-・`#ノシ
 #´・ε・`#ノシ
 #´・ヮ・`#ノシ
 #´・⊇・`#ノシ
..[..===..]
 |ノシショボテン|
 |_\3500_|






Last updated  2019.08.20 05:09:08
コメント(0) | コメントを書く

全7件 (7件中 1-7件目)

1


Copyright (c) 1997-2021 Rakuten, Inc. All Rights Reserved.