2019年11月
S M T W T F S
« Oct   Dec »
 12
3456789
10111213141516
17181920212223
24252627282930

このブログ内を検索

アーカイブ

ATOM RSS2.0

2019年11月

2019.11.22

01 仕事

大阪BBQ~秋の陣~、、開催!!

こんにちは!新人のNです!
大阪も少しづつ寒くなってきましたね。
布団からでるのがとてもつらくなってきました。。

さて、そんな寒さもお肉をたべて吹き飛ばそうと、
大阪BBQ~秋の陣~が開催されました!!

BBQ_集合写真

雲一つない快晴!🌞
BBQにもってこいの天気でした~!

今回はお肉やコーンなどももちろん、マグロのカマ焼きやハマグリなど、
魚介系も満載でとてもおいしいBBQでした!(^^)!
お菓子などの差し入れも沢山いただき誠にありがとうございました!

(沖縄出身の私からするとこの日も肌寒く、コンロの火から離れられませんでした(笑))

今年も残りわずか!まだまだ気温の移り変わりが激しいので体調に気を付けて、
いい思い出つくって締めくくりましょう~!!

2019.11.17

13 自己啓発・勉強

AWS認定資格を取ってみる~対策編-データベースのエトセトラ~

巷ではもうインフルエンザが流行り始めてますが、皆さん体調管理は万全ですか?
ということで、今回はデータベースの様々な特徴について解説したいと思います。
概念的なお話となりますが、サービス運用に関わる重要なポイントなので、しっかり理解してくださいね!
まずは皆さん、「可用性」という言葉は聞いたことありますか?
Wikipediaによると、システムが継続して稼働できる能力。
例えば皆さん、お買い物はネットで決済、なんて当たり前ですよね。
夜中だろうが休日だろうが、いつでもお買い物ができる。そして、デパートのように台風が来たら店が開かない、なんてこともありません。
そう、いつ何時でもサービスが使えることを「可用性」と言います。
そしてAWSのサービスでは、この可用性を担保する様々なオプションが用意されています。

まず前回構築したRDS。RDSは以下のように二つのアベイラビリティゾーンにDBが用意されます。

それぞれプライマリ、スタンバイDBが作成され、通常は更新も参照もプライマリDBがアクセスされます。
そして更新は即座にスタンバイにも反映されるようになっています。
そのため、プライマリDBに障害があっても、スタンバイDBに切り替わり、何事もなかったようにサービスが継続されるのです。
ではもう一つの要素、パフォーマンスについてはどうでしょうか。
デパートではお客さんが沢山来ると、レジで待ち時間が発生します。
レジで並んでいると、目の前の客が商品について文句を言い始めます。それはサービスカウンターでやってよ、って思いますよね・・・
RDSも、基本的にはデータの更新より、参照されるほうが圧倒的に多いです。

そのため、読み取り専用のDB(リードレプリカ)を用意することで、沢山の読み取りでも素早く応答を返すことができます。
データの更新は、プライマリからリードレプリカに伝播します。しかし伝播は非同期に行われ、タイムラグがあるため、参照したデータが必ずしも最新ではない可能性があることに注意が必要です。

さて今回初登場のNoSQLであるDynamoDBはどうでしょうか。

DynamoDBは三つのアベイラビリティゾーンで構成され、更新は同時に二つのDBに行われ、三つ目は非同期に伝播されます。
そのため、RDS同様、タイミングによって読み込んだデータが最新ではない可能性があります。

これを「結果整合性」と呼びます。
DynamoDBでは、常に更新されたデータを読み取れるよう、更新が全てのDBに行われているかを確認してから結果を返すオプションがあります。これを「強力な整合性」と呼びます。但し当然ながらパフォーマンス低下が発生します。
ここで重要なのは、業務要件が何を最も重視しているか、ということです。
パフォーマンスがいいに越したことはないですが、「いつでも最新のデータを返す必要がある」要件であれば、強力な整合性を選ぶ必要がある、ということです。

ちなみにこの整合性は、ストレージサービスのS3にもあてはまります。

S3もバケットは複数のアベイラビリティゾーンに複製され、結果整合性モデルとなっています。

そして最後に紹介するのは「Redshift」。
Redshiftは、大量のデータを分析するためのデータウェアハウスです。
データを単純に溜めるだけのデータベースとは毛色が異なりますが、こちらも必ず回答の選択肢で見かけるサービスです。
大容量のデータを複雑なSQLで分析する必要があるときは、迷わずRedshiftを選びましょう。
逆に、継続的な書き込みや更新には向かないので、そのような要件ならRDSとなります。

このように、何を実現したいか、何を重視するかでどんなデータベースサービスを選ぶかを問われる問題が多いので、各サービスとオプションの特徴をしっかりおさえて下さいね。

さてこのAWS認定資格を取ってみる企画も、残すところ二回となりました。
次回はこれまた重要なオプションのAuto Scalingと、出題数は少ないものの頻出であるサービスについて解説したいと思います。
そして最終回は模擬試験など、受験に向けての対策をご紹介しますので、お楽しみに!

2019.11.09

13 自己啓発・勉強

AWS認定資格を取ってみる~対策編-データベース-RDS~

すっかり朝晩冷え込む季節になりましたが、風邪等引かず勉強頑張ってますか?
今回からデータベース(DB)のお話をしたいと思います。
DBも、有名なOracleやMySQLなどのRDSから、NoSQL型のDynamoDB、そしてDBに分類するか微妙ですが、データウェアハウス系のRedshift等、色んなサービスが用意されています。
AWSのデータベース
とあるデータ処理のサービスを実現するのに最適なDBはどれが、的な問題が多く出題されます。
サイズの上限であったり、どんな処理をしたいか。コストは。などなど、要件に最適なサービスを見極めるため、違いをしっかり覚えましょう!
ということで、今回はまずRDSについて。何はともあれまずはDBを作ってみます。
AWSのコンソールからRDSを選択し、「データベースの作成」を押下します。

今回はお試しで、オープンソースDBのMySQLを選択します。

世の中で動いているDBは、24時間365日稼働し続ける必要があるため、可用性が重要になります。
当然、設定が大変なのですが、AWSではそれをテンプレートとして提供してくれます。
当然お金もかかりますので、お試しとして無料利用枠を選択します。

DBインスタンス識別子は、AWS上の管理名です。データベース名ではありません。
ユーザー名、パスワードは接続に必要なので覚えておいてください。

通常は、DBはVPC内のEC2などから接続され、外部から直接接続する必要はないため、インターネットからアクセスできないようになっています。
今回はテストとして、作ったDBにPCからインターネット経由で直接アクセスします。
そのため、追加の接続設定で、パブリックアクセス可能を有効にします。

さらに、追加設定で「最初のデータベース名」に、作成するデータベース名を入力します。
注釈にあるように、データベース名を入力しないとDBはインスタンスが作成されるだけで、DBそのものは作成されません。

これでDBを作成する準備が整いました。DBが作成されるまで数分、とありますが、10分ほどかかるので気長に待ちましょう。

DBが作成されたら、PCからの接続に必要となるエンドポイントとポートを控えておきましょう。
エンドポイントは、DBのアドレスです。ブラウザでネットサーフィンする際のURLと同じですね。
ポートはMySQLのデフォルト値です。

デフォルトのセキュリティ設定では、どこから誰でも接続できるようになってます。
とりあえずこのまま進めます。

早速DBに接続してみましょう。今回は接続のため、フリーのA5MK2というSQLツールを使いました。
ホスト名にエンドポイント、ユーザーID・パスワード・データベースにDB名を入力します。
テスト接続を押し、OKとなれば準備OKです!

無事DBに接続できたら、テーブルを作ったりいろいろ試してみてください。

さて、現状はインターネット経由でこのVPCにいつでも誰でもアクセスできてしまいますので、自分のPCから、MySQLへの接続のみ許可するようセキュリティを設定してみましょう。
※セキュリティ設定も試験に出るので、よく理解してくださいね
まず先ほどのセキュリティ設定画面にて、セキュリティグループを選択します。

インバウンドを選択します。これが、インターネットからこのVPCにアクセスする際の、セキュリティのルールです。
デフォルトは、すべてのトラフィック(どんなポート向けでも)が、すべてのアドレスから接続できるようになっています。

まず、あたなのPCのIPアドレスを調べてみましょう。一般的にはWi-fi等を使っていると思いますので、グローバルIPを調べます。
「IPアドレス調査」などで検索すると、グローバルIPを調べるサイトが出てくるので、アクセスするとあなたのIPアドレスが分かります。

編集を押します。
デフォルトの設定は×ボタンで削除します。
ルールの追加を押します。タイプはMYSQL/Aurorを選択すると、MySQL用のポートが自動で設定されます。
続いてソース、ここが接続元のIPアドレスになります。先ほど調べたアドレスに/32をつけて入力します。
IPアドレスはサブネットマスクで範囲指定しますが、/32とすることで特定のアドレスのみを意味します。

設定を保存し、再度SQLツールで接続できるか確認してください。
また、試しに先ほどのルールでアドレスを適当に変えると、接続できなくなることも確認してみてください。
このように、サービスとセキュリティを組み合わせた問題も頻出ですので、セットで覚えるといいですね!

さて今回も長くなってしまいました・・・次回もまだデータベースが続きますので、頑張りましょう!

2019.11.04

13 自己啓発・勉強

AWS認定資格を取ってみる~対策編-ストレージ-S3~

前回からもう一週間が経ってしまいました。時が経つのは早いものですね。
さて今回も引き続き、ストレージサービスです。
SAアソシエイトで必ず出題される、しかも出題数の多いS3についてです。
S3とは、SimpleStorageServiceの略で、バックアップデータや写真、動画など、様々なデータを様々なプラットフォームから利用できるストレージサービスとなります。
とはいっても言葉じゃわかりませんよね^^; 5Gまでは無料なので、とにかく使ってみましょう。
S3では、データをオブジェクトと呼びます。普段使い慣れたフォルダのような概念はなく、バケット(バケツ)を用意し、そこにオブジェクトがフラットに格納されます。
よって、まずバケットを作成しましょう。

バケットにはユニークな名前を付けます。

オブジェクトをバージョン管理することで、誤って変更しても戻すことが可能となります。ここはテストに出るかも。
今回はお試しなので、そのまま次へ進んでください。

デフォルトではインターネット越しにオブジェクトにアクセスできません。S3では、オブジェクトへのアクセスを詳細に設定できますが、今回はお試し目的なので「パブリックアクセスをすべてブロック」のチェックを外します。

これでバケットが作成されます。

このバケットにオブジェクトを追加します。せっかくなので、S3の特徴でもある「静的ウェブサイトホスティング」を試してみましょう。

ホームページなどのウェブサイトを作るには、LinuxにApacheなどのWEBサーバを立ち上げ、ややこしい設定をして・・・と敷居が高かったのですが、S3にコンテンツを載せるだけで、ウェブサイトが超簡単に公開できます。
サーバーサイドスクリプトは使えませんが、javaScriptなどクライアントサイドスクリプトは使えますので、静的といいながら高度なサイトが作れます。
今回はお試しなので、「ハローワールド!」と表示されるサイトを作ってみましょう。
以下のようなhtmlファイルをテキストエディタで作成し、assets/img/フォルダと、適当な画像ファイルを用意してください。

用意できたら早速アップロードしていきましょう。

アップロードはフォルダまるごとドラッグアンドドロップできます。

次へを押し、アクセスの設定をします。

パブリックアクセス許可の管理で、読み取りアクセス権限を付与します。

これでインターネット越しに参照が可能となります。

このオブジェクトをウェブサイトとして使うための設定は、バケットのプロパティから「Static website hosting」を選択して行います。

インデックスドキュメントに、先ほど保存したhtmlのファイル名を指定します。
エンドポイントに表示されているURLが、このサイトへのURLとなります。このURLにアクセスすると、インデックスドキュメントが表示されます。

ブラウザにエンドポイントのURLを張り付けると、この通り!

実際にウェブサービスとして提供するには、DNSやキャッシュ、バランシングなどを組み合わせてやります。
ちなみにARKが提供する介護システムの「あゆむ」のウェブ画面もこの構成を使っています。

また応用として、クライアントからのデータを加工してS3にアップロードすることもできます。
データ加工をJavaのアプリケーションでやろうとすると、先ほどの例のようにLinuxにウェブサーバを立ち上げ、tomcatをインストールしてアプリケーションを配置する、なんて面倒な手順が必要で、しかもウェブサーバをずっと動かし続ける必要があります。
でもアップロードは一日一回、なんてときに24時間365日サーバを動かしつづけると、リソースが無駄ですよね。
そんなときこそAWSの本領発揮です。
Lambdaというイベント駆動型のスクリプト実行サービスを使い、データを加工してS3に格納することができます。
イベントはAPI Gatewayを使い、HTTPで受け取ります。
このように、サーバーレスなサービスが簡単に作れてしまうのです。
ちなみに「あゆむ」も、アプリからのバイタルサインをLambdaを使ってDBに格納しています。

ということで、もう大分長くなってしまったのでそろそろ終わりますが、最後にもう一つだけ!
S3にも種類がありまして、どんなにばかでかいデータも保存できるのですが、データ量に比例してお金がかかります。
そのため、たまにしか使わないデータはお安く格納できる種類があります。
・低頻度アクセス
アクセス頻度が低いデータ向けですが、使いたいときにすぐ使えます。
標準タイプでは複数のアベイラビリティゾーンに保存されるので可用性が高いのですが、このタイプは単一のゾーン保存となるため、可用性が下がります。でもその分お安いです。
・S3 Glacier
アーカイブのように滅多に使わないデータ向けです。特徴は「使いたいときにすぐ使えない」。使うには手続きが必要で、数時間かかることも。Glacierには「迅速取り出し」というオプションもありますが、それでも「すぐには使えない」。
「すぐ使いたい」ときにはGlacierは使えない、ここだけでも覚えておけば、良いことあるかも!?

開始から早一か月半、そろそろ折り返し地点が見えてきましたよ。
次回はデータベースを予定してますので、もうひと頑張りしましょう!

このページの先頭へ