プログラマでありたい

おっさんになっても、プログラマでありつづけたい

2018年の振り返りと2019年の目標

 あけましておめでとうございます。今年もよろしくお願いします。毎年恒例となってきているので、正月大幅に過ぎましたが、昨年の振り返りと今年の目標です。2018年の主な活動は、出版2冊と雑誌寄稿2回、後は職務上の役割変更でした。

6,7,8冊目の本の出版


 まず出版ですが、6冊目の本でAWS本の第三弾として、Amazon Web Services 業務システム設計・移行ガイドを2018年1月に出版しました。また、最初のAWS本を改訂版して、Amazon Web Services パターン別構築・運用ガイド 改訂第2版 を3月に出しました。そして、クラウドエンジニア養成読本も著者の一人として執筆しました。

 Amazon Web Services 業務システム設計・移行ガイドは、マルチアカウントでAWSをどう使いこなすかとか、オンプレとVPCの接続をどうするかといった、実際の企業内の利用に即した使い方を解説しています。書いた当時では、こればベストという手法だったと思います。が、2018年12月のAWS re:Inventで、複数のアカウントからVPCをシェアするShared VPCが出たり、プレビューながらもマルチアカウントでセキュリティ管理するControl TowerやSecurity Hubが出てきました。ということで、アップデートが必要だなという状況です。でも、基本的な考え方は今でも充分通じると思います。今年は、これを英語化したいなと目論んでいます。

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

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

 クラウドエンジニア養成読本は、AWS・GCP・Azureという3大クラウドを取り扱う野心的な書籍です。ただ、カスタマーレビューにある通りAWS成分多めです。私は、特集1の「ゼロから学ぶクラウドの世界 〜クラウドの現在、そして未来はどうなる?」という部分の担当で、クラウドを取り巻く現状、主要ベンダーとその位置付け、最近の潮流、さらにはエンジニアはクラウドとどう向かい合うのかということをつらつらと書いています。
 メインのテーマとしては、コンテナ化・サーバレス化がアプリの可搬性を高めて、結果としてマルチクラウド化が進むという予想を書きました。2018年の流れを見ていると、たぶん大きくはずしていなかったと自画自賛しております。

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

  • 作者: 佐々木拓郎,西谷圭介,福井厚,寳野雄太,金子亨,廣瀬一海,菊池修治,松井基勝,田部井一成,吉田裕貴,石川修,竹林信哉
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/03/14
  • メディア: 単行本
  • この商品を含むブログを見る

 AWSの最初の本も改定して、自分が書いたAWS本がAmazonのクラウドのランキングに3冊並んだのはちょっと嬉しかったです。また、それぞれ何度か一位になれました。

f:id:dkfj:20180322064951j:plain

雑誌寄稿


 今年は1回、日経クラウドファーストに寄稿しました。AWS Migration HubとSnowBallの話です。正直、移行関係の実務はツラミが多いので楽しくないのですが、Snowballの実体験に基づくハマりどころは書ききれたかと思います。専門誌なのでクローズドな世界なので、今年はもう少し一般の方が目にするような所でも書きたいと思います。

ブログ


 2018年は16本のみでした。2017年の18本とほぼ同様です。ブログのアクセス数は、286,847なので前年比2017年は228,420ページビューと2016年に対して25%増です。 検索流入は安定して入ってきているので、質を高めた記事を月2本くらいは書いていきたいものです。

f:id:dkfj:20190114170627p:plain

2018年の目標に対しての採点


 2018年の目標は、これでした。

  • 本を2冊書く ⇒ ○ 2017年末に書いてたのがメインだけど、とりあえず3冊出版したので良しとしよう。
  • Kindle本を書く ⇒ ☓ 今年こそ。完全に自分でコントロールする本を書いてみたい 
  • ブログ ⇒ △ 目標比70%ほど。安定的に記事を書いたら実現できそうということは解った 
  • 英語ブログ ⇒ ☓ 全く忘れてた。これ、2019年の重点目標
  • 資格試験 ⇒ △ AWSスペシャリスト、とりあえずセキュリティはとった
  • ワークバランス ⇒ ○ 平均残業時間29.46時間。前年度比で削減できたので、今年はもっと減らしたい
  • 健康 ⇒ △ 1万歩/日は、達成できてると思うが、それ以外の睡眠時間・体操が駄目。Fitbitの記録は過去28日までしか見られないので、月ごとに記録しないと駄目だな
  • 3つ目の分野 ⇒ △ AWSとクローラー以外の3つ目の分野。幾つか候補出てきたけど、もう少し模索中

2019年の目標



  • 本を3冊書く ⇒ 一冊昨年書いたのと、もう1冊共著の予定があります。後は1冊、じっくり企画考えて書きます
  • Kindle本を書く ⇒ 4度目くらいの今年こそ。紙の本の目処が立ってるので、今年はこちらに時間を取る 
  • ブログ ⇒ 月2本で、24記事目標。量より質で、400,000ページビュー目指す。 
  • 英語ブログ ⇒ 過去記事の翻訳を含め30記事。grammarly使ってみようかな 
  • 資格試験 ⇒ AWSの日本語で受けられる試験、全部とおる。難関はAlexaとネットワークかな
  • ワークバランス ⇒ 平均残業時間20時間未満。そのためには、やり方変えないとな。
  • 健康 ⇒ 睡眠時間平均7時間。週5で体操。1万歩/日
  • 3つ目の分野 ⇒ 引き続きここを模索
  • 将棋1級 ⇒ 去年、将棋ウォーズ始めました。現在3級で壁にぶち当たってる。殻を破って1級達成したい

まとめ



 子供が大きくなってきたので、家庭周りの用事も増えてきた。使える時間も限られているので、しっかりコントロールして一歩づつこなしていきます。座右の名は、これ

f:id:dkfj:20180616105436j:plain

※田舎に貼ってた張り紙です


See Also:
2017年の振り返りと2018年の目標
2016年の振り返りと2017年の目標
2015年の振り返りと2016年の目標

re:Invent2018 AWSの新サービス群に対する1行所感 その3

 ラスベガス空港で徹夜で遅延する飛行機を迎えながらお早うございます。朦朧とする頭で所感シリーズ第三弾です。

アプリケーションロードバランサー(ALB)のターゲットにAWS Lambdaが選択可能に



ALBの後ろにEC2ではなくLambdaぶら下げられるようになりました。サーバレス化が捗りますね

アプリケーションロードバランサー(ALB)のターゲットにAWS Lambdaが選択可能になりました | Amazon Web Services ブログ

AWS Toolkits for PyCharm、IntelliJ(プレビュー)、Visual Studio Code(プレビュー)



Cloud9以外にもサポートするIDEが追加されました。IDEも宗派分かれるので、宗教戦争の回避できますね。後は、vim/emacsの最終戦争待ちですか

新発表 – AWS Toolkits for PyCharm、IntelliJ(プレビュー)、Visual Studio Code(プレビュー) | Amazon Web Services ブログ

LambdaのRubyサポート



もう無いんじゃないかと諦めていたLambdaのRubyサポート。待ちきれなくてNode.jsやPythonに転向した人も多数とか

re:Invent 2018 / Werner Vogels Keynote / Serverless Updates | Amazon Web Services ブログ

LambdaのCustome Runtime



独自のRuntimeを搭載することが可能に。これによりLinuxのあらゆる言語をサポートすることが出来るようになりました。LambdaでCOBOLが動くと話題の一品

新機能 – AWS Lambda :あらゆるプログラム言語への対応と一般的なコンポーネントの共有 | Amazon Web Services ブログ

Lambda Layers



Lambda Layersにより複数のLambda関数から共有されるコードを持つことが出来るようになりました。つまりはフレームワークが使える。これは革命的なことになりそうですね。

新機能 – AWS Lambda :あらゆるプログラム言語への対応と一般的なコンポーネントの共有 | Amazon Web Services ブログ

AWS Well-Architected Tool – クラウドベストプラクティスのレビューツール



AWSの設計指針に沿っているかツールで検査してくれるようになりました。設計を点数化してくれるというのは凄い。継続的設計評価

新発表 – AWS Well-Architected Tool – クラウドベストプラクティスのレビューツール | Amazon Web Services ブログ

AWS Step Functionsがサポート対象拡大



連携のAWSアプリケーションがLambda以外に、DynamoDBやSQSなど7種類のサービスの連携追加。俺、大歓喜

新発表 – AWS Step Functions が コンピュート、データベース、メッセージング、アナリティクス、機械学習 のサービスと統合 | Amazon Web Services ブログ

Amazon Managed Streaming for Kafka(MSK) マネージド・カフカ



Kinesisあるけど、Kafkaも出しました。KinesisとMSKの関係は、たぶんSQSとAWS MQの関係

re:Invent 2018 / Werner Vogels Keynote / Amazon MSK | Amazon Web Services ブログ

Cloud Map AWSリソースのサービスディスカバリを容易にするサービス



AWSのリソースを論理名で扱えるように抽象化するサービス。抽象的な言い方で申し訳ないですが、これはサービス連携の上で使い所ありそう。

NEW:サービスディスカバリのためのAWS Cloud Mapとのアプリケーション統合 | Amazon Web Services ブログ

License Manager ソフトウェアライセンスの管理サービス



BYOL利用時にライセンスの上限を超えないようにするためのサービス。System Managerと連携して情報を収集し、設定値を超えたらSNSで通知してくれると。それサービスいるのという気はする

新サービス License Manager – ソフトウェアライセンスの管理とライセンスルールの保全 | Amazon Web Services ブログ

AWS App Mesh マイクロサービスのメトリクスを収集



X-Rayのようなアプリケーションの追跡ツール。X-Rayとの棲み分けはと思うが、App Meshの結果をX-Rayに連携できるよとのこと。あとコードに埋め込むX-Rayに対して、App Meshはプロキシ型っぽい

AWS App Meshが発表になりました。 | Amazon Web Services ブログ

EC2インスタンスの休止が可能に



 いわゆるハイバーネートが出来るようになりました。ユースケースは、ぱっと思いつかない

新機能 – EC2インスタンスの休止 | Amazon Web Services ブログ

所感



 後半は、サーバレスバンザイという内容でした。個人的にはStepFunctionsが嬉しいです。

re:Invent2018 AWSの新サービス群に対する1行所感 その2

2018年度版のAWSの新サービス群の1行所感の2回目。Andy Jassyのキーノートがあったので、たぶんこれが本編になります。いやぁ、多すぎて驚き疲れました。
1回目はこちらです。

AWS Control Tower アカウント管理情報の統合



たぶん今回の新サービスの目玉の1つ。Organisation、Service Catalog、Configとかを統合して全体をコントロールしやすくするサービス。マルチアカウントが捗りそう

re:Invent 2018 / Andy Jassy Keynote / AWS Control Tower | Amazon Web Services ブログ

AWS Security Hub セキュリティ情報の統合


Control Towerと並んでもう一つの目玉。GuardDuty、Inspector、Macieやサードパーティのセキュリティソフトからの情報を統合して表示してくれる。これ良さげ

re:Invent 2018 / Andy Jassy Keynote / AWS Security Hub | Amazon Web Services ブログ

AWS Lake Formation データレイクをサクッと作れるサービス



S3を起点にAthenaやRedshift, Sagemaker,QuickSightなどを作っていってくれるウィザードみたいなサービス。数日で作れますという点が気になる

re:Invent 2018 / Andy Jassy Keynote / AWS Lake Formation | Amazon Web Services ブログ

Amazon FSx for Windows ファイルサーバー



Windows向けのフルマネージドなファイルサーバ。EFSの接続プロトコルを追加するという形は取らなかったのだね。

新発表 – Amazon FSx for Windows ファイルサーバー – 高速・完全マネージド型・セキュアなファイルサーバー | Amazon Web Services ブログ

Amazon FSx for Lustre HPC向けの高並列なファイルシステム



HPCから使えるように高並列に対応したファイルシステム

新発表 – Amazon FSx for Lustre | Amazon Web Services ブログ

Amazon Timestream 時系列DB



マネージドな時系列DB。機械学習とかで、時系列に重みを変えていく時に便利なのですかね

re:Invent 2018 / Andy Jassy Keynote / Amazon Timestream | Amazon Web Services ブログ

Amazon DynamoDB On-Demand DyanmoDBのキャパシティの調整を自動に



DynamoDBのキャパシティ調整大変だよね。いい話ありますよ。これ使ったら、自動で調整しまっせ

Amazon DynamoDB On-Demand – 事前のキャパシティプランニングが不要のリクエスト課金が可能になりました。 | Amazon Web Services ブログ

Amazon Quantum Ledger Database (QLDB)



フルマネージドなLedgerデータベース。Twitter上での中の人達のどよめきをみてると、ものすごいサービスなんだろう。

re:Invent 2018 / Andy Jassy Keynote / Amazon Quantum Ledger Database(QLDB) | Amazon Web Services ブログ

Amazon Managed Blockchain マネージド・ブロックチェーン



AWSもブロックチェーンのサービス出さないのと煩く言われて出してやったよという感じなのかも。台帳管理にQLDB使ってます

re:Invent 2018 / Andy Jassy Keynote / Amazon Managed Blockchain | Amazon Web Services ブログ

AWS Inferentia 機械学習の推論チップ



TensorFlowはGoogleが作ったかもしれないけど、実際動いてるのはAWS上が多いんだよ。へいへい!これ使うと、更にめっちゃ安くで高性能になるよ

re:Invent 2018 / Andy Jassy Keynote / AWS Inferentia | Amazon Web Services ブログ

AWS マーケットプレイスで機械学習アルゴリズムとモデルのパッケージを提供



アルゴリズムを売り買いできる市場を作りました

新発表 – AWS マーケットプレイスで機械学習アルゴリズムとモデルのパッケージを提供開始 | Amazon Web Services ブログ

Amazon Textract 文字起こしのOCRサービス



文字起こしのOCRサービス。ただのOCRではなく、インテリジェンスに文字と文字の対応も判断してくれる。日本語、いつか対応してくれると信じています

re:Invent 2018 / Andy Jassy Keynote / Amazon Textract | Amazon Web Services ブログ

Amazon Elastic Inference 後付できるGPU



必要な時に、必要なだけGPU追加できます。(もちろん上限はあるよ)

Amazon Elastic Inference — GPUを利用した深層学習推論の高速化 | Amazon Web Services ブログ

Amazon Outposts オンプレにAWSを!!



VMWare CloudもしくはAWSクラウドと同じAPIが利用可能なオンプレ環境を作れる物理機器をAWSが提供。オンプレのクラウド化ではなく、クラウドがデータセンターに侵食していくという逆のアプローチに

re:Invent 2018 / Andy Jassy Keynote / Amazon Outposts | Amazon Web Services ブログ

Amazon Personalize Amazonのリコメンドシステムをあなたにも



みんな知っているAmazonのリコメンドシステムを下々のものにも使わせてやるで〜って感じかな
Amazon Personalize – すべてのユーザにリアルタイムパーソナライゼーションとレコメンデーションを | Amazon Web Services ブログ

Amazon Forecast – 時系列予測



時系列予想の機械学習サービス。Timestream使ってます。とりあえずFXの予想でもしてみるか
新発表 – Amazon Forecast – 時系列予測を容易に | Amazon Web Services ブログ

Amazon SageMaker Ground Truth



アノテーション(ラベル付け)の自動化サービス。機械学習で何が大変かというとアノテーション。そこを自動化手伝うよというサービス。これは凄そう

新機能 – Amazon SageMaker RL – Amazon SageMakerを使ったマネージドな強化学習 | Amazon Web Services ブログ

Amazon SageMaker RL – Amazon SageMakerを使ったマネージドな強化学習



SageMakerとの棲み分けが、まだ解らない。より便利にした後継サービスという位置づけなのかも

Amazon SageMaker Ground Truth — 高い精度のデータセットを構築し、ラベル付けのコストを最大70%削減 | Amazon Web Services ブログ

Amazon Glacier Deep Archive めちゃ安のアーカイブ・ストレージ


1GBで月0.1円。1TBでも月100円くらい。めっちゃ安いで〜

re:Invent 2018 / Andy Jassy Keynote / Glacier Deep Archive | Amazon Web Services ブログ

感想



 ビジネス的なインパクトとしては、Outpostsが大きそう。そして、実運用面ではSecurityHubとControl Towerが。エンジニアとしてはQLDBに注目ですかね。

1回目はこちらです。

re:Invent2018 AWSの新サービス群に対する1行所感 その1

 2018年11月25日〜30日までアメリカのラスベガスでAWSの最大のイベントであるre:Inventが開催中です。発表が多すぎて訳が解らなくなってきたので、自分なりの解釈で1行所感をつけていきます。まずは、27日午前までです。
※一部、re:Invent開催前に発表されたものも含まれています。また、1行の定義はなんだという問には答えません。

その2も書きました。

AWS RoboMaker



ロボット向けのROS(Robotic Operating System)をベースにAWSの各種機能と強力に統合したサービス。でも、ロボットと言ってもドラえもんじゃないよ。産業用ロボを想像してください。

AWS RoboMaker-インテリジェントなロボットアプリケーションの開発、テスト、デプロイと管理 | Amazon Web Services ブログ

AWS Transfer for SFTP SFTPでS3にデータ転送



 SIerでAWS案件をやっていたら、一度は尋ねられた事があるだろう。「S3でFTPできないの?」と。このサービスがリリースされた事による反応で、その人の素性が解ることだろう

re:Invent 2018 Midnight Madness/ AWS Transfer for SFTP | Amazon Web Services ブログ

AWS DataSync オンプレミスとAWS間の新しいデータ転送サービス



 Storage Gatewayというサービスがあってのう。今は昔の話じゃ(になるのかな)。あと、オンプレ・AWS間の圧縮・高速化のソリューション出してるサードパーティが沢山あったよなぁ。合掌

re:Invent 2018 Midnight Madness/ AWS DataSync | Amazon Web Services ブログ

Firecracker 新しいマイクロVM



LambdaやFargateで使っているコンテナ基盤をサービスとして利用できるようにするよ。OSSとしても公開するよ

Firecracker – サーバーレスコンピューティングのための軽量な仮想化機能 | Amazon Web Services ブログ

Amazon EC2 A1 インスタンス



ArmベースのCPUを使ったインスタンス。いつまで経ってもArmの時代が来ないから、Amazonが自分でCPU作ったわ

Introducing Amazon EC2 A1 Instances Powered By New Arm-based AWS Graviton Processors

AWS Global Accelarator グローバルで利用できるロードバランサ



もうロードバランサーは、GCPの方が凄いと言わせないぞ。(本当に凄いか、まだ解らんけど)
Introducing AWS Global Accelerator

AWS Transit Gateway VPC・オンプレ・ダイレクトコネクトの接続ハブ



AWSは、個人でISPでも開業させたいのでしょうか?
Introducing AWS Transit Gateway

AWS Ground Station 人工衛星を時間貸しできるサービス。正確には、地上の受信の基地局を貸すサービス



ごめん。何言ってるのか、本当に解らない
re:Invent2018 AWS Ground Station が発表になりました。 | Amazon Web Services ブログ

S3 Batch Operations S3内の複数のオブジェクトに一括処理が可能に



数億のオブジェクトにAPIで順次Get⇒処理してると時間と金が掛かるよね。それ一括で出来るよ、S3 Batch Operationsならね

Amazon S3 Introduces S3 Batch Operations (Preview) for Object Management

AWS Amplify Console Amplifyを使って簡単にフロントエンド/バックエンドサービスを作る



ポチッとなで、フロントエンドとバックエンドのサービス、更にGitのリポジトリまで作ってくれる。ちまちまとしたAPI Gateway+Lambdaの設定からも開放される

Introducing the AWS Amplify Console

AWS Resource Access Manager – クロスアカウントでのリソース共有


 アカウント間のリソース共有のコントロール。複数アカウント利用が当たり前になった証左でしょう。

新しい AWS Resource Access Manager – クロスアカウントでのリソース共有 | Amazon Web Services ブログ

Route 53 Resolver オンプレミス-VPCの相互名前解決


 オンプレとクラウドを両方利用するハイブリッド。最大の悩みどころが両者の名前解決。その悩みを解決しやすくしたのがRoute 53 Resolver

New – Amazon Route 53 Resolver for Hybrid Clouds | AWS News Blog

Amazon Aurora Serverless にアクセスが可能な Data API


Aurora Serverlessがサーバレス(Lambda)からアクセスしやすいようにHTTPのエンドポイント作ったよ

Access your Amazon Aurora Serverless Database with the New Data API (Beta)

AutoScalingのPredictive (予測的)スケーリング

 機械学習で作成したモデルをもととする予測ベースの自動スケーリング。自動拡張の設定もAWSにお任せあれ

新機能 – Machine Learning を中核とする EC2 の予測スケーリング | Amazon Web Services ブログ

コンピューティング能力と GPU を増強した Snowball Edge


 内容は、そのまんま。52vCPUと208GBのメモリにGPU。そのパワーを何に使う?

近日登場 – コンピューティング能力と GPU を増強した Snowball Edge | Amazon Web Services ブログ

CloudFormationで、定義と実態の差異検知


 CloudFormationの最大の敵である手作業による直接変更を検知してお仕置きお知らせしちゃうぞ

新 – CloudFormation ドリフト検出 | Amazon Web Services ブログ

AWS System Manager Distributor


Systems Managerが更に発展統合されたサービス。出世魚かよ EC2 Manager ⇒ Systems Manager ⇒ System Manager Distributor

Introducing AWS Systems Manager Distributor

Amazon S3 Block Public Access


うっかりさんの為に、S3のパブリック公開を禁止する機能。アカウントレベルで設定できるので情報システム部門、大歓喜

Amazon S3 Block Public Access – アカウントとバケットのさらなる保護 | Amazon Web Services ブログ

100Gbpsのネットワーク帯域に対応するC5nインスタンス



 ISUCONに対抗して、100Gbps出すためのOSチューニングコンテストをAWSが作るとみた。普通のOSイメージで100Gbps使いきれるのかな?

新機能 – 100Gbpsのネットワーク帯域に対応するC5nインスタンス | Amazon Web Services ブログ

所感

 本編のキーノート前に、怒涛のリリース。明日どうなるんだろう?

その2も書きました。

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

 著者の西谷さんAmazon Web Servicesを使ったサーバーレスアプリケーション開発ガイドを頂いたので読みました。予想以上に丁寧に書いていて、これから本格的にサーバレスアプリの開発をしようとしようという方には、非常にお勧めです。

サーバーレスアプリを取り巻く現状



 最近ではサーバレスという概念自体はだいぶ広まっているのですが、すぐに作れるという部分のみにフォーカスしていることが多いです。解説されている内容も、設計手法というよりサービスの紹介と使いかた、或いはコードの書き方というのが多いです。結果として、どうなっているかというと取り敢えず動くけど、何か問題が起きた時に原因が解らない、対処の方法が解らないということが多いです。また、作った人しか全容を把握していなくて、担当者の異動や転職でニッチもサッチもいかなくなる事態というのを何度か見てきました。

サーバーレスアプリをチームで開発するためには



 じゃぁ、どうすれば良いのか。個人的な見解としては、サーバーレスアプリも個人ではなくチームで開発するための体制を作るべきです。その為には何が必要かというと、標準的な考え方や開発手法です。実はこの部分について、AWSは色々なものを用意しています。例えば、アプリケーションを定義するモデルであるAWS Serverless Application Model (AWS SAM)であったり、フレームワークであるServerLesss Expressがあります。また継続的なビルド・デプロイを可能にするCodePiplineやCodeCommit,CodeBuild,CodeDeployなどもあります。ブラックボックスになりがちな実行状況については、CloudWatchやX-Rayで追跡可能です。
 これらをどうやって使っていけば良いのか、包括的に解説しているのが本書となります。

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



 7章構成となっています。

1章 サーバーレスアプリケーションの概要
2章 Amazon Web Services(AWS)利用の準備
3章 インフラを自動化しよう
4章 Twitterのリアルタイム分析をしよう
5章 写真投稿サイトをシングルページアプリケーションで作ろう
6章 サーバーレスアプリケーションのライフサイクル管理
7章 サーバーレスアプリケーションのトラブルシューティング

 1,2章が概要説明と準備、3〜5章が実践編、6章が運用を見据えてどのように管理をしないといけないのか、7章が障害発生時にどう対処するのかといった内容です。個人的には6章の部分で、SAMや複数環境の利用、CI/CDについてしっかりと解説しているところがポイントが高いです。作ることを優先して、この辺りをおざなりにすることが多いので、少なくとも一度は読んでどうすべきなのかを把握しておくとよいと思います。

本書の特徴



章立ての他に、本書にはもう一つ特徴があります。画面の操作は最小限に、出来るだけコマンドラインで実行している点です。画面が少ない理由としては、AWSのUIは頻繁に変わるのでその対策だと思います。また、それを除いたとしても、実際の開発の現場ではコード固めて画面からアップしてという形ではなく、コマンドからデプロイするという方法に落ち着くと思います。そのあたりを考慮すると、かなり実践的な使いかたに即してよいのではと思います。

感想



 おっさん視点なので、どうしてもサーバレスアプリを継続的に開発できるチームはどう作るかという視点で読んでしまいました。ここで書かれている手法は、もちろんチームではなく個人でも有効です。むしろ、まず個人として身につける内容です。そういった意味で、非常によい本だなと思います。
 ハンズオン形式で実際に作りながら学ぶという形式なので、ここに書かれている内容を全てやりとげれば、現状のサーバレス開発の現場であれば、非常に重宝されると思います。ぜひぜひ挑戦してみてください。
※実は私も、まだ読みながら手を動かしていないので、時間見つけてやります

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

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


以下、目次です

目次



Chapter1 サーバーレスアプリケーションの概要
1-1 サーバーレスアプリケーションとは
1-2 ユースケースとアーキテクチャパターン
1-3 サーバーレスアプリケーションのライフサイクル管理概要

Chapter2 Amazon Web Services(AWS)利用の準備
2-1 AWSアカウントの取得
2-2 AWSにおける認証と認可について
2-3 リージョンの選択
2-4 AWS Command Line Interface(AWS CLI)の準備

Chapter3 インフラを自動化しよう
3-1 Amazon CloudWatchのアラームをトリガーに自動処理をする
3-2 Webサイトの状態を定期的にチェックする

Chapter4 Twitterのリアルタイム分析をしよう
4-1 Amazon Kinesisを使ってTwitterのデータを受け取る
4-2 AWS Lambdaを使ってストリーミングデータをAmazon DynamoDBへ保存する

Chapter5 写真投稿サイトをシングルページアプリケーションで作ろう
5-1 Webサイトの概要を確認する
5-2 バックエンドのAPIを実装する
5-3 フロントエンドを実装する
5-4 Amazon Cognitoを利用した認証処理を追加する
5-5 Amazon Rekognitionを使って自動タグづけを行う

Chapter6 サーバーレスアプリケーションのライフサイクル管理
6-1 AWS Serverless Application Model(AWS SAM)詳細
6-2 複数環境の管理
6-3 デリバリプロセスの自動化(CI/CD)

Chapter7 サーバーレスアプリケーションのトラブルシューティング
7-1 メトリクスのモニタリング
7-2 AWS X-Rayを利用したトラブルシューティング

まとめ


クラウドエンジニア養成読本を書きました

 ご報告遅くなりましたが、技術評論社から出版中のクラウドエンジニア養成読本の執筆に参加させていただきました。この本は、AWS, Azure, GCPという3大クラウドを取り扱うという意欲的な企画で、それぞれの分野の第一人者の方々が執筆されています。その中の末席に加えて頂けたこと、大変光栄です。

マルチクラウド


 私は、特集1の「ゼロから学ぶクラウドの世界 〜クラウドの現在、そして未来はどうなる?」という部分を担当しました。導入的な部分で、クラウドを取り巻く現状、主要ベンダーとその位置付け、最近の潮流、さらにはエンジニアはクラウドとどう向かい合うのかということをつらつらと書いています。
 その中のひとつのキーワードとして、マルチクラウド化を挙げています。マルチクラウドというと、何を持ってと宗教論争が起きるので、ここでの言葉の定義は2つ以上のクラウドを使っていたらマルチクラウドとざっくりしたものとしています。

f:id:dkfj:20180322072148p:plain

 マルチクラウド化の必然については、後述するコンテナ・サーバレスという2つの潮流の中で、クラウド間の可搬性がより高まることが予想されます。そうなると、企業としては、サービスごとに一番良いものを使い分けていくという方向になります。そんな未来がテーマの一つにしています。

コンテナ化とサーバレスアーキテクチャ


 先程のマルチクラウド化の論拠は、コンテナ化とサーバレス・アーキテクチャだと言いました。この2つは、システム・アプリケーションの可搬性を高めます。どちらも上手く作れば、動くプラットフォームはなんでもよくなります。そうなると、特定のクラウドサービスに拘る理由が少なくなってきます。実際、AWSをメインで使っているものの、コンテナ部分についてはKubernetesが便利なのでGCPを使っているという話をよく聞きました。
 コンテナ・サーバレス以外にもAI・機械学習・ビッグデータに関わるようなサービスについては、既に併用しているというケースは多いのではないでしょうか?GCP使ったことないと言いつつ、Big Queryだけ使ったことある人多いですよね。

成長戦略


 じゃぁ、マルチクラウドが進む中で、エンジニアはどうすれば良いのでしょうか?全てのクラウドを学んでいく?私の意見として、それは現実的ではないと思っています。個人として、複数のクラウドを習熟するのは困難ですし、たとえ組織としてもかなり大規模な組織ではないと難しいのではないかと考えています。
 では、取るべき道はどうすれば良いのでしょうか?私は、T型のアーキテクトか、特定のレイヤーに特化のどちらかだと思います。

 まずT型のアーキテクトです。下の下手な字にあるとおり、特定のクラウドに習熟した上で、他のクラウドについても、ある程度抑えるという方向です。

f:id:dkfj:20180322072108p:plain

 これに対して、特定レイヤー特化型は、ネットワークやコンテナ、サーバレスなどレイヤーを絞って、複数のクラウドサービスに習熟するという方向です。

f:id:dkfj:20180322072137p:plain

 私自身としては、T型です。特定レイヤーについては、もう少し余裕があれば手を伸ばしたいところです。取り組むとしたら、主戦場であるコンテナ・サーバレスではなく、今までの経験が活きる認証認可の分野かなと思っています。

まとめ


 他の方の執筆内容については言及できませんでしたが、かなり面白いです。同僚の石川によるサーバレスで構築するシングルページアプリケーション&バックエンドや、ソラコム松井さんのIoT、ハンズラボさんのクラウド移行話など、読み応えたっぷりです。
 余談ですが、最近だしたAWS関係本がAmazonのクラウドランキングに3つ並んで、ちょっと嬉しいです。

f:id:dkfj:20180322064951j:plain

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

  • 作者: 佐々木拓郎,西谷圭介,福井厚,寳野雄太,金子亨,廣瀬一海,菊池修治,松井基勝,田部井一成,吉田裕貴,石川修,竹林信哉
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/03/14
  • メディア: 単行本
  • この商品を含むブログを見る

AWSのアクセスキー・シークレットアクセスキーをプログラムに安全に埋め込む(埋め込まない)方法

 AWSでやらかす系の事故で、もっとも恐ろしいものの一つに、アクセスキー・シークレットアクセスキーの流出があります。これは、多くの場合プログラム中にアクセスキー・シークレットアクセスキーを埋め込んだままGitHub等の公開リポジトリに登録することで起こります。GitHubを監視しているBotがカモを待ち受けているので、キーを発見するやいなや不正利用して可能な限りのインスタンスを立ち上げます。そして、BitCoin等の採掘などに利用します。気が付かないと、一晩で100万円近くの請求という話もあったようです。

 

AWSのアクセスキーの流出を防ぐ方法


 このアクセスキーの流出は、AWSの仕組みを知っていると、ほぼ被害は防げます。という事、基本的な部分をおさらいしましょう。アクセスキーではなく、IAMロールを使うというのが基本ですが、どうしても使わざるをえない場合は、下記のルールを守ってください。

 

 守るべきシンプルなルールは、たったの一つです。

 

AWSのアクセスキーは、プログラムに直接書き込まない。環境変数から読み込む

 

 この環境変数というところがミソで、実はAWSのSDK,CLIは特定の環境変数名を自動で読み込むようになっています。アクセスキーは、AWS_ACCESS_KEY_IDで、シークレットアクセスキーは、AWS_SECRET_ACCESS_KEYです。

Linuxの設定例
export AWS_ACCESS_KEY_ID=your_access_key_id
export AWS_SECRET_ACCESS_KEY=your_secret_access_key

 

Windowsの設定例
set AWS_ACCESS_KEY_ID=your_access_key_id
set AWS_SECRET_ACCESS_KEY=your_secret_access_key

 

AWSの認証情報の検索順


  この辺りの情報は、AWSの認証情報の検索順等で検索すると出てきます。例えばRubyの例だと次のように定義されています。

 

AWS SDK for Ruby は、次の手順で認証情報を検索します。

 

1. クライアントオブジェクト内で認証情報を設定する

2. Aws.config を使用して認証情報を設定する

3. 環境変数を使用して認証情報を設定する

4. 共有認証情報の設定

5. IAM を使用して認証情報を設定する

 

 

 言語によっては多少違いますが、優先順位や設定可能項目は概ね同じです。つまりプログラムで設定したものが最優先で、次に環境変数系、最後にIAMロールという順です。

 

AWSのアクセスキー運用のベスト・プラクティス


 

 上記の最低限のルールの他に、下記のようなアクセスキーの運用を守ってください。いわゆるベストプラクティスの一部です。

 

- AWSサイドで利用する場合は、IAMロールを利用し、アクセスキーを利用しない

- アクセスキーを使う場合は、該当のIAMユーザには最小権限を付与する

- 可能な限りIPアドレスで絞る

- git-secretsを利用して、誤操作時に気付けるようにする

- Assume Roleを利用して、一時的なアクセスキーを利用すると、なお良い

 

 ただし、初めての人にこれ全部最初にやれというのも現実的ではないので、最低限守っておくべきというのが最初に説明したプログラムに埋め込まないという対応になります。

 

まとめ 


 実務的な部分では、もっと考慮しないといけない部分は沢山あります。ただ、手始めにローカルで試す場合、最低限この方法を守っていれば危険を回避します。本当は、サーバーサイドでロール使ってが良いですが、環境面の制約があり、キーを使わざるをえない場合の話です。

 こういった話も、3/23発売の改定第2版 Amazon Web Services パターン別構築・運用ガイドにまとめています。転ばぬ先の杖として、ぜひご活用ください。

 

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

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

  • 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/03/23
  • メディア: 単行本
  • この商品を含むブログを見る