HTML セクショニングと見出しのマークアップ

最近の案件でマークアップに関していろいろ気づきがあったのでメモしておきます。

見出しタグが入らないエリアは <section> で囲まない

良くないと思われる例

<section>
  <p>テキストです。</p>
</section>

改善例

<div>
  <p>テキストです。</p>
</div>

<section> の中には見出しタグはひとつにする

良くないと思われる例

<section>
  <h1>見出しです。その1</h1>
  <h2>見出しです。その2</h2>
</section>

改善例

<section>
  <h1>見出しです。その1</h1>
  <section>
    <h2>見出しです。その2</h2>
  </section>
</section>

もしくは

<section>
  <h1>
    <span class="title01">見出しです。その1</span>
    <span class="title02">見出しです。その2</span>
  </h1>
</section>

見出しタグは順番にマークアップする

良くないと思われる例

<section>
  <h2>見出しです。その1</h2>
  <h1>見出しです。その2</h1>
</section>

改善例

<section>
  <h1>見出しです。その1</h1>
  <h2>見出しです。その2</h2>
</section>

できない場所は無理やりJSで入れ替えるなども方法としてはあがるようですが、見出しがh1→h2→h3の順でないと、SEOに悪影響あったりします? などを見るとSEO的には関係なさそうです。

<nav> の中には見出しタグがあったほうがよい

良くないと思われる例

<nav>
  <ul>
    <li><a href="#">ナビゲーション</li>
    <li><a href="#">ナビゲーション</li>
    <li><a href="#">ナビゲーション</li>
  </ul>
</nav>

改善例

<nav>
  <h2>メニュー</h2>
  <ul>
    <li><a href="#">ナビゲーション</li>
    <li><a href="#">ナビゲーション</li>
    <li><a href="#">ナビゲーション</li>
  </ul>
</nav>

要素構成上の問題でもありますが、<nav> タグ内に見出しがないと Untitled NAV となってしまいます。
nav要素内に見出しがない |  clear sky source
ただどうやらエラー認定はされないようでここはあまり気にする必要はないかもしれません。

まとめ

宗教論争的な面が多くありそうな話なのでその時々のルールを守って快適に仕事が進むのがいいと思いますが、
基礎的なルールで間違いていたところがあったので、まとまった時間でもう少し学びたいなと思いました。
<article><aside> あたりもしっかりしようと思います。
HTMLそれなりに触っては来たけど何も分かっていない気がしてきました。

他参考サイト

AWS クラウドプラクティショナー認定試験のために覚えたサービス

クラウドラクティショナー取得のための勉強に際して覚えたサービスと短い説明をまとめておきます。
基本的にプラクティショナーレベルの場合、サービス名称と概要を覚えておけば、サービス名を聞かれる問題はなんとかなると思います。(EC2やIAMなどのメジャーどころはもちろん除きますが)
以下にあげた以外にも実際の出題はあったと思うので、ある程度広く浅くが大事かなと感じました。

セキュリティ関連

AWS Shield

分散サービス妨害(DDoS攻撃)に対するマネージド型の保護サービス。
AWS で実行しているWebアプリケーションを保護する。
「Standard」と「Advanced」の2つのレベルでサービスがあり、「Standard」は追加料金なしで保護の適用を受けることが可能。
攻撃通知や分析、レポート生成は「Advanced」を選択することでDDoS Response Teamにアウトソースすること、AWS WAFサービスが無制限に利用可能。

Amazon Inspector

AWSのEC2上にデプロイされたアプリケーションのセキュリティとコンプライアンスを向上させるための、脆弱性診断を自動で行うことができるサービス。

AWS WAF (Web Application Firewall)

マネージド型のWebアプリケーションファイアウォールサービス。
アプリケーションの可用性低下、セキュリティの侵害、リソースの過剰消費などの一般的なWebの脆弱性からWebアプリケーションを保護する。
基本利用料は無料でWebセキュリティルールに基づき課金される。セキュリティルールはユーザーが設定する必要がある。

IAM (Identity and Access Management)

ユーザーのAWSクラウドリソースへのアクセス管理サービス。
AWSのユーザーとグループを作成および管理し、アクセス権を使用してAWSリソースへのアクセスを許可および拒否できる。

セキュリティグループ

1つ以上のインスタンストラフィックを制御する仮想ファイアウォール

  • 許可のルールの指定が可能
  • 拒否のルールは指定は不可能
  • インバウンドトラフィックとアウトバウンドトラフィックのルールを個別に指定可能

MFA (Multi-Factor Authentication)

他要素認証。
コンソールログイン時にMFAを有効化することでアカウントを保護できる。

テクノロジー

コンピューティングサービス

EC2 (Elastic Compute Cloud)

サイズ変更可能なコンピューティング性能をAWSクラウド内で提供するウェブサービス

AMI (Amazon Machine Image)

EC2インスタンスのテンプレート。OS/アプリケーション/データなどの様々な情報を提供する。

  • クイックスタートAMI
  • マイAMI
  • AWS Marketplace
  • コミュニティAMI から選択/作成できる。

ELB (Elastic Load Balancing)

同じ構成を持った2つのEC2インスタンスを別々のAZに配置し、ユーザーからのリクエストラフィックを分散できる。
(マルチAZ配置。高可用性・耐障害性を向上することができる)

Auto Scaling

EC2インスタンスを必要なときに自動で増減できる機能。
1つのインスタンスのサイズ(性能)ではなく、数の増減でスケーリングする。(水平スケーリングの自動化)

EBS (Elastic Block Store)

EC2インスタンスにアタッチして使用するブロックストレージボリューム。
ボリュームタイプは変更が可能で、同じアベイラビリティゾーン内の複数サーバー間で自動的にレプリゲートされるなどの特徴がある。

ストレージサービス

S3 (Simple Storage Service)

インターネット対応の完全マネージド型のオブジェクトストレージ。
無制限のストレージ容量、高い耐久性(イレブン・ナイン)、インターネット経由でアクセス可能という特徴がある。

S3のアクセス権限

デフォルトでプライベート設定。以下の3種類のなかからアクセス権を設定する。

ネットワーク

VPC (Virtual Private Cloud)

AWSクラウド内にプライベートなネットワーク環境を構築するサービス。
リージョンを選択して複数のアベイラビリティゾーンをまたがって作成することができる。
EC2やRDSといったサービスはVPCを使用する場合VPC内で起動される。

ネットワークACL (Network Access Control List)

VPCのサブネットに対して設定する仮想ファイアウィール機能。
必要な要件があった場合に設定する、追加のセキュリティレイヤーとして機能させることができる。
デフォルトでインバウント(受信)とアウトバウンド(送信)が許可されている。

CloudFront

世界中に150箇所以上あるエッジロケーションを使い、最も低いレイテンシー(遅延度)でコンテンツを配信できるコンテンツ配信ネットワーク (Contents Delivery Network/CDN)サービス。

Route 53

エッジロケーションで使用されるDNSサービス。
一般的なDNSサービスと同様に、ドメインに対してのIPアドレスマッピングしてユーザーからの問い合わせに回答する。

データベースサービス

RDS (Relational Database Service)

AWSで簡単にリレーショナルデータベースを使用することができるサービス。
オンプレミスで使われているデータベースエンジンをそのまま簡単に使うことができる。

DMS (Database Migration Service)

オンプレミスの従来のデータベースからAWSへのデータベース移行を簡単にするサービス。

Dynamo DB

NoSQL型の高いパフォーマンスを持ったフルマネージド型のデータベースサービス。
使用の際にはリージョンを選択するだけで、自動的に複数のアベイラビリティゾーンの複数の施設で同期・保存が開始される。(マルチAZな環境)

リレーショナルデータベース(RDS)と、非リレーショナルデータベース(Dynamo DB/NoSQL)

リレーショナルデータベース(垂直スケーリング) => 空席予約などの厳密な確定処理に向いている。大量のデータ更新や読み込み処理は不向き。
非リレーショナルデータベース(水平スケーリング) => 大量なアクセスを処理することに向いている。複雑なクエリ、トランザクションを必要とする処理は不向き。

Amazon Redshift

高速でスケーラブルなデータウェアハウスサービス。
データウェアハウスとデータレイクすべてにわたる分析をシンプルで費用対効果高く行える。

管理サービス

Amazon CloudWatch

EC2インスタンス、RDSインスタンスDynamo DBテーブルなどの各インスタンス、EBSのディスクI/Oなどの現在の状態、情報をモニタリングするサービス。
標準メトリクスではAWSが管理している範囲の情報をお客様側での追加の設定なしで収集している。
EC2のメモリやアプリケーションのステータスなどOS以上の範囲、およびお客様がコントロールしている範囲に関しては CloudWatch を使用してカスタムメトリクスとして書き込むことができる。

CloudWatch Logs

EC2のアプリケーションのログ、Lambdaのログ、VPC Flow Logsなどのログを収集する機能。
CloudWatchエージェントをインストールして少しの設定が必要。

Trusted Advisor

AWSアカウント環境の状態を自動的にチェックして回り、ベストプラクティスに対してどうであったかを示すアドバイスをレポートするサービス。

CloudTrail

AWSアカウント内のすべてのAPI呼び出しを記録するサービス。
API呼び出しを記録するということはAWSアカウント内におけるすべての操作を記録するため、監査や調査に最も適している。

AWS Config

AWSリソースの変更履歴を記録する。VPCの変更記録など誰がいつ何を変更したかが自動で記録される。

CloudFormation

AWSの各リソースを含めた環境を自動作成/更新/管理するサービス。
テンプレートを用いるので、同一のAWS環境を何度でも自動で構築することが可能。

Elastic Beanstalk

Webアプリケーションの環境を簡単にAWSに構築するサービス。
CloudFormation との違いは、Elastic Beanstalkはテンプレートが必要ない(設定パラメータを提供する)。

請求と支払い

請求ダッシュボード

どのサービスにどれくらいコストが発生しているかを確認する画面。

コストエクスプローラ

ROIの計測等で用いるコスト分析機能。
設定したコスト配分タグにてデータが可視化される。

コスト配分タグ

設定したキーと値によってタグ分けする機能。
コストエクスプローラーで可視化したり、CSV形式でダウンロードする際に使われる。

請求アラーム

CloudWatchメトリクスの1つなので、SNS(Simple Notification Service)と連携して設定すると、特定の金額を超えたときにメール送信することなどができる。

AWS Organizations

複数アカウントを一括で階層管理するサービス。
Organizationsの一括請求を使用することで複数アカウントの請求を1つにまとめることができる。

AWS簡易見積りツール

AWSでどれくらいコストがかかるのかを事前に知るために使うことのできるツール。

TCO計算ツール

AWSへの移行、導入を検討している際に、オンプレミスで構築した場合とのコスト比較をレポートしてくれるツール。
経営層やシステムを所有する企業へのプレゼンテーションに利用ができる。
TCO = Total Cost of Ownership(総保有コスト)

AWSのサポートプラン

ベーシック/開発者/ビジネス/エンタープライズ の4プランがある。
https://aws.amazon.com/jp/premiumsupport/compare-plans/

AWS(クラウド)周りの聞き慣れない用語

AWSクラウド)周りの聞き慣れない用語

AWS 認定試験(クラウドラクティショナー)勉強の際に、ネットワークやサーバー周りに疎い自分からすると理解が難しい単語によく出くわしました。
カテゴリーばらばらで適切でないかもですが、サービス名以前に用語の理解が必要だなと感じたので、最初に理解しづらかった単語と意味を並べていきます。

共通/基礎部分

マネージド

直訳すると「管理する」なので、
マネージドサービス = システム側での管理がされたサービス = ユーザー側での管理があまり必要のないサービス
のように考えました。

さらに「フルマネージド」となると、一括で管理されたサービスという意味合いになるので、
さらにユーザー側での管理が必要のないサービスという認識。

デプロイ

日本語訳的には配置する、展開すること。
主にネットワークを通じて提供されるWebアプリケーションなどのシステム開発工程において、システムを利用可能な状態にすること。
参照元: https://www.weblio.jp/content/%E3%83%87%E3%83%97%E3%83%AD%E3%82%A4

レイテンシー

データ転送の「遅延」のこと。
「低レイテンシー」とは、遅延が少なくデータ処理が行われることを指す。(ポジティブな意味)
CloudFrontは最寄りのエッジロケーションにあるキャッシュを使用してコンテンツを配信しているので低レイテンシーの実現ができる。

スケールメリット

規模の拡大によって得られるメリット。
AWSは数十万単位の多くのユーザーがクラウドを使用するため、スケールメリットを活かして従量課金制の料金も低く提供できる。

EC2/RDS/S3関連

インスタンス

EC2で立てるサーバーのひとつを指す。
例)インスタンスをひとつ立てる = サーバーをひとつ立てる
EC2には、さまざまな種類(スペック)のEC2インスタンスが用意されている。

データベースインスタンスは、AWSではRDSで使われるまた別のもの。
こちらも様々なタイプが用意されている。

レプリケート(レプリケーション

コピー(複製)すること。
RDSはMulti-AZ配置をするとAZ間でレプリケートされる。
S3でもレプリケート先パケットを指定すると異なるリージョンにあるパケットにレプリケートできる。
EBSはアベイラビリティゾーン内の複数のサーバーで自動的にレプリゲートされている。

リードレプリカ

更新用データベース(マスター)からレプリケーションされた参照専用のデータベースのこと。
参照元: https://www.iij.ad.jp/svcsol/category/cloud/bp/db002.html

バケット(パケット)

バケツ(入れ物)のこと。
S3ではバケットを作成して、その中にオブジェクト(ファイル)を格納する。
バケット名はユニークである必要がある。

オブジェクト

データ(アップロードするファイル)のこと。

障害/負荷関連

フォールトトレランス

障害発生時にサービス全体を止めずにシステムを動かし続けること。
参照元: https://dev.classmethod.jp/cloud/amazon-rds-replication/

フェイルオーバー

稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組み。
参照元: https://www.idcf.jp/words/failover.html

スナップショット

バックアップ。
ある時点でのソースコードや、ファイル、ディレクトリ、データベースファイルなどの状態を抜き出したもののこと。
参照元: https://www.idcf.jp/words/snapshot.html

ヘルスチェック

システムなどが正常に稼働しているかを外部の別の機器などから監視あるいは検査すること。
http://e-words.jp/w/%E3%83%98%E3%83%AB%E3%82%B9%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF.html
チェック結果:ヘルシー => ヘルスチェックが良好 => 問題は起こっていない。
チェック結果:アンヘルシー => ヘルスチェックでエラー => 何かしらの問題が起こっている。

スケーラブル

増大・拡大に適応できる能力・度合いのこと。

スケールアップ / スケールダウン

サーバーなどの性能を上げる/下げること

  • アップ => 上げる
  • ダウン => 下げる ※垂直スケーリング(性能の上下)の場合に使う

スケールアウト / スケールイン

サーバーなどの台数を増やす/減らすこと。

  • アウト => 増やす(拡大する)
  • イン => 減らす(縮小する) ※水平スケーリング(台数の増減)の場合に使う

垂直スケール / 水平スケール

垂直スケール => ひとつのサーバーなどを大きくする。
水平スケール => ひとつのサーバーなどの数を増やす。並列で使う。

設計関連

Design for Failure

故障に備えた設計。
時間が経てば故障する、ということを認識し、アーキテクチャに取り入れた考えのこと。

Single Point Of Failure(SPOF)

単一障害点。
Design for Failure を実現するために SPOF をなくすという考え方をする。
障害の原因ポイントが単数だと設計的に良くないとされていて、予め複数にリソースを割り振った設計が好ましいとされる。

可用性

システムが継続して稼働できる能力のこと。

高可用性 => システムの停止時間をなるべく少なくすること。
AWSのサービスを使った高可用性の実現には、複数のAZおよびリージョンにまたがるアーキテクチャにしたり、Auto Scalingを使用するといった方法がある。
参照元: https://qiita.com/hz1_d/items/ca24e1d131bf475e23b1

冗長化

コンピューターやシステムに何らかの障害が発生したケースに備えて、予備装置を普段から配置、運用しておくこと。
参照元: https://boxil.jp/mag/a2945/ コンピュータの世界では、冗長は無駄というようなネガティブな意味ではない。
「冗長性がある設計や構成」ということは、予め何らかの障害に対して対策している良い設計や構成というポジティブな意味。

イレブン・ナイン

99.999999999%のこと。
9が11個あるので、イレブン・ナイン。

S3の耐久性(堅牢性)はイレブン・ナイン。
S3の可用性は99.99%なので注意。

プロビジョニング

必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと。
参照元: https://www.idcf.jp/words/provisioning.html

ユーザー関連

MFA (Multi-Factor Authentication)

サインインする際に行う多要素認証のこと。
ユーザー名とパスワードに加えて保護のレイヤーを追加する。(PingもMFAのソリューションのひとつ)

フェデレーティッドユーザー

AWS上ではアカウントを保持していないAWS外部のユーザーを指す。
Auth認証(Twitterでログインするみたいな)のようなサービスの利用法をフェデレーションという。

AWS クラウドプラクティショナー 取得まで

職種や前提知識

Webのフロントエンドエンジニア。
過去に案件でAWSを用いたプロジェクトはいくつか担当しましたが、実際にコンソール上で設定を変更したりすることはほぼなく、よく使われるサービス(EC2/S3/ELB/CloudFrontあたり)がどのようなサービスであるかをなんとなく知っている程度。
VPCなどコーディング業務から遠いサービスは今回ほぼ初めて聞いた程度でネットワークやサーバーに関しての知識も基礎部分はかなりあやしいです。

認定資格テキストの読みこみ(本)

まずAWS認定資格試験テキスト「AWS認定 クラウドラクティショナー」 https://www.amazon.co.jp/dp/4797397403/ の読みこみを行いました。
認定試験の知識のなかで一番ベースとなる知識をつけることができ、試験のレベル感もこの本で把握していきました。

1週目は分からない部分がありながらも一通り読み進めて設問を解きました。
初めて聞くサービスや用語も多いので、

  • 資格取得の全体の雰囲気(設問の出され方など)を把握する
  • 聞いたことがない用語に関しては把握する
  • 聞いたことがあるサービスに関しては、概要を説明できる
  • 聞いたことがないサービスに関しては、どのようなサービスかをぼんやりと認識できる
  • AWSの責任共有モデルやセキュリティ、料金システムに関しては細かい仕組みや数字は覚えられず、基本的な考え方や方向性に関して認識できる程度の理解度までが1週目では限界でした。
    ※全部を覚えようとするとパンクしてしまうと思い途中で方向転換

レーニングプログラム AWS Cloud Practitioner Essentials(動画)

AWSが提供しているクラウドラクティショナー向けの動画カリキュラム。
現在配信されているパート2ではなくパート1?を見たような気がしますが、全7〜8時間くらいで長めです。

認定資格用に作られている動画と、初心者ユーザー向けのサービス紹介の動画の2タイプで構成されていましたので、有益度合いは人によるかなと思います。(聞いておいて損はしないですが)
機械翻訳的な日本語音声なのでちょっと聞きづらさを感じてしまいました。

各セクションの最後に設問があるので役に立ちます。難易度が高く感じました。(動画に出てないことも出てくる)
この時点で50%くらいの正答率だったので結構ヘコみました。
このあたりで勉強開始前までに聞いたことないサービスに関しても概要は理解できたと思いますが、まだまだ細かい所は覚えられていなかったと思います。
そのため、この段階でもう一度テキストを読みました。(2周目)

実際にAWSを触ってみる

実際にAWSのアカウント作成して無料枠で触ってみました。
参考にしたのは少し古いですが 0から始めるAWS入門:概要 - Qiita などをみながら進めて、VPC設定、インスタンスの立ち上げくらいまで行ってみました。(約2時間程度)

AWS Innovate 2019 AWSome Day セッション(動画)

AWS公式の初心者向けセッション動画を一通り見ました。(4動画)
https://aws.amazon.com/jp/about-aws/events/aws-innovate/sessions/#awsomeday02
こちらは厳密に資格対策用の教材ではないですが、内容はかなり初心者向けに作られています。
図を用いながら説明があるので、もしかすると認定資格テキストの前の最初の段階で見るほうがいいかもしれません。
スピーカーの方が2人いるのですが、掛け合いして進んでいくので、個人的には飽きずに楽しむことができました。

これまでの知識の復習など

  • よく使われる用語や試験範囲のサービス一覧を自分でまとめてみる
  • テキストの読みこみ 2回(3週目、4週目)
  • 認定資格テキストとトレーニングプログラムの設問を改めて一通りやってみる

模擬試験

試験の1週間くらい前に受けました。
正解90%程度。
本試験より難易度はやさしいとは分かっていたものの、だいたい正解だったので試験の日程を1週間後に設定できました。
解答と解説がないのであまり有益でないかもですが、試験形式に慣れるためにやっておいたほうがよいです。

試験結果

820点ほどで合格。

  • 20%:間違いなく正解
  • 60%:なんとなく正解かな
  • 10%:たぶん間違いかな
  • 10%:これ分かんないな

というくらいの感触でした。90分の持ち時間でだいたい30分で一通り回答、15〜20分でマークつけた問題の見直しを行いました。(40分余り)

勉強期間はGW明けくらいから初めて6月上旬の受験だったので1ヶ月ほど。
通勤時間に本読んだり、動画は週末に見たりしました。
はじめは他の勉強や課題と同時並行で進めれるかなと思っていましたが、本の読み込み1週目でこれ大変だなと思って5月中旬以降はほぼこれだけの勉強期間になってしまいました。

問題内容や難易度/対策

認定資格を取ること、が目的であれば直接コンソール触わらなくてもOKかなと思います。
初見のサービス名がいきなり出たり、知らない英語の用語が出てきたりして焦ってましたが、
70%正解なら合格にはなるので、簡単(素直)な問題などを落とさないように基礎固めておいたほうが安心できそうです。

  • EC2(インスタンスタイプなど)
  • RDS(データベース周り)
  • IAM(ユーザー権限)

に関してはそれぞれ3問ずつ以上は出たと思うので、しっかりおさえておいたほうがよいかなと感じます。
(IAMとかMFAとか5回以上設問や選択肢であった気もする)

自分みたいなレベル感の人はとりあえずサービス名や用語覚えるまでの段階が一苦労と思いますが、
そこを乗り越えたらそれぞれの特徴覚えて、問題の傾向やクセを理解するテクニック的なところになるので割と一気にいけちゃうと思いました。

Mac SourceTree で AWS CodeCommit のリポジトリをチェックアウト

前回もつまづきまくって2度目があったのでメモしておきます。
httpsリポジトリアクセス、IAMのロール周りも設定後の場合です。

公式で近いチュートリアルは下記が近そう
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-https-windows.html

Amazon CLI をインストール

ここは省略します
参考: AWS CodeCommit + Git (https) を OSX から SourceTreeで使う - Qiita

AWS CLI の設定

ターミナルから下記で AWS CLI の設定を行います。

$ aws configure --profile [プロジェクト名(自由につけて良い/あとで使う)]
AWS Access Key ID : [アクセスキーID]
AWS Secret Access Key : [シークレットアクセスキーID]
Default region name : [CodeCommitを使う?リージョン(ap-northeast-1 など)]
Default output format : [空欄(None)でOK]

認証情報ヘルパーを設定する

同じくターミナルで認証情報ヘルパーを設定します。

$ git config credential.helper "!aws codecommit credential-helper $@"
$ git config credential.UseHttpPath true

下記もひつようかな?

/user/.gitconfig ファイルに下記を追加

[credential]
    helper = "aws configure --profile [CLI設定のプロジェクト名] codecommit credential-helper "
    UseHttpPath = true

SorceTree からクローン

SorceTree で Git URL をクローンする。
URLにhttpsアドレスを入力して Git のユーザー名/パスワードを入力
※このときにパスワードしか出ない場合はほかプロジェクトのユーザー名が使われているかも

問題なければクローンできる。Git URL と判定されていなければ以上の設定で不備ありと思います。