AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - 2015年7月

基幹・業務システム用途のAWS導入事例を集めてみました!

2015.07.24

~今回のテーマは、基幹・業務システム用途のAWS導入に関する事例です。
以下に比較してみます。



























 比較項目
 株式会社リコー 様
 AWS選定理由
 『事例が多い、各種認証が豊富、グループ内で実績が多い』
 多くのエンタープライズ企業が利用していること、
 米国政府系機関から要求される各種認証が競合他社より数多く取得されていたこと、
 同社が顧客向けに提供するクラウドサービスや社内のシステムの両方で
 既に多く利用実績があったこと。
 導入効果
 『運用コストが約1/3、ハードウェアを持つという制約から解放』
 以前のシステムと比べ大幅なコスト削減につながっている。
 必要最小限のサイジングから開始し、迅速な拡張・最適化が可能になった。
 また調達面でも大幅な納期短縮が可能となった。
 利用している主な
 AWSの機能
 Amazon VPC、Amazon EC2
 AWS事例ページ




























 比較項目
 HOYA株式会社 様
 導入理由
 『クラウドが持つバリューをちゃんと提供できているか』
 実際の検討項目は、必要なシステムのスペック、オンデマンドセルフサービス、
 伸縮性、監査情報の有無、サービス、セキュリティ、事業継続、及び災害対策、
 コストなどの幅広い範囲について確認を行った。
 導入効果
 『ビジネス要件に合わせて、ITインフラを柔軟かつ迅速に調達』
 今回のAWSの採用により、今後M&Aなどにより、リソース調達などが発生した場合でも
 迅速な対応が可能になると考えている。
 また、コスト面でも初期投資で約50~60%の削減。
 3年間のコスト比較を行った結果でも、コスト削減できることが分かっている。
 利用している主な
 AWSの機能
 Amazon Direct Connect、Amazon VPC、Amazon EC2、
 Amazon S3、Amazon EBS、Amazon AMI
 AWS事例ページ




























 比較項目
 西鉄ストア株式会社 様
 導入理由
 『可用性と代替性、セキュリティ方針』
 セキュリティやコンプラインスの面から社内で議論になったが、
 可用性と代替性の面からクラウド以外の選択肢はなかった。
 セキュリティについては、AWSや協力ベンダーから提供されて
 セキュリティ方針を社内で理解してもらった。
 導入効果
 『サーバ購入コストの削減とハードウェア障害からの開放』
 ハードウェアの入れ替えがなくなり、サーバー購入のコストが削減された。
 さらにハードウェアの故障等の問題からは解放され、
 ハードウェアの原因調査をしなくても良くなった。
 結果的にコストパフォーマンスをほぼ倍にすることができた。
 利用している主な
 AWSの機能
 Amazon EC2、Amazon S3
 AWS事例ページ

http://www.infilic.co.jp/

プロセス監視によりAWS Auto-healingをかかる仕組みを作ってみました

2015.07.22

AWSサーバ障害復旧の対策の一つとしてはAWSのAutoscalingGroup設定ですが、サーバ上プロセスの死活を感知することはできません。

一つの例としては、AWS EC2にWordpress等Webアプリを立ち上がって、データベース(Mysql)も同じサーバに立ち上がる場合、サーバ障害発生時、AWSのAutohealingでサーバの障害を検知して数分間で元サーバを殺して、新しいサーバを立ち上がってデータをリストアして短い間に復旧ができます。しかし、データベースがメモリ不足等の原因でプロセスを落ちたら、サーバ自体は問題ないので障害を検知されずにWebページも見れなくなってしまします。人を知らず夜間で問題が発生すればWebページの実際障害時間が数時間になる可能性もありますのでこの場合Auto-healingの仕組みのみで足りないです。

mysqlプロセスを監視する為、サーバに監視スクリプトをcronに設定すれば一番シンプルの方法だと思います。一応mysqlプロセス障害時もAutohealingをかかる仕組みで下記のようなスクリプトを作ってみました。
#!/bin/bash
# -----------------------------------------------------------------------------
# mysqld 死活監視
# -----------------------------------------------------------------------------

### アカウントや認証情報を外部ファイルから読み込み ###
....

# -----------------------------------------------------------------------------
# 変数定義
# -----------------------------------------------------------------------------
L_FILE_NAME='/usr/local/bin/script/mysqld_err.count'(失敗検知回数を外部ファイルに保存する)
L_STOPPING_COND=3(3回続いて失敗を検知されたらAutoHealingする)
L_RC=`mysqladmin ping -u $USER -p$PASS 2> /dev/null`(mysqladmin pingでプロセス死活監視)
L_NORMAL_RES="mysqld is alive" (mysqladmin ping 正常の結果)
L_TOPIC_ARN=arn:aws:sns:ap-northeast-1:YOUR_AWS_ACCOUNT:YOUR_SNS_TOPIC (SNS通知設定)
L_SUBJECT="【Monitoring System】Server DB Failure"
L_MSG="DBエラーが検知されました。サーバを停止します。"

###mysqldの状態を確認、失敗する場合カウントアップする
if [ "${L_RC}" = "${L_NORMAL_RES}" ]; then
COUNT=0
else
COUNT=`(cat ${L_FILE_NAME})`
COUNT=`expr $COUNT + 1`
fi
echo ${COUNT} > ${L_FILE_NAME}

###失敗回数一定になれば、バックアップ出来る為一時的mysqldを起動して、エラー情報をメール>して、サーバを停止する
if [ $((COUNT)) -ge $((L_STOPPING_COND)) ]; then
/sbin/service mysqld start (DBバックアップ出来るように一時的にmysqldを再起動する)
aws sns publish --topic-arn ${L_TOPIC_ARN} --subject "${L_SUBJECT}" \
--message "${L_MSG}"
/sbin/shutdown -h now
fi

そして、cronに一分間隔で設定すれば、
* * * * * /usr/local/bin/script/mysqlmonitoring.sh > /dev/null 2>&1

プロセス監視によりAWS Auto-healingをかかる仕組みは出来ました。

 

バックアップ、災害対策に関するAWS導入事例

2015.07.15

~今回のテーマは、バックアップ、災害対策に関する事例です。
以下に比較してみます。



























 比較項目
 ディップ株式会社 様
 AWS選定理由
 『災害対策を安全かつリーズナブルに実現できること』
 保有するデータ量と導入のし易さ、スピード、そして最も重要視したのがコスト。
 複数社を比較・検討したが、特にストレージ面のコストが
 性能要求に対して安価であった。
 また、Amazon VPCにより、災害対策を安全かつリーズナブルに実現できる点も大きく、
 AWSシンガポールリージョンに決定。
 導入効果
 『コストを抑えつつ、ロケーションバックアップとDRサイトを構築』
 DRサイトを構築して、クライアントやユーザなど対外的に
 DR対策はしっかりできており、万一の際もサービスは継続できると
 明確に説明できる点は大きなメリットとなった。
 オンプレミスとのコスト比較を行った結果、
 AWSであれば約3分の1程度のコストで実現できた。
 利用している主な
 AWSの機能
 Amazon Route53、Amazon VPC、Amazon EC2、Amazon EBS
 AWS事例ページ




























 比較項目
 株式会社ファンコミュニケーションズ 様
 導入理由
 『コストや可用性、データセンターとの親和性を重視』
 オンプレミス環境のでは、日々急増するトラフィックや蓄積される
 ビッグデータに対応するためのハードウェア初期投資や準備期間に
 限界を感じ始めていた。
 そんな折、自社データセンターとAWS間に専用線接続が可能になったことが
 クラウド導入のきっかけとなった。
 導入効果
 『ハードウェアや人件費の初期投資が大幅に削減』
 運用コストを削減できることが分かったほか、
 バックアップの例では運用コストは1/5~1/10程度にまで削減。
 セキュリティ面では、AWS Direct ConnectとAmazon VPCの利用によりセキュリティを
 保ちつつプライベート領域の拡張性が向上している。
 利用している主な
 AWSの機能
 Amazon Direct Connect、Amazon VPC、Amazon EC2、Amazon S3、
 AWS Storage Gateway、Amazon Glacier、CloudWatch
 AWS事例ページ




























 比較項目
 京セラドキュメントソリューションズジャパン株式会社 様
 導入理由
 『信頼性、導入実績、国内センターと価格面』
 上記に加え、特に信頼性においては数値的 なSLAが明確で、
 また、Amazon EC2が仮に故障しても日次でAmazon S3にバックアップしているために
 安心して運用できると考え採用を決定。
 導入効果
 『サービス拡張にあたり、サーバ台数変更を短時間で実現』
 サービスの都合上、スケールアウト/インを短期間で実施する必要があるが、
 サーバ台数変更をわずか2時間で対応することができ、運用負荷の低減に
 つながっている。
 Elastic Load Balancingを利用しているため、現在手動対応しているサーバー台数増減を
 Auto Scalingを使った柔軟な対応にすることを検討中。
 利用している主な
 AWSの機能
 Elastic Load Balancing、Amazon EC2、Amazon VPC、Amazon S3
 AWS事例ページ

http://www.infilic.co.jp/