継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS CDK が GA されたのでツールのアップグレードと関連情報をまとめる

タダです。

AWS Cloud Development Kit(以下、CDK)が GA しましたね!バージョンが v1.0.0 になりました.

公式ブログ aws.amazon.com

GitHubのリリース github.com

過去記事でいくつか AWS CDK の記事を扱っています.今回は GA されたことでバージョンがアップグレードされたので AWS CDK CLI のアップグレードと AWS CDK に興味ある方が見るべき各種ドキュメントや関連 GitHub リポジトリの情報をこの記事でまとめたいと思います.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

AWS CDK CLI のアップグレード

AWS CDL CLIAWS CDK でデプロイするアプリや CloudFormation テンプレートを実環境に展開するために必要なツールです.このツールのバージョンアップを過去にやっていたので今回もその手順に沿ってバージョンアップグレードします.

docs.aws.amazon.com

関連記事

sadayoshi-tada.hatenablog.com

アップグレード前のバージョンは 0.33.0になっています.

$ cdk --version
0.33.0 (build 50d71bf)

ncu で確認した結果, 1.0.0 にアップグレードするためのコマンドを確認できたのでアップグレードしました.1.0.0 にアップグレードできました.

$ ncu -g aws-cdk
[====================] 1/1 100%

 aws-cdk  0.33.01.0.0

ncu itself cannot upgrade global packages. Run the following to upgrade all global packages:

$ npm -g install aws-cdk@1.0.0
$ npm -g install aws-cdk@1.0.0
/usr/local/bin/cdk -> /usr/local/lib/node_modules/aws-cdk/bin/cdk
+ aws-cdk@1.0.0
added 1 package from 1 contributor, removed 1 package and updated 28 packages in 12.756s
$ cdk --version
1.0.0 (build d89592e)

なお,初めてインストールするという場合は下記のドキュメントが参考になります.

docs.aws.amazon.com

AWS CDK の各種ドキュメントやリポジトリ

GA したのでこれから AWS CDK に触っていく人も多いかと思います.そこで確認できている各種ドキュメント情報をまとめます.

AWS ドキュメント

他のサービスと同様の公式ドキュメントです.まずはこちらから何ができるのかを確認されると良いと思います.

docs.aws.amazon.com

AWS CDK リファレンス

API リファレンスとサポートされているプログラム言語ごとのサポートページへ誘導してくれるリファレンスページです.

docs.aws.amazon.com

GitHub リポジトリ

開発のリポジトリです.改善要望はこちらから投げることができます. github.com

サンプルプログラムのリポジトリです.手始めに動かしたい人におすすめです. github.com

まとめ

GA された AWS CDK CLI のバージョンアップグレードと AWS CDK に関するドキュメントやリポジトリを紹介しました.僕も今回のリリースを受けてもっと使い込んでいきたいと思いました.締め切りになっていますが AWS CDK ミートアップが開催されるため国内の事例もこれから増えていくかと予想しています.乗るしかないこのビッグウェーブに!という気持ちで勉強していきたいですね😄

awsclouddevelopmentkitcdkmeetu.splashthat.com

CloudWatch Logs Insights で大量なログ分析も手軽に行う

タダです。

運用フェーズになるとトラブルシュートや定常運用時にログを確認することがよくあると思います.僕もそんな時に最近は CloudWatch Logs Insights をを使うようにしています.CloudWatch Logs Insightsは CloudWatch Logs に保管されたログに対してクエリを発行してログを表示したり、クエリの結果をグラフに出すことも可能な機能です.

aws.amazon.com

これまでは CloudWatch Logs の画面から検索することも可能でしたが,CloudWatch Logs Insights の登場によって検索で正規表現や条件をつけたりすることで検索しやすいです.今回は CloudWatch Logs Insights を使うにあたって必要なクエリの使い方と料金を整理します.

クエリについて

クエリのコマンド

クエリには1つ以上のクエリコマンドを Unix 形式のパイプ文字をで区切って定義可能で,使えるコマンドは以下の6種類です.

  • fields : 1つ以上のログフィールドを取得する
  • filter : ログフィールドを1つ以上の条件に基づいて絞り込む
  • stats : ログフィールドに対し集計計算(sum,avg,count,min,max,percentile)を行う
  • sort : 昇順,降順でログイベントをソートする
  • limit : クエリで返されるログイベントの数を制限する
  • parse : ログフィールドからデータを取り出す

参考情報

docs.aws.amazon.com

サンプルクエリ

実際にどうやってクエリを定義していいか,をすぐにわからない人も安心してください.以下のようなサンプルクエリが用意されています.CloudTrail は利用されている方も多いかと思うので,まずはこちらから始めてみるのも良いかもしれません.

  • Lambda
  • VPC Flow Logs
  • Route53
  • AppSync
  • CloudTrail
  • 一般的なログ

参考情報

docs.aws.amazon.com

利用料金

料金は,クエリごとに走査したログデータの量に対してかかるのですが,GB あたり $0.005 になります.ログ容量に応じた課金体系になっています.

まとめ

今回は, CloudWatch Logs Insights の基本であるクエリコマンドの種類とサンプルクエリ,利用料金をまとめました.今の所はログをソートしたり,filter で条件を絞ったりなどを使っていますが,もっと使いこなせてログ分析を得意になっていきたいです.

DevLoveX で カックさんの発表を聞いて感想と今後の技術ブログに活かすことを振り返る

タダです。

6/22,23に開催された DevLoveX に参加してきました.参加したのはブログメンタリングでお世話になっていたカックさんが登壇されるため,発表を聞いてみたいと思ったからです.ネットでメンタリングしてもらったので,リアルでお会いしたかったのもありますw devlove.wixsite.com

発表資料や補足のブログはカックさんのブログで既に公開されているので,この記事ではお話を聞いての感想と今後の技術ブログ活動に活かしていきたいことを書きます.

カックさんの登壇後のブログ

記事は下記リンク先です.なお,登壇概要も合わせて引用文として載せます.

アウトプットを楽しむエンジニアが増えています.特に技術ブログを書くエンジニアが増えていますが,習慣化をして書き続けることや,読みやすい記事を書くことに課題を感じるという声を多く聞きます.そこで,技術ブログを習慣化して楽しく書けるエンジニアを増やすために「ブログメンタリング」という活動をしています.約1年半のブログメンタリング経験を整理し,技術ブログのコツとメンタリングのコツをお話します.

kakakakakku.hatenablog.com

カックさんの発表資料

発表を聞いての感想と今後の技術ブログに活かしたいこと

発表を聞いての感想

  • カックさんのいうアウトプットは「URL で誰でもアクセスできて,検索可能な情報を作り出すこと」,「Public URL-ize」と言語化されていたが自分の中でもちゃんと言語化しようとハッとさせられました.
    • 因みに,自分の中でのアウトプットの定義は「自分が理解したことを言語化もしくは図解化して第三者(未来の自分も含む)に公開すること」と定義しました.アウトプットすることが大事だと思っていたけど「どうして大事か」を考えることを飛ばしていたなと発表を聴きながら気づかせていただきました.
  • 習慣化のためには例外を作らないことの大切さを改めて痛感しました.特定期間のみバーストして燃え尽きたら元も子もないですもんね.
  • 仕事で忙しいから書けない,趣味の予定があるから書けない等の逃げ道を作らず,ブログを書く時間を作り,習慣化していくためのメンタリングで,「傾聴」と「どうするべきか」をメンティーに思考・言語化させる部分は自分が社内のメンターやっていた時にできてなかったなと反省しました.特にメンティー言語化させる部分ができていなかったです.
  • 余談ですがカックさんにブログ書けなない理由をいうのは, @t_wada さんにテストコード書けないと言えないでしょ?って有名な AA を思い出しましたw

    🦁テスト書いてないとかお前 @t_wadaの前で同じこと言えんの?

今後の技術ブログ活動に活かしたいこと

今後の技術ブログ活動に活かしたいことが大きく3点あります.

1. ブログの専門分野の確立と役に立つ記事を作成していくこと

今僕が目指しているのが「自身の理解を整理して詳しくなる」と「誰かの役に立ちたい」部分です.これはブログメンタリングをしてもらっていた頃より意識していたことです.メンティー卒業後も自分の関心分野の記事は書いていますが,役に立つ記事のためには「ちゃんと伝わる記事になっているか」をもっとこだわっていきたいです.

2. 継続的なブログネタの整理を行う

記事を作るにあたって無計画に記事を書こうと思っても進まないためブログメンタリング期間中にネタ出しをして,そのネタ帳を今も使っています.ただ,最近ネタの棚卸しや整理を怠っていると感じたので発表を聞いた日に見直ししました.この活動を週1から見直す癖をつけていき,1.の目標の実現に近づいていきたいです.

3. ブログを楽しんで書き続けるためのセルフコントロール

改めてブログを楽しんで継続していけるよう自己管理していきたいです.ホッテントリTwitter 等で反応をもらえるのは本当に嬉しいですし,ブログを書き続けてきてよかったと心から思えます.この感覚を継続していけるように,1.と2.の実現のために忙しくても眠くても時間を捻出し,書くための自己管理をやっていくぞと改めて思いました.

まとめ

DevLoveX でのカックさんの発表を聞いて感想と今後のブログ活動に活かすたいことをまとめました.発表を聞いてスゴいと言われる人は日頃から積み上げてきたものがあるからスゴいと唸られるんだなと感じました.カックさんは12年間ブログを書き続けてきたと話をされていました.僕は継続してまだ1年とちょっとなのでまだまだですが,積み重ねて少しでもカックさんのように近づいていきたいと思います.

最後はポエムぽくなってしましましたがw,カックさんの新規メンター募集が今かかっているので気になる方は「ブログのライザップ」と言われるブログメンタリングに応募してみてください!ブログをもっとよくしていきたいと思っている人は必見です!

関連記事

カックさんのブログメンティー期間を振り返った記事 sadayoshi-tada.hatenablog.com

ブログメンティー同士で集まった時のレポート記事 sadayoshi-tada.hatenablog.com

「Effective DevOps」オンライン輪読会 第6回開催レポート

タダです.

challenge-every-month の Slack メンバーで 「Effective DevOps」のオンライン輪読会を毎週開催中です.

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

開催概要

方針や輪読会の概要は @kojirock さんがまとめてくださっているので参照ください.

kojirooooocks.hatenablog.com

過去の開催レポート

これまでの開催レポートは以下の通りです.

sadayoshi-tada.hatenablog.com

kojirooooocks.hatenablog.com

kdnakt.hatenablog.com

kdnakt.hatenablog.com

担当章について

今回の範囲は9章分になります.9章からは4つの柱の2つ目の柱である「アフィニティ」の話になります.「アフィニティ」は酒の名前からきた言葉で,親近感や親密度を表す言葉です.「アフィニティ」がチームに与える影響を掘り下げていくのがテーマとなりました.

資料

資料はこちらです.

gitpitch.com

所感

  • アフィニティ」に必要なのはお互いを理解し,チーム,組織,企業と強力な関係を構築すること
    • お互いを理解するためにオープンで自由にコミュニケーションを取り,信頼を置く等様々な要素が必要になる
  • 今いる人だけでなく,未来に参画する人にも「アフィニティ」の向上するよう継続的なモニタリングや改善が必要なのはソフトウェアと一緒だと感じた
  • 組織の目標達成のために個々人やチーム間の目標の違いを理解し、乗り越える必要がある

まとめ

第6回目の輪読会で扱った資料と所感を書きました.次回が本全体の半分まで読んだことになります.残り半分も3人で走り切りましょう!💪

次回

次回は @kojirock さんの担当です.担当章が10章分になります.

ケース別 VPC ピアリングの実装の考慮点

タダです.

複数のサブシステムを設計,実装する時に VPC ピアリングを使って相互にネットワーク疎通可能にすることがあると思います.僕も VPC ピアリングを使ったネットワーク設計に関わってきました.VPC ピアリングは VPC 間の連携には欠かせいない機能ですが,他の AWS サービスと組み合わせる時に注意すべきことがあると感じたので紹介したいと思います.

参考情報

VPC ピアリングの基本 docs.aws.amazon.com

サポートされてない VPC ピア接続設定 docs.aws.amazon.com

FAQ aws.amazon.com

20190313 AWS Black Belt Online Seminar Amazon VPC Basic

www.slideshare.net

他の AWS サービスと組み合わせる時の注意点

今回は,僕が業務で遭遇した VPC ピアリングを他の AWS サービスと組み合わせて使うときに感じた注意点をケース別に3点まとめます.

Case1. EFS をピアリング越しでマウントする場合

EFS を VPC ピアリング経由でマウントしたい要件があった場合,EFS のエンドポイントを DNS 名前解決ができなくなります.対策として Route53 のプライベートホストゾーンとリソースレコードセットを使って EFS マウントターゲット IPアドレスを定義する必要があります.

プライベートホストゾーンとして、「fs-xxxx.efs.ap-northeast-1.amazonaws.com」を定義し、A レコードとして EFS の IPアドレスを定義するような形です.

別の VPC で EFS マウントポイントに DNS 名前解決を使用することはできません。EFS ファイルシステムをマウントするには、対応する可用性ゾーンのマウントポイントの IP アドレスを使用します。また、DNS サービスとして Amazon Route 53 を使用できます。Route 53 で、プライベートホストゾーンとリソースレコードセットを作成して、別の VPC から EFS マウントターゲット IP アドレスを解決できます。

参考情報

docs.aws.amazon.com

Case2. Route 53 プライベートホストゾーンを 別アカウントのVPC ピアリング経由で利用する場合

Route 53 のプライベートホストゾーンを 別アカウントのVPC ピアリング経由で利用したい場合の設定は AWS マネジメントコンソールから直接行えません.というのもプライベートホストゾーンと関連づける VPC は同一アカウント内であれば Route 53 の管理コンソール上より参照可能なのですが別アカウントの VPC は参照できないため AWS CLIなどで設定が必要になります.

参考情報

docs.aws.amazon.com

docs.aws.amazon.com

この記事では AWS CLI の設定例を書きます.設定作業は2ステップで完了します.

1. Route 53 プライベートホストゾーンが存在するアカウントで create-vpc-association-authorizationを実行する

まず,別アカウントの VPC をプライベートホストゾーンに関連付けるためのリクエストを送信することを送信する許可を プライベートホストゾーンが存在するアカウントの権限でcreate-vpc-association-authorization実行します.

$ aws route53  create-vpc-association-authorization \
--hosted-zone-id <プライベートホストゾーンの ID> \
--vpc <別アカウントの VPC ID>

2. 別アカウントの VPC ピアリングが存在するアカウントで associate-vpc-with-hosted-zoneを実行する

次に別アカウントの権限で associate-vpc-with-hosted-zoneを実行します.

$ aws route53  associate-vpc-with-hosted-zone \
--hosted-zone-id <プライベートホストゾーンの ID> \
--vpc <別アカウントの VPC ID>

Case3. VPC ピアリング越しのエンドポイントを DNS 名前解決したい

RDS のエンドポイントなど AWS のマネージドサービスは DNS 名前解決を行なってアクセスする必要があります.その際は, VPC ピアリングのオプションで DNS 名前解決を有効化して対応します.

オプションを有効化したい VPC ピアリングを選択してチェックボックスを有効化して保存すれば DNS 名前解決オプションを有効化できます.簡単ですね! f:id:sadayoshi_tada:20190614083424p:plain f:id:sadayoshi_tada:20190614083535p:plain

参考情報

docs.aws.amazon.com

まとめ

業務で直面した VPC ピアリングの他の AWS サービスと組み合わせる時に注意すべきと感じたポイントを3点まとめました.

VPC ピアリングは大規模システムになればなるほど利用機会が増えるサービスのため,気に掛けるポイントは把握しておく必要があります.この記事で紹介しきれてない考慮点があればまたこの記事を更新かけていきたいと思います.