コンユウメモ

作ったガラクタとか、旅行とかの話

ちょっとしたTipsも面倒臭がらずにQiitaに書き残しておく修行

最近実装しているときに調べたことを面倒臭がらずにTipsをQiitaにちょこちょこまとめている。仕事で調べたことを仕事終ってから業務情報を取り除き、不足分を付け足しリライトして公開している

こういうことを着実に一歩一歩、クンフーを積んでいくと、 1年後に自分で同じことを調べて自分の記事がヒットして感謝を感じるはずである。

それに長いQiitaの記事はたくさんストックされたりするけど、検索にヒットして役に立つのは小さいTips何だよね。 ついでにソフトウェアエンジニアの採用をする目線で見ると、 Qiitaのコントリビュートの数が多いと「おおすげー」とは思うけどちゃんとどういう事書いてるか中身も見てから判断するからね。

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

AWSを学び直した際の備忘録

Udemyのセールで購入した下記の講座が大変良かったので、紹介するとともに学び直した内容の備忘録を残しておくことにした。なのでこの記事で特定のAWSの機能の設定の仕方などは書いてはいない。Linuxの基本的なことはわかっている人がAWSを体系的にどうやって学んだのか、どういう理解の仕方をしたのかを知ることができるという内容だ。

手を動かしながら2週間で学ぶ AWS 基本から応用まで

作者の方の紹介ページ www.ketancho.net

こちらの副読本とした。 比較的新しい本であり上記の作者の方も作者に名を連ねているところから、用語の説明の仕方などにUdemyの講座とブレが少なく理解しやすそうなのでこちらを選んだ

Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)

Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

ついでに上記のブログでおすすめされていたサーバレスの本も買った

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

はじめに

何年も前からAWSを使うことはあっても体系的に学んでいなかったし、必要なところだけ設定していた。特にIAMやVPC、ELBあたりは雰囲気で使っているところがあった。 AWSのメジャーなサービスをザクッと把握して何ができて何ができないのかインデックスを作っておきたかったというわけだ。

AWS学び直し備忘録

初期設定

アカウント作成

  • Rootユーザは基本使わない
  • サービスごとにアドミンユーザを作るのが良い
  • 各アドミンユーザから、適宜利用者ごとにIAMユーザを作る
  • 最初はAdminAccessのユーザを作る。このアカウントでRDSやEC2も作る

IAMユーザ

  • 利用者ごとに作る
  • 最初はAdminAccessのユーザを作った。このアカウントでRDSやEC2も作る
  • IAMユーザはIAMユーザ用のサインインリンクからログインする
    • IAMのマネジメントコンソールのダッシュボードにURLが書いてある
  • IAMロールとIAMユーザIAMポリシーは別のもの

CoudTrail

  • AWSの操作ログを保存する
  • データの操作、S3バケットを作ったとか
  • S3に古いイベントを残することができる
  • 証跡の作成する
    • CroudTrailのバケットの置くところを設定する

Cloudwatchの設定

  • 請求アラートの設定をしておく

AWS見積もり方

EC2

セキュリティグループ

  • ファイアーウォールのこと
  • 開けるポートを選ぶ、HTTPとかSSH向け
  • あるセキュリティグループがついているEC2からのみ通信を許可するというような設定ができる

    キーペア

  • SSHのキーペアのこと
  • SSH接続するのに使う

AMIとスナップショットの違い

  • AMI => ディスクイメージ OSとかまるごと
  • スナップショット => EBSつまりハードディスクのバックアップ

EIP

  • ec2の固定IP
  • 注意、動いていないインスタンスに紐付いてないと微妙に課金される。紐付いていれば課金されない

AWSネットワーク

リージョン

  • 地域 アヴェイラリティゾーン(AZ)
  • データセンターのこと
  • ap-northeast-1a、1c, 1dは別のデータセンターと考えて良い
  • なのでリージョンのAZだと、東京リージョンにあるデータセンターである。東京リージョンは現在3つのAZがある

VPC

  • 独自のネットワークだけど、AZをまたがって作ることができる。マルチAZにする。負荷分散やディザスタリカバリ対応
  • サブネット、外部にアクセス可能なものや、アクセスさせないものに分けることができる
  • サブネットはAZをまたげない
  • WEBサーバはマルチAZで作って可用性を上げるのが基本
  • CIDR
  • プライベートサブネット内にあるEC2に接続するのにNAT GWを使う。
  • NAT GWはパブリックサブネット内に置く、昔はWebサーバを踏み台にして接続していたような気がする
  • ACLとIAMと(セキュリティグループも若干)はやや混同している、機能がかぶっているところがある気がする。
  • パブリックサブネットとプライベートサブネット
    • パブリックはDMZ的なEC2のWebサーバ置く
    • プライベートはRDSやバッチサーバを置く
  • ルートテーブル
    • パブリックサブネットはインターネットに出ていくのと、入ってくる設定
    • プライベートサブネットの場合は、VPC内の通信だけなら許すようにする
  • UserData
    • EC2立てるときに高度な設定にあるテキストエリア。シェルスクリプトを実行する
    • EC2のオートスケールはAMIを読み出すのでここでAnsible的なことを頑張らなくても良さそう。実務ではあまり使わなそう
  • VPC内のサーバのIPアドレスはプライベートIP

NAT GW

  • プライベートサブネットの踏み台サーバ的なもの
  • SSHで双方向通信ができる
  • EC2に設定したセキュリティグループでSSHのポートを潰してしまわないように注意

ネットワークACL

  • セキュリティグループと似ている
  • サブネットのごとにポートアクセス制限を書けることができる
  • セキュリティグループとの違いは
    • サブネットごとにまとめて、開放ポートの制限などを書けることができる
    • in/outの通信の両方の設定する必要がある

RDS

  • RDMSのことMySQLPostgreSQLなどなど
  • パブリックアクセシビリティを有効にするとグローバルIPアドレスが振られる
    • 多分サブネット側でネットワークの口が閉じているとアクセスできない。通常RDSはプライベートサブネットに置くので、パブリックアクセシビリティをOnにすることはなさそう
  • フェイルオーバーがうまくいったかどうかをどうやって確認するかまだよくわかってない
  • マルチAZの設定は明示的にAZを選択できない?2つのAZのどちらがマスターにするか指定できない?Webサーバと同じAZに置きたいよね?

ELB

  • ロードバランサ
  • オートスケールもここで設定する
  • SPOF => 単一障害点 のこと。これを作らない構成にするのが良い
  • ALB => アプリケーションロードバランサ、ELBの種類の一つ。基本的にこれを使えばOK
    • URLごとに振り分けたりする。Nginxのリバースプロキシでやらせるようなことをやる
    • アクセスの負荷分散もALBでできる
    • サーバのヘルスチェックを行える
    • ヘルスチェックでコケたらメール通知(Slackも)できる ELB + CloudWatchアラームを使ったEC2サービス監視プラクティス | DevelopersIO
    • AutoSclingは2−6に増やせる。また時間を設定して自動的に増やすことができる(テレビ対応とかの場合)
  • ELBはサブネットの外側、VPCの入り口のイメージ
  • ALBの設定画面はAWSのWebコンソールのEC2のメニュー内のロードバランサところにある
  • ALBのターゲットグループの設定でぶら下がっているサーバのヘルスチェックのステータスがわかる
  • ALBのヘルスチェックは、繋がらなくなると切り離され、切り離されている間もヘルスチェックはされて、healtyになったら接続されるようになる
  • オートスケール機能は、ターゲットグループの設定によってできるようになる
    • AMIが対象になる。プログラムのコードを最新にするようなときはどうするのだろうか。CodeDeployの設定でAMIを作ってどうにか対応できそう AWS CodeDeploy を Amazon EC2 Auto Scaling と統合する - AWS CodeDeploy
    • オートスケールの機能もEC2のメニュー内にある
    • オートスケール設定はターゲットグループに紐付いている
    • ターゲットグループは、ALBに紐付いている
    • オートスケールでスケールインとスケールアウトの両方できる

S3

  • よく使うファイル置き場、ログも置ける
  • 静的ホスティングもできる
    • エラー画面を作る
    • ALBの設定でヘルスチェックが全滅の場合にこちらを向ける設定ができるっぽい
    • 表示するエラーは404とか500番はアプリ側で出す気がするけど、504番エラーとかかな?
      • バケットポリシーの設定ができない。設定しようとするとアクセス拒否になる場合。
        • パブリックアクセス設定の、新規のパブリックバケットポリシーをブロックするのチェックを外して更新する必要がある
      • バケットにパブリックポリシーがある場合、パブリックアクセスとクロスアカウントアクセスをブロックする のチェックが有ると参照しない。このあたりの4つの項目の組み合わせがいまいちピンときてないのでここにかいた2つのチェックを外せばよいだけかどうかは検証していない

Route53

  • おなじみDNSサーバ、他にも接続先をS3やELB、CloudFrontにエイリアスでできる − DNSフェイルオーバー機能で、ELBのサーバが動かないときにソーリーページを表示する
    • Failoverは落ちたときに切り替えができる
  • 他にもELB(かな?)の振り分けができてA/Bテストができる、カナリアリリース(一部の人にだけなにかする)ができる

IAM

  • 権限周りの機能。これが結構ややこしい
  • IAMユーザは個別のユーザ、メールアドレスに紐づく
  • IAMグループはユーザをまとめて紐付けると権限が付与されて便利
    • RDSの参照、編集権限とか、ECSの削除権限など
  • 担当者ごとにIAMユーザを発行して作る。
    • 運用をイメージすると、IAMグループのアプリ開発者向けのIAMユーザ= アカウントを渡す。
  • IAMロール
    • サーバに権限を付与する。他のAWSサービスへのアクセス権とか
    • 旧来的には、IAMユーザのアクセスキーとシークレットキーをプログラムの環境変数などに埋め込んでいた。
      • 実行時にaws-cliでアクセスキーやシークレットキーを入力しなくて良くなる
  • IAMポリシー
    • IAMグループやIAMユーザに紐付ける権限のセット
  • EC2インスタンスの設定画面のアクションからIAMロールの割当/置換から設定できる
  • ベストプラクティス
    • AWSにアクセスする人はひとりひとりIAMユーザを作る。IAMグループでいくつかのグループを作る。
    • 権限は必要最小限にする

AWS CLI

  • awsのウェブコンソールをターミナルからコマンドラインで操作できるようにするもの
  • ~/.awsディレクトリのconfigureにawsのアクセスキーやシークレットキー情報が格納されている
  • 複数のIAMユーザでcliを操作したい場合は aws configure --profile NAME でNAMEの名前のユーザを切り替えながら作業ができる。
  • 基本的にリファレンスを見ながらやる
  • バッチ処理なんかで使いそう
  • やったことのある事例は、本番環境のS3にあるバケットを差分コピーして、ステージング環境にデイリーで移行するバッチ

Cloudwatch

  • メトリクス(リソース状況を計測するツール)
  • 金額がかかりすぎた場合のアラートや、CPU使用率の通知はSNSを通じてメール送信したりする。slackに通知も投げれる。
  • makarelなどを併用しているところが多いイメージがあるがそれはなんでなんだろ?
  • Cloudwatchlogはpaper trailのAWSの版

CloudFront

  • CDN
  • コンテンツのパージが遅いというが2018年末だと現状はどうだろう?
  • Route53の設定して名前解決してみたい
  • Cloudfrontを正面においた場合ユーザ独自情報、動的コンテンツはどうなるのかな
    • ビヘイビアの設定で、コンテンツごとにキャッシュする時間を決められる。URLごとに設定可能、precedenceで優先度設定できる
  • HTTP2にブラウザが対応していたら、そのプロトコルで返したり、gzで圧縮するのもここでできるらしい
  • TTL 0に下だけだとうっすらキャッシュされるので、きちんとキャッシュしない設定をする必要がある
  • キャッシュの削除は昔は結構かかってるイメージが合ったが最近は5分ぐらいらしいまじで? Fastlyは一瞬だけども

ElastiCache

  • ElasticCacheじゃなくてElastiCacheなのね。
  • memcacheかredisか選べる。memachedはマルチスレッドで、redisはシングルスレッド。多分価格を抑えたかったらセッション管理ならmemcachedの方が良いかも
  • セッション管理とキャッシュ処理、キューイングなどをまとめてRedisでやることが多いかな

SES

  • メールサービス
  • バウンス処理や到達ステータスの管理は未だにないみたいだ。この機能作るのだるかったから、SendGridに頼ったほうが生産性が高そうだ。Sendgridの方が携帯電話会社のドメインに届きやすいとか聴いたことあるけど現状どうだろうか

SQS

  • マネージドのキューイングサービス、RailsでつくつるならRedisでSidekiqを使ったほうが再試行や管理画面の構築上楽かもしれない。 -SQS向けにsyoryukenというgemがある
  • SQSを使うならLambdaを噛ませたほうがクラウドネイティブっぽくて良さそう。キューならLambdaとRDSの組み合わせでも筋が悪くない

CodeCommit

  • Gitのホスティングサービス。PRにも対応しているようだが、Githubに人気が集中していて人気がない
  • Issue管理をGithubでしないでTrelloやJira、Backlogなどでやるなら選択肢としてありかも

CodeBuild

  • CIサービス、CodeCommitだけではなく、githubやbitbucketにも対応している。ただし人気がないCircleCIに人気が集中している。なぜだ

CodeDeploy

CloudFormation

  • インフラの自動構築サービス。AWSを構築するサービスをしている会社は概ねこちらを用いいるようだ
  • ymlやjsonVPCやEC2などもろもろ設定できる。ymlの方がコメントが書けるので良さそう
  • 同様の機能にHashiCorp社の製のterraformがある
    • 両者を比較する記事もあるが、CloudFormationの弱いところは2018年現在ではなさそう
    • terraformもCloudFormationのファイルに変換する機能があればイイんじゃないのかなー知らんけど
  • CloudFormationで設定した構成を手動で変更した場合に検知できる機能(ドリフト監視)があるので便利。最近の機能
  • Kubernetesを展開するサービスEKSもCloudFormationで設定できるようだ。
    • EKSはサブネット内の設定をするのかな?この辺はよくわかってないAZ間をまたげそうだけれども
    • ざっくりCloudfrontの方が低レイヤーと考えておけば良さそう
  • キーペアの生成はCloudFormationではできないっぽい。aws cliかブラウザのコンソールで生成する

感想

  • VPC, IAM, ELBなど普通のLinuxにはない設定を理解できた。もともとLPIC のレベル2までは持ってたのでその差分が理解できた
  • CloudFormationを簡単に作れる仕組みがあればいいのにね。構成のノウハウやコードを共有するサイトやサービスがあればいいのにAWSが公式にやればいいのになー
  • EC2や普通のRDSを使った構成で作るのはセキュリティパッチなど考えないといけないから、そういう構成なら中規模なアプリならHerokuなどのPaaSのほうが楽かな
  • インフラに関してはAWSのすげぇインフラエンジニアに任せられるサーバレスでアーキテクチャ構成を作っていきたい

Udemyレッスンのリンク

手を動かしながら2週間で学ぶ AWS 基本から応用まで

副読本

Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド

#2019年やりたいことリスト を作ってみた

キューティクルロン毛マンワタナベさんを真似して酒飲みながら来年やりたいリストを作った blog.nabettu.com

仕事

  • AWSもうチョットデキルようになる
  • サーバレス
    • サンプルのアプリを作る
    • サーバレスで仕事をする
    • サーバレスの構築だけする仕事をする
    • サーバレス関係の登壇をする
    • サーバレスの技術顧問をする
  • エンジニアコミュニケーションの講座を開く
  • リモートワーク
    • リモートワーク絡みでブログを書く、技術書展への頭出しのため
    • 技術書展でリモートワークでの仕事の仕方の本を書く
    • リモートワーク関係でもうちょっとブランディングする
  • 1ドルでいいから日本円以外の仕事をする
    • 海外のクラウドソーシングのしごとの調査
    • スキルセットと鑑みて必要なら伸ばすスキルを伸ばす
  • 仕事でモダンなiOSを書く
  • デザイン、フロントエンド、バックエンドが疎でありコミュニケーションしやすいアーキテクチャを提示する
  • ストック型のビジネスにも挑戦する
    • 気負うとやる気が無くなるので失敗する前提で気楽にやる
    • ナレッジを貯めるのが目標
    • クローズドベータで学びのサービスを検証したい
  • 自分のHPをリニューアルする

学習

  • 今年も英語学習に力を入れる
    • セブに短期留学する(数年ぶり二回目)夏前まで
  • Rubyの資格を取る(夏)
  • 情報処理安全確保支援士の資格を取る(秋)
  • AWSの資格を取る(冬頃)
  • iPadだけで開発できるよう工夫する
  • DDDとクリーンアーキテクチャの本を読む
  • コンピュータの古典の積読を潰していく
  • オンライン勉強会を開く
  • Meetupに参加して英語でなんか発表する
  • Touch Designerを勉強してインスタレーションを作る
  • STEAM教育のAのArtについて学びを深める

生活

  • 北海道にセカンドハウス計画を進める
  • ワーケーションを増やす
    • シンガポール、マレーシアを旅行してプラナカン文化を追う旅行に行く
    • マレーシアのモスクも見に行きたい。
    • ポルトガルのサグレス岬に行きたい。深夜特急を読み直して、物語で行ったのはそこで、ロカ岬と勘違いしてたから
    • アメリカの東海岸から西海岸へ旅行する。そんで「アメリカはでっかい田舎なのさ」と言う
  • 久々に格闘技を習いに行く
  • 確定申告を速攻終わらせる
  • そろそろ税理士との契約を考える
  • 投資信託に毎月機械的にぶっこむ
  • SNSの依存度を下げる
  • Maker Faire Tokyoなどに子供やITリテラシーの低い人でも楽しめるものを作って出す
  • 毎月確定申告の準備をする
  • プラスチックオーシャン対策や食糧問題にも何か小さいアクションを起こしたい