NATゲートウェイの設定 / AWSのプライベートサブネットから、インターネットに接続する

◆ 今日やること

AWSのプライベートサブネットから、インターネットに接続する場合、NATゲートウェイが必要です。
プライベートサブネットに配置したEC2インスタンスからyum installとか実行する時に必要ですよね。

NATゲートウェイの設定がないと、インターネットに出て行けません。


$ sudo yum install -y mongodb-org
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main/latest                                                                          | 2.1 kB     00:00
amzn-updates/latest                                                                       | 2.3 kB     00:00
https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: [Errno 12] Timeout on https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/repodata/repomd.xml: (28, 'Connection timed out after 30000 milliseconds')
Trying other mirror.

failure: repodata/repomd.xml from mongodb-org-3.2: [Errno 256] No more mirrors to try.

◆ 実装編

> NATゲートウェイの作成

サブネットの選択は、Publicサブネットにしましょう

NATゲートウェイの作成.png

> ルートテーブルの設定をします

0.0.0.0/0の送信先ターゲットを上記で作成したNATテーブルに変更します。

ルートテーブル.png

> 確認

AWSのプライベートサブネットから、インターネットに接続できるようになったかと思います。
以下を実行して、インストールが完了すればOKです。


$ sudo yum install -y mongodb-org

続きを読む

AWS EC2にMongoDBインストールとレプリケーション設定

MongoDBインストールとレプリケーション設定について、簡易的な抜粋メモとして書いています。
詳細に関しては、記事の最後の参考サイトを確認するようにしてください。

◆ 今日やること

  • MongoDBをEC2にインストール
  • レプリケーションの設定と確認
    • 今回せっていするレプリケーションの形式は、以下の図の通り、「Primary with Secondary Members」です。

mongorepl.png
引用元:Replication — MongoDB Manual 3.4

◆ バージョン

  • MongoDB 3.2
  • Linux 4.4.30-32.54.amzn1.x86_64 #1 SMP Thu Nov 10 15:52:05 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

◆ 実装編

> EC2へのインストール

sudo yum update -y
sudo vim /etc/yum.repos.d/mongodb-org-3.2.repo

[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/amazon/2013.03/mongodb-org/3.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc
sudo yum install -y mongodb-org
sudo service mongod start

sudo chkconfig mongod on

> 設定周り

  • WoredTigerストレージエンジンの主な設定

    • cacheSizeGB: システムメモリの6、7割
    • blockCompressor:デフォルトはsnappy(中間です)
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
       cacheSizeGB: 1
       journalCompressor: snappy
    collectionConfig:
       blockCompressor: snappy

> EBSボリュームをAttach

  • EBSボリュームにmongoのデータを溜めるようにする。

Amazon EBS ボリュームを使用できるようにする – Amazon Elastic Compute Cloudに従って、EBSボリュームをアタッチする

  • パーミッションを変更するのを忘れないように。
sudo chown -R mongod:mongod /data
  • /etc/mongod.conf
/etc/mongod.conf
# Where and how to store data.
storage:
  dbPath: /data

> レプリケーションの設定

MongoDBではマスターのことをプライマリ,スレーブのことをセカンダリと呼びます。
MongoDBのレプリケーションの最小構成は,3つのノードが必要です。

  • ネットワークインターフェイスの設定で、レプリケーションを組むサーバのIPを記述しておくこと

レプリケーション設定前には、お互いに通信できることを確認しないといけません
Troubleshoot Replica Sets — MongoDB Manual 3.4

mongodb が listen するIPアドレスはデフォルトでは 127.0.0.1 に設定されており、ローカルからのみアクセスを許可するようになっています
mongod.conf の bind_ip に設定されたIPアドレスで listen するのでこれを変更することで外部からの接続を許可します
ここに 0.0.0.0 を設定すると全てのIPアドレスからの接続を許可します

/etc/mongod.conf
# network interfaces
net:
  port: 27017
  bindIp: [127.0.0.1,10.1.52.111,10.1.51.227,10.1.51.68]


  • レプリケーション名を決める
  • Oplogのサイジングと設定サイズを決める
/etc/mongod.conf
replication:
   oplogSizeMB: 500
   replSetName: testRepl

第4回 MongoDBのレプリケーションを構築してみよう:MongoDBでゆるふわDB体験|gihyo.jp … 技術評論社

OplogはCapped Collectionなので,作成時以外にサイズ変更することができません。 デフォルトのOplogのサイズは「1GBまたは,ディスクの空き領域の5%」
Staleを避けるために,Oplogのサイジングは非常に重要となります。
Oplogのサイズは,mongodの初回起動時にoplogSizeオプションで変更可能です。
Oplogの適切なサイズを見積もる方法のひとつに,本番を想定した書き込みテストを実施し,作成されたOplogのサイズを取得する方法があります。
1時間程度,本番想定と同程度の書き込みテストを行った後,以下のコマンドでレプリケーションの最新情報を取得します。

> db.getReplicationInfo()

1時間で作成されたOplogのサイズがわかれば,Oplogのサイジングの目安となります。
少なくとも8時間のセカンダリのダウンタイムに耐えられるようにしておくことが推奨されています。

  • レプリケーションの設定

どれかのサーバに入って、以下のコマンドを実行

config = {
  _id : "testRepl",
  members : [
    { _id : 0, host : "10.1.51.227:27017" },
    { _id : 1, host : "10.1.51.68:27017" },
    { _id : 2, host : "10.1.52.111:27017"} ] }

rs.initiate(config)
  • スレーブの読み取り専用動作設定

そのままだと、スレーブが読み取り専用としてアクセスできないので以下の設定を行っておく。

スレーブノードで、以下のコマンドを実行

 db.getMongo().setSlaveOk()
  • レプリケーションステータスの確認
testRepl:PRIMARY> rs.status();
{
    "set" : "connobaRepl",
    "date" : ISODate("2017-01-12T07:03:05.556Z"),
    "myState" : 1,
    "term" : NumberLong(6),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "members" : [
        {
            "_id" : 0,
            "name" : "10.1.51.227:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 100310,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "electionTime" : Timestamp(1484104344, 1),
            "electionDate" : ISODate("2017-01-11T03:12:24Z"),
            "configVersion" : 3,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "10.1.51.68:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 100245,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:04.017Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:04.020Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        },
        {
            "_id" : 2,
            "name" : "10.1.52.47:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 99751,
            "optime" : {
                "ts" : Timestamp(1484182286, 1),
                "t" : NumberLong(6)
            },
            "optimeDate" : ISODate("2017-01-12T00:51:26Z"),
            "lastHeartbeat" : ISODate("2017-01-12T07:03:05.025Z"),
            "lastHeartbeatRecv" : ISODate("2017-01-12T07:03:05.022Z"),
            "pingMs" : NumberLong(2),
            "syncingTo" : "10.1.51.227:27017",
            "configVersion" : 3
        }
    ],
    "ok" : 1
}

> mongoログインの時の警告メッセージを消す方法

[ec2-user@ip-10-1-52-47 ~]$ mongo
MongoDB shell version: 3.2.11
connecting to: test
Server has startup warnings:
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-01-11T03:10:18.308+0000 I CONTROL  [initandlisten]
testRepl:SECONDARY>

◆ 参考サイト

続きを読む

秒間500件以上のLOGフローアーキテクチャ

今年の9月、社内でLOGのアーキテクチャの改善を計るチームに参加する事になりました。
その際に経験させていただいた、知見をここでまとめてみようと思います。

背景

チームが作られた経緯としては、社内のLOGアーキテクチャを利用している際、問題が発生したためです。
問題発生した際の簡単なLOGアーキテクチャ図です。

AWS Design (1).png

  • backendのmongodbがLOGの流量に耐えきれず落ちた。
  • log dispatcherまで派生し、他のbackend_serviceへのLOG流入にまで影響を及ぼした。
  • 各種log dispatcherサーバの設定時、backend毎に流量の微調整を行わなくては行けないので障害発生時やサーバ構築時の対応にてインフラチームの人員コストが増大していた。

今回の目標

上記問題をふまえて、今回のLOGアーキテクチャ検討チームの目標は

  • 秒間500件以上を各backendまで流し込むアーキテクチャ

    • 流量に応じて各種サービスのスケールアウトを行えば、数倍以上の速度を実現。
  • 各backendサービス毎に影響範囲を分けたアーキテクチャ
    • 一つのbackendが落ちても他のbackendへのフローに可能な限り影響を及ぼさない。
  • インフラ側のコスト削減
    • インフラチームの人員コスト(log dispatcherサーバ構築やtd-agentへの流量調整等の煩雑な作業)を削減。

LOGアーキテクチャ案 – 1st サーバレスアーキテクチャ –

上記の問題を解決するために検討された、LOGアーキテクチャ案がこちらです。

アーキテクチャ図

AWS Design.png

アーキテクチャ概要

  • 前提条件

    • LOG 1recordの平均容量は1KB。
    • 検証対象となる秒間件数は「総秒間処理レコード数1」。
    • 検証範囲としてはkinesis〜backendサービスの間つまりlambdaが担当するフロー部分全てを範囲とする。
    • kinesisの流入性能は目標秒間件数以上の性能を満たしているため検証範囲から外す。
  • LOGについて
    • 流入されるLOGはplayerの行動ログ。
    • LOG内にはplayerのidが入っている事を前提とする。
      • また、そのplayer_idは32文字の16進数文字列とする。
  • app serverについて
    • EC2インスタンスのm4.2xlargeを1つ利用しtd-agentサーバからkinesisへLOGを流し込む。
    • 「td-agent fluent-plugin-kinesis」のKPLを利用してkinesisに流し込む。
  • kinesisについて
    • Kinesis Streamsは1シャードに秒間1000recordもしくは秒間1MBまで受け付けられる。
    • kinesis Streamsのshard数は2つで検証を行う。
      • ただ、計測結果の内容は1lambda containerでの処理内容を計測する。
  • lambdaについて
    • 使用言語はpythonを使用。
    • lambdaの使用メモリは256MB。
    • kinesis streamsよりrecordsを取得するblueprint「kinesis-process-record-python」を利用して実装。
      • kinesisのシーケンス番号を独自に管理してくれる。
      • lambda内でエラーが発生した場合シーケンス番号を進めずリトライしてくれる機能も備わっている。
      • shard数を増やすとlambdaもshard数にあわせてlambda containerをスケールして起動する。
  • フロー解説
    1. app serverのtd-agentからkinesisへLOGを流し込む。
    2. lambdaが定期的にKinesisよりrecordを取得して各backendへ流し込む。
      • S3には取得したrecordをgzで圧縮して1起動lambda毎に1ファイル書き出す。
      • Bigqueryにはplayer_id毎のtable作成しplayerのLOGを流し込む。
        • player_id毎のテーブルには検索容量を削減し料金を低減させる目的がある。
        • 弊社各アプリのplayer情報全てを1テーブルに格納して検索するとコスト面がかかりすぎてしまうため分割する。
        • Bigqueryのdate-partitionedを利用して、teble内では日付毎にpartitionされている。
        • テーブルがplayer数だけ生成されるため、GCP社様に確認を行い「問題ない」旨の返答を頂いた。
  • 撤去したbackend
    • mongoDBでは、コストに見合ったインスタンスでは流量に耐えられないため撤去。

計測結果

実行lambdaのメモリ量は全て256MBです。

backend形式 最大メモリ 総平均時間1 平均時間2 平均間隔時間3 平均レコード数4 秒間処理レコード数5 総秒間処理レコード数6 エラー発生率(%)7
Bigquery 119MB 868.86秒 72.22秒 32.79秒 38件 3.10件/秒 0.04件/秒 85.7%
S3 156MB 6.35秒 6.08秒 0.46秒 4389件 721.24件/秒 691.11件/秒 0%

達成内容

  • S3への流入について1lambda(256MB)で約秒間500件以上を達成。

問題点

  • Bigqueryへ投げるリクエストに時間がかかっている。
  • Bigqueryへのcreate_tableが正常に終了した後数分間はinsertを行っても「Not found Table」のエラーが発生。

問題点の考察

Bigqueryへ投げるリクエストに時間がかかっている。

1lambda内で複数リクエストを投げているが、その部分は直列で処理を実行しており、並列で処理を実行する事でスループットをあげられる可能性があります。

Bigqueryへのcreate_tableが正常に終了した後数分間はinsertを行っても「Not found Table」のエラーが発生。

「create tableの性能があまり良くない」 or 「table生成にラグが発生する仕様」だと思われるため、tableを無制限に作成する方式では限界があると考えられます。テーブルの作成数を最適化する方法でこの問題に対処します。

LOGアーキテクチャ案 – 2nd gevent並列処理 –

「1st案」の問題点を元に続いての案を実行してみました。

アーキテクチャ図

Untitled.png

アーキテクチャ概要

  • geventを使ってBigqueryへのリクエストを並列処理。

    • 並列処理でリクエストを投げる事でlambda containerのパフォーマンスを最大限利用。
  • テーブルの仕様を変更。
    • player_id毎のテーブルでは無く、player_idを元に16分割したテーブルへデータを流し込む。

計測結果

実行lambdaのメモリ量は全て256MBです。

backend形式 最大メモリ 総平均時間1 平均時間2 平均間隔時間3 平均レコード数4 秒間処理レコード数5 総秒間処理レコード数6 エラー発生率(%)7
Bigquery 256MB 24.63秒 20.69秒 3.23秒 4078件 197.09件/秒 165.56件/秒 3.8%

達成内容

  • 1stよりも高速化を実現。

問題点

  • 秒間500件以上は未達成。

問題点の考察

秒間500件以上は未達成。

256MBのlambdaでpythonを利用し高速化を計る場合は、これが限界だと考えられます。
ただ、lambda container上で実行出来る実行ファイルもしくは共有ライブラリを利用する事で高速化を実現出来るかもしれません。

LOGアーキテクチャ案 – 3rd Golang共有ライブラリ –

アーキテクチャ図

Untitled.png

アーキテクチャ概要

  • golangを利用してbigqueryへrequestを投げる共有ライブラリを作成し利用。

    • インタプリタ言語とは異なるコンパイル言語であるgolangで作成した共有ライブラリを利用。
    • goroutineを利用して並列処理を行う。

計測結果

実行lambdaのメモリ量は全て256MBです。

backend形式 最大メモリ 総平均時間1 平均時間2 平均間隔時間3 平均レコード数4 秒間処理レコード数5 総秒間処理レコード数6 エラー発生率(%)7
Bigquery 158MB 11.11秒 10.50秒 0.57秒 4711件 448.25件/秒 424.01件/秒 0.3%

256MBでは秒間500件に後少しの所で達成出来ませんでした。

ただ、kinesis shard数を2本から1本へ変更すると

backend形式 最大メモリ 総平均時間1 平均時間2 平均間隔時間3 平均レコード数4 秒間処理レコード数5 総秒間処理レコード数6 エラー発生率(%)7
Bigquery 146MB 7.62秒 6.86秒 0.86秒 4640件 676.11件/秒 608.63件/秒 1.3%

目標秒間件数を満たす事が出来ました。
なぜこのような事が発生するのかは、別で記事にしたいと思います。

達成結果

  • 共有ライブラリを利用する事で高速化を実現し、限定的な条件ではあるモノの目標秒間件数を達成。
  • サーバレスアーキテクチャのため、インフラチームの運用コストも削減を実現した。

あとがき

この構成に関しては下記資料を参考にさせて頂きましたが、AWS以外のbackendサービスへの流入についての記事は見当たらなかったため、検証し記事にさせて頂きました。

今回の記事関連で聞いてみたい事がありましたら、何なりとコメント頂ければわかる範囲でお答えします。それでは、この記事を最後まで読んで頂きありがとうございました。

参考資料

https://speakerdeck.com/kanny/miao-jian-shu-mo-falseroguwoiigan-zinisuruakitekutiya

注釈


  1. (lambda総時間 + error総時間 + lambda実行間隔総時間) / lambda成功処理回数 

  2. 1起動lambdaあたり処理する平均処理時間 

  3. lambdaとlambdaの間の実行間隔の平均時間 

  4. 1起動lambdaあたり処理する平均record数 

  5. 平均レコード数 / lambda平均時間 

  6. 平均レコード数 / 総平均時間 

  7. エラー終了lambda回数 / 総実行lambda回数 

続きを読む

サーバーレスアーキテクチャってなんだっけ

読者の対象イメージ

・さくらVPSを契約してLAMP環境とかを作ってCMSとか作れる感じの人
・AWS EC2の無料枠で簡単なHPを公開しているよ
・スマホアプリから呼ぶAPIプログラムなら作ったことあるよ!
・上記のことは全然わからないけど、なんとなく今から始めるなら最新の技術で安いWebアプリ開発がしたい人

サーバレスアーキテクチャってなに?

サーバレスな、アーキテクチャ
「サーバーのないインフラ」
・サーバーの管理、運用が必要のない仕組み

サーバーが必要ないってどういうこと?

・クラウドプラットフォームが、必要なときだけサーバーインスタンスを貸してくれるイメージ
(1日に100アクセスしか無いのに、サーバーとか固定IPを持っておくのって無駄が多くない?ってこと)

 1. HTMLファイルとかの静的ファイルはS3とかのクラウドストレージに配置しましょう。
 2. 独自ドメインやキャッシュはCloudFrontみたいなキャッシュサービスを通じてやりましょう
 3. メールフォームとか動的なページはAPI化して

なんでそんなことするの?

サーバーのセットアップ面倒くさいな

・Linuxって色んなOSあるんでしょ。何選べばいいの。ぼくずっとCentOSとかだったけど、え、アマゾンはAmazon Linux???
・EC2インスタンスを借りたらまず、gitとapacheとphpとmysqlをインストール。でもphp5.6使いたいからその前にnpmリポジトリを更新して・・・あれ?
・あれ、apacheのSSLの設定ってしたっけ・・・
・いつのまにかサーバー再起動してるじゃん。しかもmysql自動起動になってなかった・・・orz

攻撃怖いじゃん

・インターネットにHPやサービスを公開すると、色んなイタズラを受ける
・1秒に100回SSHに接続してきたり・・・
・メールフォームにJavaScript埋め込まれてサーバーの中のファイルを見られたり・・・
・大量にWordpressにCLIログインしようとしてきてDBがサチったり・・・

そんな常にサーバーインスタンス必要ないんだけど・・・

・1日に100アクセスのサービスとか、別に普通にあるし
・開発のために別のインスタンス作ったけど、無料枠じゃないから月2000円とられちゃったり

大量のアクセスに備えたいよね

・サーバー代ケチったら、せっかくTwitterでバズってサービスが大盛り上がりになると思った時にサーバーが落ちちゃうとか、悲しい

ロードバランサ組んだりするほど大掛かりなことする技術力ないです

・確かにロードバランサを組んで大量のサーバーに負荷分散すればいい
・しかも負荷に応じて自動的にサーバーの数を上限できるように設定しておけば安心!
・でも、インフラ専門の技術者じゃない人いるでしょ。サーバーの運用のことばっかしてられないよ
・正直、勉強することが多くて無理・・・。

そんな、インフラ専門のエンジニアではない人でも簡単に運用したい!

・herokuみたいに、インフラのことを気にしないでビジネスロジックだけ書いてアプリリリースしたいよねって需要に最適!

どうすれば使えるの?

・Microsoft Azure Functionsとか、Google Cloud Functionsとかある。
・ぼくが使っているのはAmazon AWSを使った構成。

メリット、デメリットまとめ

メリット

・サーバーの運用が不要(用意やOS・ソフトのインストール、デプロイなどがいらない)
・料金がたいてい安くなる(AWSは大体が従量課金、EC2を24時間365日起動しておくより基本安くなるはず)
・セキュリティに疎くてもある程度安全(攻撃対象となるサーバーが「無いに等しい状態」なので、安心)
・可用性高い(可用性って、ぼくも最近はじめて聞いた言葉だけど。要は落ちないってことかな。あと大量のアクセスも安心!)

デメリット

・サーバーで常時プログラムが動いている前提のシステムは構築しづらい(ネットゲームのサーバーとか向かない)
・新しいんで仕様がどんどん変わる可能性もある
・Lambdaで使える言語が限られている。(Java, NodejS, Python。やろうと思えばBashからPHP使えるけど)
・良くも悪くもサーバーがない。例えば、IPが固定されないので、IP WhiteListを設定するなら、別途VPCつかったりNATゲートウェイ使ったりする必要がある(チャレンジして挫折したので今月もう一度試してみる)
・サーバーがないってことは、あれ、ログファイルとかってどうなるの。(CloudWatchに一時的に保存される。あとは自分でなんとかする必要あり)

サーバーレスアーキテクチャの例

・前提として、LAMP環境でメールフォーム付きのホームページを持っていたとします。
・これをどうやってサーバーレスアーキテクチャに載せ替えたらいいでしょうか。

LAMPとの対応例

やること LAMP環境 AWS サーバレスアーキテクチャ
静的ファイルの公開(html, css, jsファイル, img) Apache S3
静的ファイルのキャッシュ CloudFront
独自ドメインの使用 Apache VirtualHostなど CloudFront
メールフォーム送信php phpスクリプト API GatewayでAPI化してAWS Lambdaを起動
問い合わせ内容をDBに保存 MySQL(PostgreSQL、MongoDBなど) AWS DynamoDB

静的ファイルはAWS S3でホスティング

・DropBoxやGoogleDriveほど使い勝手がいいわけではありませんが、そのどちらもで最近できなくなった静的ファイルのホスティングがAWS S3サービスでできます。
・フォルダごとアップロードして、共有権限を全員閲覧にすれば、Amazonのドメインで公開が可能!

静的ファイルの独自ドメインでのアクセス、キャッシュはCloudFront

・実はまだ使ったことがないんですが・・・・
・理論上は、CloudFrontで独自ドメインとS3のファイルを紐付けられるそうです
・しかもキャッシュも設定できるらしい!(まだイマイチ嬉しいポイントが分かってないですが)

メールフォームなど、プログラムが必要な部分はLambda。

・サーバーレスアーキテクチャのキモ。詳しくは後日説明。
・ここでは、phpみたいなGETやPOSTリクエストに対して起動するプログラムファイル専用のS3みたいなものと考えてOK。
・その他にも、cronの代わり(毎日朝6時に実行する)とか、DynamoDBのデータが変更されたら(MongoDBのフックみたいな)タイミングでプログラムを実行することが可能です。
・Lambdaは直接は起動できないので、API GatewayでURLに対するGETやPOSTに紐付ける必要がある。

データベースはDynamoDB

・DynamoDBはNoSQL。
・使ったこと無いけどイメージ的にはMySQLよりMongoDBの方が近いみたい?
・凄いざっくりいうと、凄い大きなHash。データベースからキーでデータを取り出す。
・一回の読み込みのサイズが1MBに制限されていたり(それ以降はページングが必要)、ちょっと面倒。
・各言語に用意されたAWS SDKってライブラリを使ってアクセスしてね!
・ちなみに基本ハッシュなので、問い合わせ情報の蓄積にはあまり向いていない・・・。

まとめ・サーバーレスアーキテクチャってなに?

今までの流れ(Webサーバーとか)
「サーバーはオフィスにおいてあります」
「サーバーはサーバールームに移動しました」
「サーバーは専用のデータセンターに移動しました」
「サーバーは専門業者のデータセンターのものを借りることにしました」(さくらマネージドサーバー的な)(ここまでが物理サーバー時代)
「サーバーは専門業者のデータセンターのものを別の人とシェアして使うこといしました」(さくらマネージドサーバー的な)
「サーバーは何処かにあるサーバーの一部分を仮想的に1台のサーバーとして借りることにしました」(Amazon EC2、さくらのVPS)
「サーバーは色んな所にあるサーバーをその時必要そうな台数分用意しておいて負荷分散しながら使うことにしました」(ロードバランサー使うよ)

「サーバー?ないよ?頼んだことは皆Amazonが持ってるどっかのサーバーが代わりにやっておいてくれるから(適当)」(サーバレスアーキテクチャ)

って感じです。

明日以降

仕事の合間で、サーバレスアーキテクチャの使い方とか、詳しい仕様とか、できることとかを書いていこうと思います。

続きを読む