こつつみ

コツコツ積み上げる

これからのビジョン

4/5で僕は25歳になった

4/1からは社会人3年目となった。2年前の今日はプログラミングのプの字も知らなかったのに割と意欲的に取り組めたんじゃないかと思う。

業務では、通信分野・組み込み開発をしている

プライベート * 社会人1年目では、ディープラーニング機械学習から初めて、競技プログラミングにハマりAtCoderでは緑になった。(下から3番目レベル, 上位30%くらい) * 社会人2年目では、スマホアプリ開発(Android)、Web開発(フロントエンド、バックエンド)、自宅サーバー設置など

ただ技術は全てが中途半端だ。 しかし、全てを満遍なく知ることができた。

これからのキャリアを考える上でこんなに良いことはない。

大企業に所属していると配属ガチャと呼ばれるものがある。しかし、本当にガチャなのだろうか? 実力があれば、希望の場所にいけるだろう。

自分がこれから何十年もやることをガチャで決めるのは嫌じゃないのか? 少なくとも俺は嫌だ。だから、色々経験して自分のあったものを探したつもりだ。

現在は、冒頭でも言った通り通信分野で組み込み開発をしている。 満遍なく経験した結果、組み込み開発は好きだけどC言語が嫌いということに気づくことが出来た。 C言語しか経験していなかったら比較のしようもなかったと思う。

社会人3年目、自分は次のキャリアに進むためWeb(サーバーサイド)・クラウドを主軸に置いてやっていく。 そのためにも、実力を示すしかない。

面接でただやりたいと言っても、熱意だけでは仕事はつとまらない。 やりたいことをやるために、先に結果を出す必要があるのだ。

仕事とは別の時間でコツコツとやった結果で、自分のやりたいことができるのだ。 とりあえず、昨日その一環としてAWSのSAA試験に合格することが出来た。 その話は、また別の機会に...

資格は実力じゃないとは言われるが、大企業の社内転職では有用だと思う。 これと今までの経験を合わせることで、クラウドを使った部署にいくぞ。

ガチャなんかに人生を決められてたまるもんか 俺はやりたいことをやるんだ

AWS SAA 用語集をまとめてみた

AWS SAA試験を受けるに当たり模擬試験を受けて、分からない単語が多すぎたので自分なりにまとめる。 かなりボリューミーになってしまった。知りたいところだけ目次から飛ぶのがオススメかもしれない まだ試験は受けていないので、範囲として足りない部分があるかもしれないが、そこはご容赦願います。

概要

  • IaaS (Infrastructure as a Service)
    • OSより上 
    • ex) EC2
  • PaaS (Platform as a Service)
    • Data, Applicationのみ (セキュリティを考えなくて良い?)
    • ex) RDS, lamda, fagate
  • SaaS (Software as a Service)
    • 全部やってくれる
    • ex) S3, cloud watch

AWS Well-Architected フレームワーク

ベストプラクティス

運用の優位性

システムを改善し続けましょう システムトラブルを減らそう ログを記録してモニタリングできているか?

セキュリティ

権限管理などしっかりしましょう 追跡調査。 全てのレイヤーでセキュリティを設定しましょう 継続改善できているか 障害リハーサルや自動復旧の仕組みづくりはあるか?

信頼性

単一障害点がないか?  一個障害が起こったらサービスが利用できないなんてことにはならないように設計するべき 自動的にリソース拡張しているか? 障害の影響を軽減できる仕組みか? これらのテストをしているか?

パフォーマンス効率

最新テクノロジーのメリット理解し、選定できているか? 価値の高い仕事に集中できていルカ? 最新テクノロジーの比較、実験を頻繁にできているか?

コスト最適化

コストを計測し、削減できる取り組みができているか? 差別化に繋がらない高負荷の作業に費用をかけていないか? 費用を分析及び属性化できているか? 部門ごとのタグをつけてみたりなどする。


Compute

EC2

インスタンスファミリー

  • 汎用
    • T3, M5, A1
  • コンピューティング最適化
    • C5
  • ストレージ最適化
    • I3, H1, D2
  • メモリ最適化
    • X1, R5, Z1d
  • 高速コンピューティング
    • F1, P3, G3

インスタンスタイプ

  • ベアメタルインスタンス
    • ハードウェアへのダイレクトアクセスを提供
    • ベアメタルインスタンスを利用することで通常のクラウドサーバーでは不可能な、ホストコンピューターのOSなどにアクセスが可能
    • ベアメタルはユーザーは以下のことができる
      • 詳細なパフォーマンス分析ツールを利用するアプリケーション
      • ベアメタルのインフラストラクチャへの直接アクセスを必要とする特殊なワークロード
      • 仮想環境ではサポートされないレガシーのワークロード
      • ライセンス制限のあるティア1のビジネスクリティカルなアプリケーション

購入オプション

物理ホストの専有オプション

  • ハードウェア専有インスタンス
    • ...
  • Dedicated Host
    • 物理的にサーバーを占有するインスタンスタイプ
    • Dedicated Hosts では、ライセンス条項の範囲で、ソケット単位、コア単位、または VM ソフトウェア単位の既存のライセンスを利用できます。
    • 同じAWSアカウントに属していたとしても、別のIAMグループとは物理サーバーを共有しません。

ECS

  • Elastic Containar Service
  • ECSは、Docker コンテナをサポートする拡張性とパフォーマンスに優れたコンテナオーケストレーションサービス
    • これにより、コンテナ化されたアプリケーションを AWS に簡単に実行およびスケールできます。
  • コンテナ実行環境
    • EC2起動タイプ
    • Fargate起動タイプ

EKS

  • Elastic Kubernetes Service
  • コンテナ化されたアプリケーションのデプロイ、管理、スケールを Kubernetes を使って AWS で簡単に実行できます。
  • AWSKubernetes を簡単に実行できるようにするマネージド型サービスです。
    • Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するための管理ツールとして汎用的に利用されるOSSです

Fargate

  • サーバー管理なしのコンテナ実行コンピューティングエンジン
  • AWS Fargate は、サーバーやクラスターの管理の必要なしにコンテナを実行するための、Amazon ECS および EKS に対応したコンピューティングエンジンです。これ自体はDockerの仕組みをサポートするサービス
  • Fargate はコンテナを実行するために仮想マシンクラスターをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、クラスターをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
  • 以前は、Amazon EKSとFargateの組合せは利用できませんでした
  • 2019年12月より、AWS Fargate の上でKubernetesを利用できるようになりました。
  • Amazon EKS と Fargateはインスタンスのプロビジョニング設定などを自動で構成してくれるため、AWS 上での Kubernetes ベースのアプリケーション開発やその管理を一定程度自動化してくれます。
  • したがって、ECSとFargateの組合せよりも Kubernetesを利用することで、より自動化を達成することが可能です。
ECR
  • ECRは、完全マネージド型の Docker コンテナレジストリです。このレジストリを使うと、開発者は Docker コンテナイメージを簡単に保存、管理、デプロイできます。

Elastic Beanstalk

  • AWS Elastic Beanstalk はECSなどのDocker サービスと連携して、容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動化することができます。
  • AWS Elastic BeanstalkはELBと Auto Scalingを利用してスケーラブルのデプロイを自動化することが可能です。
  • また、AWS Elastic Beanstalkはアプリケーションのバージョン管理を自動化することもできます。
  • AWS Elastic BeanstalkはAmazon ECSなどのDockerにホストされたWEBアプリケーションの展開もサポートしています。
  • Elastic Beanstalk で Docker を使用することにより、容量のプロビジョニング、負荷の分散、スケーリング、およびアプリケーションの状態の監視の詳細を自動的に処理するインフラストラクチャが提供されます。
  • したがって、Elastic Beanstalk を利用することでECRとEKSとの連携してDocker経由のアプリケーション展開を設定しつつ、バージョン管理や状態の監視の詳細を自動化することが可能となります。
  • AWS Elastic Beanstalk は自動的にデプロイタスク (バッチ配布の自動化、容量のプロビジョニング、負荷分散、Auto Scaling、アプリケーションのヘルスモニタリングなど) を処理します。
  • AWS Elastic BeanstalkによりアプリケーションがホストされるAWS リソースをユーザー側で完全に制御することができます。
  • また、Elastic BEeanstalkコンソールを運用ダッシュボードとして、環境の状態とアプリケーションの状態を一目で分かるように表示することができます

Lamda

ステートレスアプリケーションはシステム上のやり取りの状態情報が不要なため、セッション情報が格納されていないアプリケーションのことです。そのため、同じ入力が与えられたときに、どのエンドユーザに対しても同じ応答を提供するアプリケーションとなります。Lambdaファンクションはステートレスなアプリケーション処理をコスト最適に達成できます。

  • Lambda関数が無期限に実行されないようにタイムアウト設定がなされています。
  • 指定されたタイムアウトに達するとLambda関数は実行を終了します。

Lambda Layer

  • 複数のLambda関数でライブラリを共有できる仕組みであり、一定の機能をLayerとしてまとめて利用することができます。
  • これまでは同じライブラリを利用する関数が複数あった場合、全ての関数に対してライブラリを含めてパッケージングすることが必要でした
  • それを、ライブラリをLayerとしてアップロードしておくことで、個々の関数は共通のLayerを使用することができます。

Lambdaエッジ

  • Lambdaエッジ を使用すると、サーバー管理を行わなくても、ウェブアプリケーションをグローバルに分散させ、パフォーマンスを向上させることができます。

Storage

EBS

  • Amazon Elastic Compute Cloud (EC2) インスタンスにアタッチして使用するブロックレベルのストレージサービス
  • 99.999%の可用性を備えるように設計されている
  • 単一のEC2インスタンスのEBSボリュームは、インスタンス用のシステムドライブやデータベースアプリケーション用のストレージなどの頻繁に更新が必要なデータのプライマリストレージとして使用できます。また、継続的なディスクスキャンを実行するスループット重視のアプリケーションにも使用できます。 これらのEBSボリュームはEC2インスタンスの稼働期間とは無関係に維持されます。
  • EBSは用途に応じてボリュームサイズやボリュームタイプを変更することができることが利点の一つです。
  • 同一AZでののみ利用可能
  • EC2 は接続されていた各 EBS ボリュームの DeleteOnTermination 属性 を使用して、ボリュームを存続させるべきか、削除すべきかを判断します
    • デフォルトでは、インスタンスのルートボリュームの DeleteOnTermination 属性が有効化されており、EC2インスタンスの削除とともにEBSも削除されてしますが、
    • その他のボリュームタイプではDeleteOnTermination 属性は非有効化されています。
    • インスタンスが停止してもルートボリュームを維持したい場合は、ルートボリュームの DeleteOnTermination 属性を非有効化することが必要です。それによって、インスタンス削除後にデータを存続させることが可能です。
  • 容量と IOPS の最大割合 は 50:1。例えば、100 GiB のボリュームは最大 5,000 IOPS

ブロックストレージの種類

  • EBSのプロビジョンドIOPSボリューム
    • レイテンシーの影響が大きいトランザクションワークロード向けに設計された極めてパフォーマンスの高い SSD ボリュームです
    • コストがもっとも高いですが、スループットとIO性能が最も高いボリュームです。コスト最適よりも性能が優先される場合には、このボリュームタイプを選択します。
    • 最大 64,000 IOPS までの一貫したベースラインパフォーマンスを提供し、ボリュームあたり最大 1,000 MB/秒のスルー​​プットを実現するように設計されています。
  • スループット最適化HDD
    • 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD ボリュームです
    • これは高いスループット性能を期待しつつ、プロビジョンドIOPS SSDよりも低コストを実現することができます
    • しかしながら、スループット最適化HDDは1000MiB /sのデータスループット性能を有していません。性能は落ちるもののコスト最適を求める場合に選択します。
  • 汎用SSD
    • 幅広いトランザクションワークロードに対応できる価格とパフォーマンスのバランスが取れた汎用 SSD ボリュームです
  • コールドHDD
    • アクセス頻度の低いワークロード向けに設計された極めて低コストの HDD ボリュームです。

S3

  • S3
    • ユーザがデータを安全に、容量制限なく、データ保存が可能な、クラウド時代のオブジェクトストレージです。
  • S3 Glacier
    • 安全性とコスト効率を重視したアーカイブ向けストレージ

サーバーサイド暗号化

  • 暗号化種別
    • SSE-S3 : AWSが管理する鍵を利用して暗号化
    • SSE-KMS:Key Management Service(KMS)の鍵を利用して暗号化
    • SSE-C:ユーザが提供した鍵を利用して暗号化(AWSで鍵は管理しない)
  • デフォルト暗号化
    • バケットポリシーを定義することなく、バケットに格納するオブジェクトの暗号化を強制する
    • Amazon S3 はオブジェクトをデータセンター内のディスクに保存する前に暗号化し、オブジェクトをダウンロードするときにS3側で自動で復号します。
    • ログも自動で暗号化されるため、S3バケットの暗号化と別に設定する必要はありません。

クライアントサイド暗号化

  • Client Side Encryption(CSE
    • ユーザーが独自の暗号化キーを利用して暗号化したオブジェクトをS3に保存して、暗号化キーの生成・監理はクライアントで実行する形式です。ユーザーが暗号化キーの管理を実施することが前提となっている

レプリケーション

ストレージクラス

Standard
  • 頻繁にアクセスするデータ,msアクセス
Intelligent-Tlering
  • 変化するアクセスパターンのデータ,msアクセス
Standard-IA
  • 低頻度アクセス用ですが、読み込みはすぐにできるため、突然の利用にも対応できます。,msアクセス
One-Zone-IA
  • データ冗長性は劣るため、アクセスが頻繁ではないデータを低価格に保存するのに向いています。
    • バックアップのコピー
    • 再作成可能なデータサマリーなど
  • レジリエンスが低い単一アベイラビリティーゾーンに保存することによってコストを節約します
  • また、データ取り出しは通常の標準クラスと同じように即時に実行可能です。,msアクセス
Glacier
  • コストが安くデータの長期保存に向いていますが、データ取得に数時間要するストレージです。
  • 最低保持期間が90日と設定されている
  • 迅速読取
    • 1分~5分ほどでデータを取得することができます。即時ではない
  • 大容量取り出し
    • 5〜12 時間必要
  • ボールトロック
Glacier Deep Archive
  • ストレージクラスの方がGlacierよりもコストが安いです。

S3 イベント通知

  • Amazon S3は、以下のサービスを利用してイベントを発行できます
    • Amazon SNSトピック
      • 購読しているエンドポイントまたはクライアントへのメッセージの配信を実行・管理するサービスです。S3をトリガーとしてメールなどを通知できます。
    • Amazon SQSキュー
      • メッセージをコンピュータ間で通信するために利用する信頼性が高くスケーラブルなキューイングサービスです。S3をトリガーとしてStandardキューを配信できます。
    • AWS Lambda
      • コードをアップロードし、サービスがAWSインフラストラクチャを使用してコードを実行できるサーバレスコンピューティングサービスです。 Lambda関数を作成するときに、カスタムコードをパッケージ化してAWS Lambdaにアップロードします。S3をトリガーとしてLambda関数を実行できます。

S3 Select

  • Amazon S3 SelectはシンプルなSQLステートメントを使用してAmazon S3オブジェクトのコンテンツをフィルタリングし、必要なデータのサブセットのみを取得できます。
  • 結果として、Amazon S3が転送するデータ量を削減でき、データ取得に要するコストを削減し、待ち時間を改善できます。

S3 Access Analyzer

  • AWS アカウントの外部からアクセスできるリソースを特定する総合的な解析結果を生成します。S3バケットに対する外部アカウントからのアクセス情報を分析して、不正なアカウントアクセスがないかを確認することができます。

Amazon S3 分析のストレージクラス分析

  • Amazon S3 分析のストレージクラス分析により、ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断できます。
  • ストレージクラス分析がフィルタリングされたデータセットのアクセスパターンを一定期間監視することで、ライフサイクルポリシーを設定することができます。

マルチパートアップロード API

大容量オブジェクトをいくつかに分けてアップロードできるようになります。この機能により、新しい大容量オブジェクトをアップロードすることが容易になり、今回のアップロード処理の負荷を軽減することが可能です。

S3に保存されているデータを直接解析することができる機能/サービス

  • Amazon S3では、データを別の分析システムに移動することなく、直接にS3データに対して高度なビッグデータ分析を実行できます。
  • Amazon S3 Select
    • Amazon S3バケット内のオブジェクト内のデータをより迅速かつ安価に分析および処理できるように設計されています。
    • 単純なSQL式を使用してAmazon S3のオブジェクトからデータのサブセットを取得する機能を提供することで機能します。
  • Amazon Athena
    • 標準のSQL式を使用してAmazon S3のデータを簡単に分析できるインタラクティブなクエリサービスです。
    • Amazon S3のデータをポイントし、スキーマを定義し、標準のSQL式を使用してクエリを開始するだけです。
    • ほとんどの結果は数秒以内に配信されます。
  • Amazon Redshift
    • Redshift Spectrumも含まれており、Amazon S3のエクサバイトの非構造化データに対してSQLクエリを直接実行できます。
    • 取得されるデータに基づいてクエリの計算能力を自動的にスケーリングするため、データセットのサイズに関係なく、Amazon S3に対するクエリは高速に実行されます。

S3 Transfer Acceleration

  • S3 Transfer Acceleration を使用すると、クライアントと S3 バケットの間で、長距離にわたるファイル転送を高速、簡単、安全に行えるようになります。
  • これにより、各リージョンからS3へのデータ転送が容易に実行できるようになります。Transfer Acceleration では、Amazon CloudFront の世界中に分散したエッジロケーションを利用しています。
  • エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。

EFS

  • NFS アクセスを提供する分散ストレージ
  • ファイルシステム NFS v4.0/4.1
  • EFS へのアクセスはファイル単位
  • 高負荷のワークロードにおいて、Amazon EFS は 10 GB/秒 を超えるパフォーマンス、および 500,000 超の IOPS をサポートできます。

Amazon FSx

Storage Gateway

  • 標準的なストレージプロトコルを利用してAWSのストレージサービスへのアクセスを可能にするハイブリッドストレージソリューション
  • 標準的なプロトコルでオンプレとシームレスで接続できる
    • ファイルゲートウェイ
      • NFS (v3 and v4.1) インターフェース
    • ボリュームゲートウェイ
      • iSCSI ブロックインターフェース
        • ストレージゲートウェイ キャッシュ型ボリューム
          • S3をプライマリーストレージとして、オンプレミスストレージとのハイブリッド構成を実現する際に利用します。
          • キャッシュ型ボリュームを使用することで、頻繁にアクセスされるデータはローカルのストレージゲートウェイに保持しながら、Amazon S3 をプライマリデータストレージとして使用できます。
        • ストレージゲートウェイのストアドボリューム(保管型ボリューム)
          • オンプレミス環境のストレージをプライマリーストレージとして利用する構成です。
    • テープゲートウェイ
      • iSCSI仮想テープライブラリ (VTL) インターフェース
  • バックアップと親和性

Databases

Dynamo DB

  • 完全マネージド型の NoSQL データベースサービス
  • DynamoDBが保存できるデータ型は次のように分類できます。
    • スカラー
      • スカラー型は 1 つの値を表すことができます。スカラー型は、数値、文字列、バイナリ、ブール、および null です。
    • ドキュメント型
      • ドキュメント型は JSON ドキュメントなどの入れ子の属性を持つ複雑な構造を表すことができます。
    • セット型
      • セット型は複数のスカラー値を表すことができます。セット型は、文字セット、数値セット、およびバイナリセットです。
  • Auto Scaling
    • DynamoDBのAuto Scalingを導入して、テーブルとグローバルセカンダリインデックス(GSI)の容量増加を自動化できます。
    • Global Secondary Index (GSI)
      • Partition Keyをまたいで検索を行うためのインデックス
    • DynamoDB Auto Scalingはテーブルとインデックスを監視して、アプリケーショントラフィックの変化に応じて自動的にスループットを調整します。
    • これにより一時的な負荷増加に対して、DynamoDBテーブル処理パフォーマンスの管理が容易になり、アプリケーションの可用性を最大化しつつ、DynamoDBのコストを削減することができます。
  • DynamoDBはそのままではリードレプリカを増やすことができません。後述するDAX を有効化することで、DAXクラスターは、1 つのみのプライマリノードと、0~9 個のリードレプリカノードを構成することができます。

DynamoDB Accelerator(DAX)

  • DynamoDBテーブルはミリセカンドからマイクロセカンドへの最大 10 倍のパフォーマンス向上を実現します。
  • DAXはキャッシュを利用しているため特定のデータへの処理が高い場合などに中長期的な性能向上のために対策としては正しいです。
  • しかしながら、キャッシュDBは高コストである

DynamoDBストリーム

  • DynamoDBに行われた追加、更新、削除の変更履歴を保持しとりだし可能
  • DynamoDBテーブルの変更イベントをトリガーにして、Lambda関数などを起動する際に利用します。
  • DynamoDBストリームがデータ処理を動的に実行するといった処理を実現することはできません

ElastiCache

  • 完全マネージド型で、セットアップ、運用、拡張が容易なキャッシュサービス
  • ElastiCacheはインメモリDB型のキーバリューストアの高性能データベースです
  • ElastiCacheはキャッシュデータにミリ秒以下のレイテンシーにアクセスを提供することで、高速のデータ処理を可能にします。
  • したがって、ユーザー行動データの高速な処理には最適なDBであり、行動データ記録に応じたリアルタイムのランキング処理やアイテム出現などを実現することが可能です。

RDS

  • フルマネージドなリレーショナルデータベース
  • RDSの拡張モニタリングを有効化
    • DBインスタンス上のさまざまなプロセスまたはスレッドがCPUをどのように使用しているかを常時モニタリングするためには、RDSの拡張モニタリングを有効化することが必要です。
    • これにより、DBインスタンスのOSのリアルタイムメトリックスが確認できるようになります。
    • RDSコンソールを使用してDBインスタンスのメトリクスを表示でき、CloudWatch Logsからの拡張モニタリングを利用することができます。
    • デフォルトでは、拡張モニタリングメトリクスは30日間CloudWatch Logsに保存されます。
  • レプリカDBで読み取り処理をスケールアウト
    • RRは5台(Auroraは15台)まで増設できる

Aurora

  • スループット
    • MySQLの5倍
    • PostgressSQLの3倍
  • Auroraはリードレプリカを最大15個設置することで、読込処理性能を向上させることが出来ます。
  • 最1つのAuroraのDBクラスターに対して最大 15 個の Aurora レプリカを、1 つの AWS リージョンの各アベイラビリティーゾーンに設置して、読込処理を分散できます。
  • DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。これにより、すべての Aurora レプリカは、最短のレプリカラグで読み込み処理を返すことができます。

Migration & Transfer

AWS DMS

  • AWS Database Migration Service
  • DBのデータ連携を支援するサービス
  • オンプレミスにあるデータベースを短期間で安全に AWS に移行できます

AWS SMS

AWS Snow Family

  • Snowball
  • Snowball Edge
  • Snowmobile // Tokyoにはない

Snowball

  • 「ハードウェアアプライアンス」を利用してオンプレミス−クラウド間の大量データ移行を高速化
  • Snowballアプライアンス
    • セキュリティを考慮して設計されたデバイス (AWSから借りてくる
  • ペタバイトスケールのデータ移行
  • 高いネットワークコスト、長時間かかる転送、セキュリティ面の懸念といった、大規模なデータ転送に関する一般的な課題を解決できます
  • データを簡単、迅速、安全に転送でき、高速インターネットによるデータ転送と比較して、コストは5 分の 1 ほどで済みます。

Snowball Edge

  • オンボードコンピュート能力とストレージを搭載するペタバイトスケールのハイブリッドデバイス
  • Snowball Edge = Snowball + コンピュート +α

  • Snowball Edge Compute Optimized

    • 機械学習、フルモーション動画分析、分析、ローカルコンピューティングスタックなどのユースケースに強力なコンピューティングリソースを提供します。
    • このデバイスは、S3 互換オブジェクトストレージまたは EBS 互換ブロックボリューム用に 42 TB の使用可能な HDD 容量を提供します。
  • Snowball Edge Storage Optimized
    • 大規模なデータ移行と定期的な転送ワークフロー、およびさらに高容量を必要とするローカルコンピューティングに適しています。
    • ブロックボリュームと Amazon S3 互換オブジェクトストレージに 100TB の HDD 容量を提供します。
    • しかしながら、利用可能なボリュームは80TBほどです。

Networking & Content Delivery

ELB

  • Amazon ECS はELBのいずれかのタイプのロードバランサ―を使用できます
    • ALB (Application Load Balancer )
      • HTTP, HTTPS,
      • L7のコンテントベース
      • ALBはURL パスに基づいてリクエストを転送するルールを持つリスナーを作成できます。この方式をパスルーティングと呼ばれます。複数のタスクを実施するEC2インスタンスグループを有している場合は、パスルーティングを使用して1つのALBで複数のバックエンドサービスにトラフィックをルーティングすることができます。
    • CLB ( Classic Load Balancer )
    • NLB (Network Load Balancer)
      • HTTP, HTTPS, TCP
      • NLBはOSIモデルの第 4 層で機能する毎秒数百万のリクエストを処理できる高性能なロードバランサーです。パスルーティングは実行可能ですが、かなりの大規模システム向けの高性能なELB
      • EC2-Classicネットワーク用ロードバランサ-

コネクション

高可用性と負荷分散

  • クロスゾーン負荷分散

VPC

  • Virtual Private Cloud
  • 1アカウントに1リージョンに5つまでのVPC
    • チームが明確に分かれているならアカウントを分けた方が良い (大企業)
  • PCのDNS hostnamesオプションが有効化されていないと、サブネットで起動されたインスタンスDNS名を取得できません。
  • VPC 内で起動したインスタンスがパブリック IP アドレスに対応するパブリック DNS ホスト名を受け取るかどうか、および Amazon DNS サーバーを通じた DNS 解決が VPCに適用されるかは、VPCの操作で決定されます。
  • VPCDNS hostnamesオプションを有効化するためには、 enableDnsSupport 属性を「true」 に設定した上で、enableDnsHostnames属性を「true」に設定して、VPC 内のインスタンスDNS ホスト名を取得可能とします。

VPC エンドポイント

  • インターネットを介さずに、VPC内のサービスからVPC外のAWSサービスに接続することができます。これにより、インターネットを通さずにEWS サービスや VPC エンドポイントサービスにVPC をプライベートに接続する機能です。
  • その際にインターネットゲートウェイ、NAT 、VPNAWS Direct Connect を介した接続やパブリック IP アドレスは必要ありません。
  • VPC と他のサービス間のトラフィックは、Amazon ネットワーク内で完結するためインターネットを経由することはありません。VPC エンドポイントには 2 種類あります。
    • ゲートウェイ
      • ルートテーブルの指定されたターゲットとなるゲートウェイです。サポートされる AWS のサービスを宛先とするトラフィックVPC内外で接続する際に使用します。以下の AWS のサービスがサポートされています。
    • プライベートリンク型(インターフェイスエンドポイント)
      • 対象サービスを宛先とするトラフィックのエントリポイントとなるプライベート IP アドレスを持つ Elastic Network Interface です。以下のサービスがサポートされています。

VPC Peering

VPC PeeringはVPC間を連携させる際に利用します

CloudFront

  • レイテンシーの高速転送により視聴者に安全にコンテンツを配信する高速コンテンツ

データ保護機能

  • CloudFrontの署名付きURLと署名付きCookieは同じ基本機能を提供しており、CloudFrontが配信するコンテンツにアクセスできるユーザーを制御できます。次の点で違いがあります。
    • 次のような場合は署名付きURLを使用してください。
      • アプリケーションのインストールダウンロードなど、個々のファイルへのアクセスを制限したい。
      • ユーザーがクッキーをサポートしていないクライアントを使用している。
    • 次のような場合は署名付きcookieを使用してください。
      • HLS形式の動画のすべてのファイル、またはWebサイトの購読者領域のすべてのファイルなど、制限のある複数のファイルへのアクセスを提供したい。
      • 現在のオブジェクトURLを変更したくない。
  • オリジンサーバの保護
    • オリジンがS3の場合
      • オリジンアクセスアイデンティティ (OAI) という特別な CloudFront ユーザーを作成してS3バケットへの直接的なアクセスを制限します。
      • これにより、ユーザーは S3 バケットへの直接 URL を使用してファイルにアクセスすることはできなくなり、CloudFront を通じて提供するファイルへの安全なアクセスを維持することが可能となります。

Cloud Watch

  • EC2インスタンスのデフォルトメトリクス以外の詳細なログ情報を取得するためには、CloudWatchの2つのサービスを利用する必要があります。
    • CloudWatchエージェント
      • このエージェントを対象のEC2インスタンスにインストールすることで、CloudWatchによりサーバー内部の詳細なログが取得できるようになります
    • CloudWatch Logs
      • CloudWatch Logsは取得したログを集約することができ、EC2インスタンスのログ管理を実施することができます。

Route 53

  • ルーティングポリシー
    • シンプル
    • 加重
    • 複数回答
      • 複数値回答ルーティングにより、Amazon Route 53 が DNS クエリに対する応答として複数の値 (ウェブサーバーの IP アドレスなど) を返すように設定できます。
      • 複数値回答ルーティングは各リソースが正常かどうかも確認するため、Route 53 は正常なリソースに値のみを返すことができます。
      • したがって、EC2インスタンス単位での正常・非正常を判断してルーティングすることができます。これはロードバランサーに置き換わるものではありませんが、Route53が設定したインスタンストラフィックが正常であることをヘルスチェックした上で複数の IP アドレスを返すことができ、DNS を使用してアベイラビリティーとロードバランシングを向上させることができます。
    • レイテンシー
    • 位置情報
    • 物理的近接性
    • フェイルオーバー
      • Route 53 のヘルスチェックを使用してフェールオーバー (アクティブ/アクティブとアクティブ/パッシブ) を設定できます。
      • Route53は同じ機能を実行するEC2インスタンスなどのリソースが複数ある場合に、リソースの正常性をチェックして、正常なリソースのみを使って DNS クエリに応答するように Amazon Route 53 を設定することができます。
        • 具体的には、「example.comサイト」が、世界各地の 3 拠点のデータセンターにそれぞれ 2 台ずつ、合計 6 台のサーバーでホストされているとします。
        • それらのサーバーの正常性をチェックし、その時点で正常なサーバーのみを使って example.comDNS クエリに応答するように Route 53 を設定することができます。
      • Route53のフェールオーバー設定のアクティブ/アクティブ構成によって、レイテンシールーティングなどのルーティングポリシーを利用してフェールオーバーを構成することができます。
        • アクティブ/アクティブ構成となり、設定された全リソースを平等に利用することができます。
        • リソースが利用できなくなると、そのリソースを Route 53 が異常として検出し、以後、クエリへの応答に含めることを控えます。
      • フェールオーバー設定におけるアクティブ/パッシブ構成は、プライマリリソースを常に利用可能にしますが、すべてのプライマリリソースが使用できなくなった場合に備えて、セカンダリリソースまたはリソースグループをスタンバイ状態にします。
  • 本環境DR環境(ディザスタリカバリ)と遠隔DR環境を別リージョンに設置して、その管理をRoute53で実施することで、他の選択肢よりもAWSのマネージドサービスを利用した自動フェイルオーバーが利用可能であり、DR対応を自動化することができます。
    • Route53を利用したDR環境の方式としては主に以下の2つが考えられます。
      • コールドスタンバイ
        • Amazon S3をバックアップデータの格納先として利用します。
        • 事前にシステムイメージをクラウド上に準備します。
        • 災害発生時にクラウド上のシステムを起動し、Route53で切り替えることで復旧します。
        • 投資コストを抑えられ、手軽に始めることができる
      • ウォームスタンバイ
        • クラウドのスタンバイ環境にデータを常時レプリケーションします。
        • 通常は、スタンバイ環境を最少構成で稼働させ、災害発生時は必要なキャパシティに変更します。
        • スタンバイ環境の運用が常時必要になりますが、Route53でシステム切り替えを素早く実行することができます
  • レコード
    • CNAMEレコード
    • Aレコード
    • NSレコード
      • あるゾーンに対する権威サーバーを指定するためのレコードです

Direct Connect

  • お客様がキャリヤから調達する専用線の片端とAWS Cloudを、Direct Connectロケーションで接続するサービスです
  • 物理的にAWS側と専用線接続の設定が必要です
    • AWSへの申請と設定などが必要不可欠
  • お客様の大切なワークロードを担うネットワークとして、シングルポイントを作らない事が重要。

Developer Tools

CodePipeline

  • 素早く信頼性の高いアプリケーション更新のための継続的デリバリーサービスを提供
  • ビルドやテスト結果をslackに通知したりできる

X-Ray

  • アプリケーションやその基盤となるサービスの実行状況を把握しパフォーマンスの問題やエラーの根本原因を特定する
  • ユーザーがAmazon API からのAPIリクエストを通じてサービスを呼び出した場合に、AWS X-Rayを使用してユーザーリクエストを追跡および分析できます。
  • API Gatewayは、すべてのAPI Gatewayエンドポイントタイプ(地域、エッジ最適化、プライベート)のAWS X-Rayトレースをサポートしています。
  • そのため、 X-Rayが利用可能なすべてのリージョンにおいて、Amazon API GatewayAWS X-Rayを使用してトレースデータを収集することが可能です。

Management & Governance

Auto Scaling

  • Auto Scalingは起動したインスタンスに対して、定期的なヘルスチェックを実行します。このへルスチェックにはEC2タイプとELBタイプの2つのタイプがあります。
    • EC2タイプ
      • EC2のステータスがrunning以外の場合、またはシステムステータスがimpairedの場合に、このインスタンスを異常と判断します。
    • ELBタイプ

CloudFormation

  • クラウドプロビジョニングを高速化
  • 基本機能

    • 作成
      • テンプレートに定義された構成でスタックを自動作成
      • 並列でリソースを作成し依存関係がある場合は自動的に解決
    • 変更
      • スタックに前回のテンプレートとの差分を適用(冪等性)
      • リソース変更時は 無停止変更 / 再起動 / 再作成 のいずれかが発生
      • Change Set を作ることで差分の内容を事前に確認可能
    • 削除
      • 依存関係を解決しつつリソースを全て削除
      • データストアはスナップショット取得 / 保持が可能
  • CloudFormation スタック

    • 1つのスタックの出力値を別のスタックに提供することで、スタック間を連動させてインフラを構成することが可能になります。
    • スタック間で情報を共有するにはスタックの出力値をエクスポートします。
    • スタックの出力値をエクスポートするには、スタックのテンプレートの Output セクションの Export フィールドを使用します。
    • CloudFormation スタックに既存のリソースをインポートすることが可能です。
    • これはエクスポートされた出力値を別スタック側が利用する際に使われます。
  • CloudFormation ドリフト
    • テンプレートを利用してインフラ展開後にインフラ構成に変更が発生した場合のテンプレートと展開されたコードとの相違点です。
      • 実際のリソースとCloudFormationテンプレートの内容に乖離があることをドリフトと言います。
  • CloudFormation スタックセット
    • 利用するとCloudFormation テンプレート内に AWS リソースの設定を定義して、1つのテンプレートにより複数の AWS アカウントやリージョンにリソースを展開できます。
    • クロスアカウントやクロスリージョンのシナリオを解決する AWS 機能のベースラインレベルのセットアップにこの機能を活用できます。
    • 一度セットアップしてしまえば、追加のアカウントやリージョンに対しても容易に展開することができます。
  • CloudFormationテンプレート
    • テンプレートからAWSリソースを自動構築するための一連のセット様式のことです。
  • CloudFormation 変更セット
    • CloudfFormationのテンプレート内容の変更を行う仕組みです。
    • スタックを更新する必要がある場合は、変更の実装前に実行中のリソースに与える影響を理解することで、安心してスタックを更新できます。
    • 変更セットを使用すると、スタックの変更案が実行中のリソースに与える可能性がある影響 (たとえば、変更によって重要なリソースが削除されたり置き換えられたりしないか) を確認できます。

CloudTrail

  • AWS インフラストラクチャ全体でアカウントアクティビティをログに記録し、継続的に監視し、保持できます。
  • AWS CloudTrail はAWS アカウントのガバナンス、コンプライアンス、運用監査、リスク監査を行うためのサービスです。

AWS Config

  • Configでは、AWS リソースの設定が継続的にモニタリングおよび記録され、望まれる設定に対する記録された設定の評価を自動的に実行できます。
  • AWS ConfigはAWS リソースの設定を評価、監査、審査できる構成管理のサービスです
  • 何に対して、誰が、いつ、何をしたかを自動で継続的に記録し、確認する

AWS OpsWorks

  • クラウド企業内のアプリケーションを設定および運用する環境自動化サービスです
    • 個別にSSH, RDPログインして設定が不要になったりなど..
  • 以下の機能を使用する
    • Puppet
    • Chef

MSecurity, Identity & Compliance

Amazon Cognito

  • API ベースで実装されるモバイルアプリや Web アプリにユーザ認証機能を提供するサービス
  • MFAによる多要素認証と保存データおよび転送データの暗号化が実施できます。
  • また、GoogleFacebookAmazon などのソーシャル ID プロバイダーや、SAML による Microsoft Active Directory などのエンタープライズ ID プロバイダーを通してサインインすることができます。
  • Amazon Cognitoはウェブアプリケーションおよびモバイルアプリに素早く簡単にユーザーのサインアップ/サインインおよびアクセスコントロールの機能を追加できます。

Amazon Inspector

  • Amazon EC2にエージェントを導⼊し、プラットフォームの脆弱性を診断する、ホスト型診断サービスです
  • Amazon Inspector は自動化されたセキュリティ評価サービスで、AWS にデプロイしたアプリケーションのセキュリティとコンプライアンスを向上させることができます
  • 自動化されたセキュリティ評価サービスで、自動的にアプリケーションを評価し、露出、脆弱性、ベストプラクティスからの逸脱がないかどうかを確認します。

CloudHSM

  • シングルテナント方式のFIPS140-2 Level3準拠のハードウェアセキュリティモジュール(HSM)を使用した暗号鍵管理サービス
  • AWS CloudHSMを利用した鍵管理により、EUなどの各国の厳しいセキュリティ基準を満たすことができます。
  • AWS CloudHSMは安全なキーストレージや高パフォーマンスの暗号化オペレーションを AWS アプリケーションに対して簡単に追加できるようにするクラウドベースのハードウェアセキュリティモジュール (HSM) です。
  • AWS CloudHSM では不正使用防止策が施された HSM へのシングルテナントアクセスを利用できます。HSM は暗号化モジュール向けの FIPS 140-2 レベル 3 標準に準拠しています。

AWS KMS

  • マルチテナント方式のマネージド暗号鍵管理サービス
  • 暗号鍵の作成、管理、運用のためのサービス
  • KMIは2つの機能から成り立つ
    • 鍵の保管
      • 鍵を安全に保管するストレージ
    • 鍵の管理
      • 鍵のライフサイクル管理、及び鍵の管理や利用に対する認証・認可・記録するアクセス制御

AWS Shield

  • マネージド型のDDoS攻撃に対する保護サービスで、AWS で実行しているアプリケーションを保護します。

AWS WAF


Analytics

Amazon Athena

  • Amazon S3 にあるデータ(およびさまざまなデータソース)に対して標準 SQL を使用して簡単に分析可能とするインタラクティブなクエリサービス
  • 実行するクエリに対してのみ料金が発生し、各クエリでスキャンされるデータ量に基づいて課金されます。
  • データの圧縮、分割、列形式への変換を行うと、大幅なコスト削減とパフォーマンス向上を実現でき、データ処理コストを抑えることができます。

Amazon EMR

  • 大幅なコスト削減を可能にする、クラウドを利用したマネージドなHadoopとSpark
    • Hadoop
    • Spark
      • ビッグデータ処理ツール
      • インメモリ高速分散処理プラットフォームで、大規模データ処理用統合分析機能を提供します。「高速」かつ「汎用的」であることを目標に設計されています

Amazon Kinesis

  • ストリームデータを収集・処理するためのフルマネージドサービス群
    • センサーデータを処理する(IoTなどで使用)
  • Amazon Kinesis Data Analytics ストリーミングデータをリアルタイムで分析することができますが、本件では適用できません。これはIoTなどのストリーミングデータを対象としており、画像解析データなどの解析には不向きです。

Amazon Kinesis プラットフォーム

  • Amazon Kinesis Data Firehose
    • ストリーミングデータをデータレイクやデータストア、分析ツールに配信するサービスです。
    • ストリーミングデータをキャプチャして変換しつつ、Amazon S3Amazon Redshift、Amazon Elasticsearch Serviceにロードします。
  • Amazon Kinesis Streams
    • ストリームデータを処理するためのアプリケーションを独自に構築
    • Kinesis Data Streamsは一連のデータレコードを持つシャードのセットであり、各データレコードにはKinesis Data Streamsによって割り当てられたシーケンス番号があるため、 メッセージが失われず、重複されず、到着と同じ順序で伝送することが可能です。
  • Amazon Kinesis Analytics
    • ストリームデータを標準的な SQL クエリでリアルタイムに分析

Redshift

  • Redshiftは高速でシンプルかつ費用対効果の高いデータウェアハウスサービスです。
    • おもにBIや業務データ分析に利用します。ユーザー行動データの高速な処理には向いていません。
  • スナップショットの要領で課金

拡張VPC ルーティング

  • Redshiftクラスターに対する拡張VPCルーティングを有効にすることで、VPCに出入りするRedshiftクラスターのすべてのCOPYおよびUNLOADトラフィックを監視することができます。
  • Redshiftは拡張VPC ルーティングを使用すると、Redshift はクラスターとデータリポジトリ間のすべての COPY と UNLOAD トラフィックVPC を通るよう強制します。
  • 拡張された VPC ルーティングを使用することで、 VPC セキュリティグループ、ネットワークACLVPC エンドポイント、VPC エンドポイントポリシー、インターネットゲートウェイドメインネームシステム (DNS) サーバーなどのスタンダード VPC 機能を使用することができます。

Work Load Management

  • RedshiftのWLM(Work Load Management)を利用することで、クエリ処理を実施する際に、クエリ処理をキューとして実行順序を定義することが可能です。
  • WLMはRedshiftのクエリ処理に対して割り当てるRedshiftのリソースを指定する機能です。
  • 事前にWLMとしてキューを用意しておき、キューに対して割り当てるメモリの割合や並列度、タイムアウトの時間を指定することでクエリに対するリソース配分を決定したり、長時間実行されるクエリを止めてクラスタリソースを無駄遣いしないようにすることができます。

Redshiftスペクトラム

  • 利用することで、S3バケットに保存されたデータを直接分析することができます。

Mobile

API Gateway

  • Amazon API Gateway は簡単にAPI の作成と管理が可能となる完全マネージド型のAPIサービスです。
  • ユースケース
    • インターネットからアクセス可能なパブリックなWeb APIの基盤を提供する
    • ⾃社企業・企業グループ内でのプライベートなWeb APIの基盤を提供する
    • AWSサービス(例:Amazon DynamoDB 等)を独⾃のWeb API化する⼿段として利⽤する
    • サーバーレスアーキテクチャを実現する⼿段として利⽤する
  • API Gatewayはグローバルおよびサービスコールを含むさまざまなレベルでスロットルを提供します。
  • ロットリング制限設定はリクエストが多すぎるために バックエンドサービスが処理しきれなくなることを防ぎます。
    • たとえば、API所有者は自分のREST APIの特定のメソッドに対して毎秒1,000リクエストのレート制限を設定し、数秒間で毎秒2,000リクエストのバーストを処理するようにAmazon API Gatewayを設定することもできます。
    • Amazon API Gatewayは1秒あたりのリクエスト数を追跡​​し、制限を超えたリクエストは429 HTTPレスポンスを受け取ります。
  • Amazon API Gatewayキャッシュをプロビジョニングして、そのサイズをギガバイトで指定することで、API呼び出しにキャッシュを追加できます。
  • キャッシュは、APIの特定の段階用にプロビジョニングされています。これによりパフォーマンスが向上し、バックエンドに送信されるトラフィックが減少します。
  • キャッシュ設定を使用すると、キャッシュキーの作成方法と各メソッドに保存されるデータの有効期間(TTL)を制御できます。
  • API Gateway はLambdaと連携してサーバレスアーキテクチャーを構築する際に頻繁に利用されます。
  • API Gatewayトラフィック管理、認可とアクセスコントロール、モニタリング、API バージョン管理など、最大数十万規模の同時 API コール処理が可能です。
  • API Gateway には最低料金や初期費用はなく、受信したAPI コールと転送データ量に応じて課金されます

AppSyn

  • リアルタイム機能とオフライン機能を備えたフルマネージド GraphQL サービス管理やスケールを気にせずに使える
  • AppSyncを使用して、DynamoDBのデータをリアルタイムで最新の状態に保つコラボレーションアプリを簡単に構築できます。
    • これにより、アプリケーションはAmazon DynamoDBのデータにアクセスしたり、EC2インスタンスAWS Lambda関数がデータ処理を実行するなどの機能を実装することができます。
    • したがって、DynamoDBとAppSyncとを連携して、リアルタイム処理機能を実装することが可能です。

Application Integration

Amazon SNS

  • Amazon SNS には、代表的な機能として Mobile Pushとpub-sub 機能があります。
    • Mobile Push (プッシュ通知)
      • モバイルアプリが起動していなくても通知。
      • モバイルユーザは通知を受け取るか否か選択可能。
      • 通知をきっかけにアプリを起動してもらう。
    • pub-sub
      • 通知もできるが、分散アプリケーションの統合用途に用いられる。
  • メッセージングが主要な役割であり、特定のイベントをトリガーにワーカープロセスを起動する構成に利用します。
  • アプリケーションは「プッシュ」メカニズムを使用して、複数のサブスクライバーにタイミングが重要なメッセージを送信することができます。そのため、更新を定期的に確認したり、「ポーリング」する必要性がなくなります

SQS

  • SQSはアプリケーションコンポーネント間で転送されるメッセージを生成・管理する信頼性が高く拡張性の高いマネージドメッセージキューサービスです。
  • SQSはキューによってシステム処理を分散させて負荷分散を可能にします。
  • これはAWSリソースの水平方向のスケーリングに役立ちます。
  • SQSキューによって複数EC2インスタンスによる並行処理が可能となり、負荷分散や処理プロセスの最適化を達成することができます。
  • FOFOキュー
    • FIFOキューを利用することで高スループット、ベストエフォート型の順序付け、少なくとも1回の配信を可能にします。
    • FIFOキューはメッセージ順序を保証し、少なくとも1回のメッセージ配信をサポートしています。
  • メッセージ重複排除 ID
    • SQSはメッセージ重複排除 IDを利用することで重複メッセージを防ぐことが可能です。
    • メッセージ重複排除 IDは 送信されたメッセージの重複排除に使用するトークンです。
    • 特定のメッセージ重複排除 ID を持つメッセージが正常に送信された場合、5 分間の重複排除間隔の間、同じ ID を持つ送信メッセージは配信されません。

AWS Step Functions

  • AWS Step FunctionsはAWS の複数のサービスを利用して、サーバーレスなワークフローに構成できます。これはワークロードの作成・管理に利用されるものである
  • 分散アプリケーション・マイクロサービスの全体を「ステートマシン」と呼ばれる仕組みでオーケストレートできる
  • 定義したステートマシンは AWS コンソールから「ワークフロー」(右図) という形式で見やすく可視化できる
  • ステートマシンの各ステップの実行履歴をログから追跡できる

Customer Engagement

Amazon SES

  • 利用することでEメール機能を実装することができます。
  • アプリケーションの利用ユーザーに対して一斉メールによるお知らせを実施するといった使い方をします。
  • メール送信
  • メール受信
    • S3バケットに自動的に配信できます。
    • メッセージ受信時にLamdaを使用してカスタムコードを実行することや、特定のワードを含むメールを受信時に SNSを使って通知を配信することができます

Other

AWS Import / Export

  • 物理ストレージデバイスからAWSに大量のデータを転送するために使用できるサービスです

Amazon Elastic Transcode

  • 動画のトランスコード処理のジョブはパイプラインがリクエストを受信した順に処理が開始されます。ジョブの変換プロセスでは、入力ファイルサイズ、解像度、ビットレートなど多くの変数が変換速度に影響します。
    • 例えば、 iPhone 4 プリセットを使用した10 分の動画のトランスコード処理時間は約 5 分です。Amazon Elastic Transcodeが多数のジョブを受け付けると、ジョブはバックログ (キュー) に登録されます。

DLM

  • Amazon Data Lifecycle Manager (Amazon DLM)を使用するとEBSのバックアップであるスナップショットの作成、保存、削除を自動化できます。 定時バックアップをスケジュールして貴重なデータを保護します。
  • Amazon Data Lifecycle Manager (DLM)を使用するとEBSのスナップショット作成や削除をスケジューリングすることができます。DLMを利用することで次のような設定が可能となります。
    • EBSの定期的なバックアップスケジュールを実施して貴重なデータを保護する。
    • 監査担当者または社内のコンプライアンスが必要とするバックアップを保持する。
    • 古いバックアップを削除してストレージコストを削減する。

AWS Budgets

  • AWS Budgets には、カスタム予算を設定して、コストまたは使用量が予算額や予算量を超えたとき (あるいは、超えると予測されたとき) にアラートを発信できる機能が用意されています。
  • これはAWSの利用コストをリアルタイムで把握するためのモニタリングツールである

AWS Data Pipeline

  • AWS Data Pipeline は、データの移動と変換を自動化するサービスです。
  • AWS Data Pipeline はデータ駆動型のワークフローを定義して、タスクの正常な完了をトリガーにして、次のタスクを実行できます。
  • AWS Data Pipeline はDynamoDBに設定することが可能であり、定期的なデータ取得タスクを設定させることができます。

AWS STS

  • AWS Security Token Service (AWS STS) を使用して一時的セキュリティ認証を付与することができます。

ACM

  • SSL証明書を集中管理するためのAWSサービスとしてAWS Certificate Manager(ACM)を利用します。
  • ACMAWS サービスとユーザーの内部接続リソースで使用するパブリックまたはプライベートの SSL/TLS 証明書を作成・登録・管理することができます。
  • SSL/TLS 証明書を設定すると、SSL認証が利用されHTTPS通信によりネットワーク通信が保護されます。
  • AWS Certificate Manager を使用すれば、SSL/TLS 証明書の購入、アップロード、更新という時間のかかるプロセスを手動で行う必要がなくなります。

AWS SAM

  • AWS SAMは、サーバーレスアプリケーション構築用のデプロイツールです。
  • YAMLを使用して、サーバレスアプリケーションのLambda関数、API、データベース、イベントソースマッピングモデリングします。
  • AWS SAMはCloudFormationと連携してサーバレスアプリケーションを展開します。
  • その際は、SAM が SAM 構文を AWS CloudFormation 構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができます。

AWS SWF

  • Amazon SWF はステップまたは連続したステップがあるバックグラウンドジョブを構築、実行、スケールすることができるクラウド内の完全マネージド型の状態トラッカーおよびワークフローシステムです。

Active Directory


補足

タグ

  • 最大数 50
    • キー : 127文字
    • 値 : 255文字

侵入テスト

  • 8つのサービスでAWSの許可なく侵入テストを行うことができる

iSCSI

ストレージをSCSIでネットワーク接続 ストレージゲートウェイができる

暗号化

  • 法に相互に排他的な3つのオプションがあります。
    • Amazon S3管理キーでサーバーサイド暗号化を使用する(SSE-S3)
    • AWS KMS管理キーを使用したサーバーサイド暗号化を使用する(SSE-KMS)
    • 顧客提供のキーを使用してサーバーサイド暗号化を使用する(SSE-C)

SSE-S3

  • SSE-S3はAES-256暗号化を使用した暗号化方式です。
  • Amazon S3 で管理された暗号化キーにより実施されるサーバーサイド暗号化です。
  • ユーザーがキーに対するアクセス管理はできませんが、署名バージョン4によりアクセス制限が設定され、所有者であるAWSアカウントID以外からのアクセスを拒否します。
  • SSE-S3は暗号化と復号化をS3が自動で実施してくれるため最も管理に手間がかからない暗号化方式である

SSE-C

  • ユーザが管理する鍵により暗号化を実施できます。
  • これにより、S3上に置かれたコンテンツを柔軟に保護できるようになります。
  • ユーザーが用意した暗号化キーでのSSE-Cを使用すると、独自の暗号化キーを設定できます

SCP(Service Control Policy)

  • SCPは組織に含まれる複数のAWSアカウントに対してざっくりとした権限制御を行うための仕組みです
  • OU(組織単位)
    • OUに対してSCPはデフォルトでフルアクセス権限が付与されており、ホワイトリスト形式のSCPが付与されても、他のリソースに対してフルアクセス権限が継続されます。

IAMデータベース認証

  • EC2インスタンスがIAMデータベース認証を利用してDB インスタンスにアクセスが可能です。
  • この認証方法では、DB インスタンスに接続するときにパスワードではなく、認証トークンを使用します。
  • 認証トークンはAmazon RDS がリクエストに応じて生成する一意の文字列であり、AWS 署名バージョン 4 を使用して生成されます。
  • トークンには 15 分の有効期間があります。
  • 認証トークンは IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。

ROA

  • Route Origin Authorization (ROA) は、RIR を介して作成されるドキュメントです。
    • 地域インターネットレジストリ (RIR、Regional internet registry)
      • 五つの地域インターネットレジストリ(RIR)では、 リソース証明書とROAが提供されています。
  • これには、アドレス範囲、そのアドレス範囲を公開することを許可された ASN、および有効期限が含まれています。
    • ASN(AS番号)とは、ASに一意に振られる番号です。
    • ASとは、BGPという経路制御プロトコルの制御単位であり、ネットワークのカタマリです。
      • BGPについては詳しいことはインターネットを検索すればたくさんの記事が出てきますので、そちらをご参照ください。
  • ROAAmazon が特定の AS 番号のアドレス範囲を公開することを承認します。
  • さらにAWS アカウントに対してアドレス範囲を AWS に持ち込むことを承認するには、アドレス範囲について RDAP の注釈で自己署名付きの X509 証明書を発行する必要があります。
    • Registry Data Access Protocol (RDAP)
      • IPアドレス等のレジストリに登録したデータにアクセスするためのプロトコルで、 WHOISプロトコルの後継として、 RFC7480~7485において標準化されたものです
      • RDAPの主な特徴としては、以下が挙げられ、TCP43番ポートを用いてテキストベースで通信されるWHOISとは異なっています。
        • HTTP(S)にて通信されること
        • 応答がJSON (JavaScript Object Notation)*2形式で構造化されていること
  • 証明書にはパブリックキーが含まれており、AWS はこれを使用してあなたが提供する認証コンテキスト署名を確認します。
  • プライベートキーを安全に管理し、これを使用して認証コンテキストメッセージを署名します。
  • これによって、既存のオンプレミス環境で利用していたホワイトリストAWSに移行することが可能となります。

クラスタープレイスメントグループ

SAML

  • SAML(Security Assertion Markup Language)はインターネット上で、IDやパスワードなどの認証情報を連携するためのXMLベースの仕様です。
  • SAMLは主にエンタープライズアプリケーション間の認証で使われています。
  • SAMLMicrosoft Active Directoryを使用しているため、AWSクラウドへのAPIアクセス用にSAMLベースのフェデレーションを設定できます。
  • AWS Single Sign-Onなどのサービスを利用することで、SAMLによる認証の仕組みを実現することが可能です。
  • AWS SSO は SAML IdP 機能を AWS Managed Microsoft AD または AWS SSO ディレクトリに追加します。
  • それにより、ユーザーは、AWS マネジメントコンソール やサードパーティー製アプリケーションなど、SAML をサポートするサービスへの SSO が可能になります

オンプレとAWSとの接続

Disaster Recovery

  • パイロットライト
    • 利用可能であるアプリケーションの最小バージョンを準備しておくことをパイロットライトのこと呼びます。
    • パイロットライトではサーバーなどセッティングされた構成を他のリージョンなどに準備しておいて、非常に稼働させて利用することができます。
    • パイロットライトという用語は、最小限のバージョンの環境が常にクラウドで実行されているDRシナリオを表すためによく使用されます。
    • AWSでは、AWSでシステムの最も重要なコア要素を設定して実行することでパイロットライトを維持できます。
    • 回復時には、重要なコアを中心に本格的な本番環境を迅速にプロビジョニングできます。
  • マルチサイト
    • マルチサイトの場合は、起動しているサーバー構成を準備して、マルチリージョンやマルチAZ構成を利用する構成のことです
  • バックアップ&リストア
    • これはスナップショットやAMIを別リージョンに保持しておくことです。これは最もコストがかからないDR対応として利用されます。
  • ホットスタンバイ
    • これは稼働可能な状態となっているインフラを準備し、アクティブにするだけで切り替えることができるスタンバイ構成のことです。

AMI

  • Amazon EC2 instance store-backed AMI
    • 使用してEC2インスタンスを作成すると、そのインスタンスのデータはインスタンスストアに保存されます。
    • インスタンスストアボリューム上のデータはインスタンスの存続期間中のみ持続するため、インスタンスが終了するとデータは自動的に削除されます。
    • インスタンスストアはインスタンス用のブロックレベルの一時ストレージです。
    • このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。
    • インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージとして最適です。
    • また、インスタンスのフリート全体でレプリケートされるデータ (負荷分散されたウェブサーバープールなど) にも適しています。

IPフローティング

ARN

  • Amazonリソースネーム(ARN)によりAWSリソースを一意に識別します。
    • IAMポリシー
    • Amazon Relational Database Service(Amazon RDS)
    • タグ
    • APIコール
    • etc ...
  • AWS全体でリソースを明確に指定する必要がある際にはARNが必要です。
  • ARNは以下のような形式で定義されています。

経験をアウトプット

以下の記事を読んで感銘を受けた。

lacolaco.hatenablog.com

これまでこの記事で書いていたことは、読んだ内容をそのまま書いているだけだった...と気づいた。

書けば覚えるといったような形でそのまま書いているだけだった。

自分の考えがまるでない。これじゃ、そこらへんにあるアフィリエイト記事と同じ..いや、それ以下だ。 こんなの何の意味もなかった。

このブログを始めた目的も言語化をできるようにするためだった。 なのに、俺がやっていたことは言語化とは程遠い転写だ。

読んだ本にせよ、学んだ技術にせよ、 そこから色んなコンテキストを組み合わせることで、このブログが面白いものになる。 こんなことに、この記事を読むまで気づかなかった。恥ずかしい。

経験をアウトプットできるのは自分だけ

俺は、俺が思ったこと、作ったものをアウトプットすることに意味がある。 時間をかけ、たくさん経験して、自分だけのブログにするのだ。

それがみんなの役に立ったら万々歳というスタンスでいく。 ここからが始まりだ。

「1440分の使い方」を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:ケビン・クルーズ
  • 書籍名:1440分の使い方 ──成功者たちの時間管理15の秘訣
  • 出版社:パンローリング株式会社
  • 発売日:2014/7/30
  • 頁 数:228ページ

「1440分の使い方 ──成功者たちの時間管理15の秘訣」とはどんな本?

7人の億万長者、239人の起業家、13人のオリンピック選手、29人のオールAの学生にインタビューして成功者共通の「生産性向上の習慣」を書いた書籍だ。

読んでから3ヶ月継続して実践しているが、時間の使い方が上手くなっていると目に見えて感じる。

成功者の時間術ですが難しいことではなく、普通の一般人である自分でも読んですぐ実行できた。 当たり前のことだと感じものも多くあるが、できていないのでハッとさせられることがある。

読者が自分にとってのベストプラクティスを選ぶような形で実践するのが良いと思う。

本の目次

以下は本書の目次です。

  • 1 1440分の威力
  • 2 適切な優先順位の重要性
  • 3 ToDoリストをやめる
  • 4 先延ばし癖を克服する
  • 5 罪悪感なく5時に退社する方法
  • 6 成功者たちのノート術
  • 7 3210メール術
  • 8 グーグル、アップル、ヴァージンの会議術
  • 9 大成功へと導く小さな一言
  • 10 強力なパレートの法則
  • 11 ハーバードの3つの質問
  • 12 テーマのある毎日
  • 13 「一度しか触らない」ルール
  • 14 朝を変えて、人生を変える
  • 15 すべてはエネルギー次第
  • 16 すべてをまとめたE-3C方式
  • 17 まだまだある!
  • 18 7人のビリオネアに学ぶ時間管理の秘訣
  • 19 13人のオリンピック選手に学ぶ時間管理の秘訣
  • 20 29人のオールAの学生に学ぶ時間管理の秘訣
  • 21 239人の起業家に学ぶ時間管理の秘訣

この本のおすすめポイント

上の中でも自分が実践しているものを抜粋する。

目標設定

この本ではMIT(Most Important Task)を見極めることの大切さを書いている。

研究によると「日々のMITを明確にすることは、生産だけでなく幸福感および気力の向上にもつながる」

目標はどんな分野でもいいが、具体的に、評価できるようにようにせよ。 もしMITに取り組まない週があったとしたら、その一週間は無駄だったということになる。

ToDoリストをやめる

これは結構衝撃的だった。

ToDoリスト = 消えることのないウィッシュリスト

どういうことかというと、ToDoリストにはいつになったら全部終わるのかという具体的な計画がないので、ずっと無くなることがないことが起こる。

他にも以下のようなデメリットがある。

  • 数分しかかからないものと、1時間以上かかる項目が混在しているのがいけない。
  • ToDoリストを取り出して、次にどれを片付けてるべきだろう、と考えるのが無駄である
  • 重要なタスクより急ぎのタスクを安易に飛びつきやすくしてしまう

では、どうするのか?

スケジュールに基づいて動くのだ!!

本当にやり遂げたいことがあるなら、きちんと予定を立てなくてはならない。

アート・オブ・チャーム共同創業者によれば、スケジュールは15分単位で1日の予定を組むのが効率が良いらしい。 電話やメール、運動もこの方法で管理する。 自分もこの本を読んでからiPhoneのカレンダー(Googleカレンダーも同期させている)を使って管理している。

  1. 重要なことは全て、やる時間を決め、スケジュール表に入れておく
  2. 重要な項目には1日のうちできるだけ早い時間帯を割り当てる
  3. 目標は取り下げない
  4. 「タイムブロッキング」した予定は、診察の予約だと思って対処する

ノート術

常にノートを持ち歩き、何でも書き留める。アイデア、新しい人に出会ったらその人の情報、得た知識、面白いこと、とにかく何でも書き留めるのだ。 書き留めなければ忘れる。

筆者のノート活用術

  1. 新しいノートを買う(モレスキンがオススメ)気分が上がる!
  2. パイロットの極細のジェルインクボールペンを何本か買う
  3. ノートの表紙に名刺を貼る - 無くしても大丈夫!
  4. 表紙の裏に今日の日付を書く - 対象のノートを見つけやすくなる
  5. 忘れたくないものは何もかも書き留めよう
  6. 素晴らしい助言やインスピレーションを掻き立てる言葉に出会った時は、ノートの後部ページにまとめて書く
  7. 電話や会議の元に日時と相手の名前を書く。内容はどんなことでも書く
  8. 初対面の人たちとの会合では名前を覚えやすくするためにテーブルの図や位置まで記録する
  9. 最後のページまで使い切ったら表紙の裏側に完了日を書く
  10. 本棚の過去の日記の隣にそのノートを並べる - 全人生の詳細な記録、これにて完成!!
  11. 毎年元日に前年分の日記にざっと目を通すことを新しい習慣にする - 必要な部分は今年度分に移しておく

また筆者は以下のような記号を使ってわかりやすく管理している

  • なるべく早くスケジュールに追加したいもの(ToDo)「□」
  • スケジュールに入れる「○」
  • フォローアップ事項「!」
  • 質問事項「?」
  • 重要な検討事項「*」

「一度しか触らない」ルール

人は何度も同じことを繰り返す。数分でできることは後でやろうと考えずに今やるのだ。

メールなどの事務作業、掃除もそうだ。これは後でやろうとかが多いので出来ることはすぐやるべきだ。

すべてはエネルギー次第

1日のうち同じ1時間でもその時の精神状態によって生産性は大いに変わる。

  • 最重要の仕事が一番捗る時間帯
  • だらけがちな時間帯
  • 頭を使わない仕事ならなんとかやれる時間帯 を把握することで、いつ何をすべきか工夫することが出来る。

そのニーズに自分の能力をうまく適合させるために!

また、集中するためには休憩も大切だ。

自分はポモドーロテクニック(25分集中してやって5分休憩を繰り返す)を実践している。 長時間だらだらやるより、短時間集中するのを小出しにする方が生産性が上がるのだ。

自分のエネルギーを最大化させることの大事さをこの章では言っている。

最後に

  • たった一言で未来のスケジュールの空きを確保できる方法 ⇨ 「No」と言うこと
  • パレートの法則 - あなたの80対20を考えよう
  • 自分の時間を作るために人を雇う

上記のような当たり前だけ出来ていないことなど様々なポイントを実例を交えながら書いている。

目次17以降は成功者の一日(1440分)の使い方や習慣について書かれている。

1~16同様に自分に合いそうなものを選択してやってみるのが良いのだろう。

是非読んでみて実践してほしい。

プライバシーポリシー

こんにちは管理人のue_shoです。下記、「プライバシーポリシー」に関して記載致しましたので、ご一読願います。

当サイトに掲載されている広告について

当サイトでは、第三者配信の広告サービス (A8.netAmazonアソシエイト) を利用しています。

このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 『Cookie』(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。

当サイトへのコメントについて

当サイトでは、スパム・荒らしへの対応として、コメントの際に使用されたIPアドレスを記録しています。

これはブログの標準機能としてサポートされている機能で、スパム・荒らしへの対応以外にこのIPアドレスを使用することはありません。

また、メールアドレスとURLの入力に関しては、任意となっております。 全てのコメントは管理人であるredoが事前にその内容を確認し、承認した上での掲載となりますことをあらかじめご了承下さい。

加えて、次の各号に掲げる内容を含むコメントは管理人の裁量によって承認せず、削除する事があります。

  • 特定の自然人または法人を誹謗し、中傷するもの。
  • 極度にわいせつな内容を含むもの。
  • 禁制品の取引に関するものや、他者を害する行為の依頼など、法律によって禁止されている物品、行為の依頼や斡旋などに関するもの。
  • その他、公序良俗に反し、または管理人によって承認すべきでないと認められるもの。

免責事項

当サイトで掲載している画像の著作権・肖像権等は各権利所有者に帰属致します。権利を侵害する目的ではございません。記事の内容や掲載画像等に問題がございましたら、各権利所有者様本人が直接メールでご連絡下さい。確認後、対応させて頂きます。

当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。

当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。

当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

プライバシーポリシーの変更について

当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。

修正された最新のプライバシーポリシーは常に本ページにて開示されます。

運営者:ue_sho

ショートカットは時間を節約する

最近「アウトルック活用術セミナー」というものを受けてみた。

というのも自分の会社は日常的にOutlookを使用しており、もしこのまま会社にいるとすれば今学んだことは一生使える物なのでは..? と思ったからである。

結果的に受けたのは大正解であった。

何よりもOutlook以外にもショートカットを活用していこうモチベーションが上がったのが良かった。

アウトルック活用術セミナー

概要を簡単に押さえておく。

結論をいうと、「ショートカットを駆使しろ!」ということである。

平均的な会社員は 業務時間の約35% をメール業務に費やしているらしい。 一年に換算すると 500時間 使っているらしい。

これを聞いたとき目を疑った。自分は長くても1日1時間程度である。(自分からメールを出す機会があまり無いので..)

周りの社会人はそんなにメール業務をして無駄すぎるだろと感じた。

その無駄をショートカットを駆使すること可能な限り削減できるという内容だった。 自分のやっていた方法とは違い、かなり参考になったので皆さんにも「アウトルック活用術セミナー」オススメする。

主催者の書籍「アウトルック最速仕事術 年間100時間の時短を実現した32のテクニック」も有用だろう (自分は買ってないので分からないが、講座と同じ内容だと思われる)

ショートカットで時間を節約

さて、本題に戻そう。

上の講座ではたった10個のコマンドを覚えるだけで、かなりの時間を節約できた。 会社でも家でも使えてすでに講座で教わった2時間以上の節約ができている実感がある。

自分はソフトウェアエンジニアだ。 一日中パソコンを触るので、ショートカットを覚えるだけで多くの時間が節約できる。

Google Chromeであったり、VSCodeと呼ばれるプログラミングのエディタであったり、PowerPoint, Excel... 自分の業務で使うものは積極的にショートカットを覚えるべきだ。

自分の業務で使うものであれば、日常的に使うのでコマンドも覚えやすいだろう。

アプリケーションだけでなく、Windows, MacといったOSにもショートカットがあるので、そちらも余力があるなら覚えた方がいいだろう。

ショートカットによる時間節約を甘くみてはいけない

「これからの人生の中で、今が一番若い」

今覚えればこれからの人生に習得にかかった時間以上の時間が生まれる。

『「Why型」思考が仕事を変える』を読んだ

本の基本情報

本の基本情報について紹介する。

  • 著者名:細谷 功
  • 書籍名:「Why型」思考が仕事を変える ── 鋭いアウトプットを出せる人の「頭の使い方」
  • 出版社:PHP研究所
  • 発売日:2010/8/19
  • 頁 数:228ページ

『「Why型」思考が仕事を変える』とはどんな本?

著者である細谷功さんの本「具体と抽象」を読んだことがあったので、別の本を手に取ってみた。それがこの本だ。

「前例主義」「マニュアル人間」「ダラダラした会議」…仕事にはびこる思考停止のワナを「Why型思考」と「What型思考」を元に解説している本だ。

この本はこのWhy型思考の身に付け方およびビジネスでの活用法を説く。 自分は完全に「What型」思考で思い当たる節が多く、何も考えられていなかったんだなと痛感した。

Why型思考を身につけたいと思うなら是非読んでみて欲しい。

本の目次

以下は本書の目次です。

  • 第1章 イントロダクション ─ あなたは「そのままくん」か「なぜなぜくん」か?
  • 第2章 職場にはびこる「WhyなきWhat病」
  • 第3章  Why型思考とは何か?
  • 第4章 WhatとWhyを切り分ければ「世界が変わって見える」
  • 第5章 Why型思考のビジネスへの応用例
  • 第6章 「そのままくん」の原点はWhat型教育にあり
  • 第7章 Why型思考を鍛えるために
  • 第8章 Why型思考の「使用上の注意」

この本のおすすめポイント

適当に自分が感じた部分のみピックアップしていく。

WhyなきWhat病

What型思考は、今ある規則やルールは律儀にそれを遵守することを常に優先で考える つまり、「マニュアル人間」である。

いやーーーこれは自分です。でも、悪いことだとは全然思ってません。 むしろ良いことだと思います。

ただ、なぜそれをやるのか考える必要があるということですね。 これはわかったつもりになってやってないことが多い。

他にも、色々なWhyなきWhat病の例が出てきます。 例えば、 * 聞かれた質問に対して、「何々に書いていました」と回答する * 前例に固執してしまうこと。実績はあるのか?やそれ前にやったことあるのか?など * 成功体験をそのまま使おうとする。なぜ成功したのかは考えない。 * 顧客を忘れて技術力に走ってしまう「作り手視点」のみの商品 * メッセージなきドキュメント

かなり自分に当てはまっており耳が痛い。自分はWhat思考で固まってしまったことに気づいた。

単なる「コピー&ペースト」だけして「そのまま使って」いたのでは、そのこと自体に価値がないことに加えて、とんでもない誤解をしたり情報の誤用をしたりすることになるかもしれない。

今までの定型業務でも「なぜこれをやるのか?」を追求していくなど、本来の目的にしたがってそれを加工していく思考力が大事だ。 (大企業はWhat型が蔓延しているので、こういったことは煙たがられるので周りの人との関係も注意する必要がある)

Why型思考とは何か

「今あるもの」や「目に見えるもの」から発想するのではなく、そもそもどういう理由で何をやらねければならないのかという、目に見えない将来を見越した本質の議論が求められている。

目に見えないもの(正解はないもの)を考えることがWhy型思考

「なぜ?」を問うことで表面だけ見えているものの裏の世界を見ることができる。 しかし、一回だけの「なぜ?」はWhat型思考と同じである。深く掘ることで裏の世界が見えるようになる。

自分は「なぜ?」をしたときは一度で止まっていたので、本質をみれていなかった。 本質を見極めるためにも、習慣として「なぜ?」を考えるようにすることが大切だと感じた。

WhyとWhatを切り分ける

Whyと Whatを切り分けることでどのような考えになるかを具体例を元に書いてある。

Whatの部分が一人歩きして、それを守ることが目的になっている

上記のように「一人歩き」の話の中であった食事マナーの例から、ルールだからやっているというものは数多くあり印象に残った。

これはWhatだな、これはWhayだなと切り分けができるようになると物事を考えるときに役立ちそうだ。

Why型思考のビジネスへの応用

Whyという「ものの考え方」や「実際に起きていることの原因や背景」に目を向けている上司とWhatという実際に現場で起こっている事象そのものに目を向けている部下とでは会話がかみ合わなくなるのは当然のことでしょう。

上司がWhy型思考で、部下がWhat型思考だとギャップが生まれる。逆も然り。(かなりの場面で起こっている)

上司から、クライアントから頼まれたら、なぜそれが必要なのか一歩進んで考える、確認する、聞くことで成果物の品質や部下のせいちょうスピードが変わっていくだろう。

「そのまま君」の原点はWhat型教育にあり

What型 - 「育てられる」(他動詞) Why型 - 「育つ」(自動詞)

What型教育。つまり、学校教育のような教えてもらうことは、時間に比例して成長していく。 しかし、爆発的に型破りな成長をする可能性も少なくなる。

Why型教育とは、師弟関係のように教えずに見て学べ!のようなもの。 教えてもらえず雑用が多いので「自ら技を盗む」ことを考えるので、爆発成長をすることがある。 (うまくいかない場合ももちろんあり)

「What型教育は一方向でもよいが、Why型教育は双方向でなければならない」ということもあるでしょう。What型教育では最悪教える側が一方的にしゃべりまくれば一定の目的は達せられたことになりますから、そこでたとえ質問がなくても問題はないわけですが、Why型教育というのは双方向ですから、質問がないという状態が放置されることはないはずです。Why型/What型の観点から見ると、これら二つの要因が日本人が質問下手になっていることに大きな影響を及ぼしていると結論づけられるでしょう

自分も会議では全然会話に参加できず、時間を無作為に過ごしていることが多い。なぜを問うような質問をすることで自分の理解を深めたい。(無闇矢鱈になぜ?と問うのも問題な気がするが...適度にしていく)

Why型思考を鍛えるために

Why型の勉強は純粋に自発的なものでなければならないというのが肝に銘じておくべき特徴です。「いやいや勉強する」というのはWhat型にはあってもWhy型にはありえないのです。

反復練習をして同じような問題を何問も解いてパターンを暗記することにあまり意味はありません(それはWhat型のトレーニングになってしまうからです)。多数の問題を解くとすれば、それはなるべく違う解き方で解くような「バリエーション」を追求することが重要です。

問題を解きまくってパターンを暗記する、身に覚えがありすぎる... 自分は競技プログラミングをしていたのですが、いつもパターンだけ覚えて実際にどういったアルゴリズムなのか、なぜこのアルゴリズムを使うと良いのか考えられていなかったなーと痛感している。 実際に結果にも現れていて、あまり伸び代がなかったように思う。(AtCoder 緑)

ただし、反復練習をして体に染み込ませることも大事なので、そこら辺も自分で考える必要がある。

読書にしたって小手先のテクニックを覚えるより、まずはじっくりと考えてその理由や背景などに思いを巡らすとともに、自分の思考力を鍛えて読書後も含め新しい発想を生み出すのがWhy型の読書法。

したがって、必ずしも量とスピードは重視せず、途中で立ち止まって考えたり、何度も読み返すこともあるでしょう。この場合に適した本はいわゆる「古典」と呼ばれるような、読み継がれてきた名作が一般的には適当。

プログラミングにしたって何故この技術が流行っているのか?となぜ?を問い続けていくことが自分のスキルにつながる。

「Why型の人にはWhat型とWhy型の区別がつくが、What型の人にはその区別がつかない」ということです。つまり、あなたが周りの人やその考え方を見て、「隣の課の新入社員の発言や仕事のやり方はいつもWhat型だ」とか「今度来た○○課長はいつもWhy型のコメントを返してくる」といったことの「区別」がつくようになれば、それはあなた自身の思考回路がWhy型になってきたことを意味しています。逆の言い方をするとこれがわからないうちは自分自身の思考回路がWhat型である可能性が非常に強いと考えてください。

まだまだ判断がついていないので、意識して観察し良い点は取り入れられるようにする。

Why型思考になるために意外に重要な事項として普段から心がけておくべきこととして「答えがない状態に耐える」、あるいは「慣れる」ということが挙げられるかと思います。

自分は学生時代から答えがないものが嫌いだったので、国語みたいな教科が苦手でした。考えを改めていき、答えがない状態を楽しめるようになっていきたい。

最後に

他の章ではWhy型思考の「使用上の注意」を書いてあり、必ずしもWhy型思考が正しいわけではないことも知っておかなけらばならない。

ただ、必ずWhy型思考は自分を成長させる。私はWhy型思考を持って生きていきたい。