IBMのソリューションやソフトウェアに対し、そのテクニカルコミュニティーにおいて高度な貢献をしたエンジニアを表彰する制度「IBM Champions」。2008年に創設され、2018年までにグローバルで計650名、うち日本人は計51名が選出されている。では彼らが見ている“テクノロジー最先端の風景”とはどのようなものなのか?――編集部では、2018年にIBM Championsに選ばれた三人に記事執筆を依頼。「言葉」ではなく、具体的な「知見・ノウハウ」を通じてメッセージを発信してもらった。ぜひ実際に頭と手を使って、彼らの視点を体感してみてはいかがだろう。
DX(デジタルトランスフォーメーション)トレンドが進展し、ビジネスが「ITを使った体験価値の競争」に変容して久しい。テクノロジーはビジネスのコアとなり、それを使いこなすエンジニアこそが、ビジネスの推進役となる時代が到来したといえるだろう。
そうした中、IBMが主催しているのが「IBM Champions」だ。IBMのソリューションやソフトウェアに対し、年間を通してテクニカルコミュニティーに優れた貢献をしたエンジニアを表彰する制度で2008年に創設。「IBM Analytics Champions」「IBM Cloud Champions」「IBM Collaboration&Talent Champions」「IBM Power Systems Champions」「IBM Storage Champions」「IBM Z Champions」の6部門で表彰される。2018年までにグローバルで650名、うち日本人は51名が選出。開発者、ビジネスリーダー、経営層など、全世界のITに携わる人に向けたインフルエンサーとして認定され、IBMのグローバルイベント、公式ホームページ、ブログなどを通じた意見発信の機会が与えられる。
今回は2018年の受賞者のうち、クラウド部門で選出された3人の日本人IBM Championsに、その知見・ノウハウを体感できる記事を執筆いただいた。ぜひ実際に手を動かして“最先端の視点”を体感してはいかがだろう。第3回はPumpkin Heads代表取締役 境川章一郎氏。ショートインタビューとともに“境川氏の思い”をお届けする。
Pumpkin Heads株式会社 代表取締役 ITコンサルタント
インフラエンジニア、アプリ開発エンジニアとしての技術力を軸に、ITコンサルティング、システム開発、Web制作・運用など幅広く手掛ける。「お客さまの要望に応じて、常に最善と考えられるソリューションを提供すること」に注力。2005年創業。
―― 最近の業務内容は?
プライム案件、SIerからの受託案件、ともにITコンサルティングをはじめ、情報システム/アプリケーションの開発・保守、Web制作・運用などを請け負っています。Pumpkin Headsの設立以前はフリーランスとして、金融系のインフラ開発、中堅・中小企業の社内インフラ開発、特定プロジェクトにおける開発チームと運用チームの橋渡し役を担うなど、さまざまな業務を手掛けていました。その経験を基に会社を設立し、2019年で14期目になります。
―― IBM Cloudの魅力は?
IBM Watsonをはじめ、魅力的なサービスが多数そろっていることだと思います。企業のITインフラにハイブリッド化が求められている中で、クラウド移行の課題を解決するさまざまな強みを持っていると思います。弊社においても一つの選択肢として「IBM Cloud」を積極的に採用・提案を継続していこうと考えています。
―― 今、注目している技術は?
コンテナ技術です。近年はビジネスニーズの変化に応じて、「必要な機能をいかにスピーディーに開発・改善するか」が重視されています。これを受けて、アプリケーション/サービスが軽量化、マイクロサービス化されていく中で、インフラ側もコンテナやコンテナ管理、サーバレスなどが重視されるようになっています。ここまで仮想化が当たり前になった今、「開発者の要請に応じて仮想マシンを立てる」といった定型作業の価値はすでに飽和しています。インフラエンジニアは、アプリケーション開発・運用により貢献できる活動を目指すべきだと考えています。
―― 執筆記事について、一言メッセージを
「もっとスケーラブルなWordPress実装をKubernetesクラスター上にデプロイする」という記事です。実は「IBM Developer」にも「スケーラブルなWordPress実装をKubernetesクラスター上にデプロイする」という、ほぼ同タイトルの記事が寄稿されているのですが、こちらは「Ingress」というKubernetesで提供される内部ロードバランサや、Kubernetesのオーケストレーション技術の一つでCPU負荷などに応じてポッドを増減させる「Horizonal Pod Autoscaler」などを使って、「もっとスケーラブルにする」方法を説いています。高負荷のトランザクションにも耐えられる、より商用に近いWordPress環境を作れると思いますので、「IBM Developer」の記事と併せて、ぜひご参考にしてください。
※この記事は日本アイ・ビー・エムから提供されたコンテンツを許諾を得て転載したものです。
こんにちは。IBM Championの境川章一郎です。
今回はWordPressをより本番環境に近づけて大量の負荷を想定した、スケーラブルなWordPress環境を作ってみます。
実は上記記事は「IBM Developer」の「Code Patterns」に寄稿されているもので、多くのサイトで利用されているWebサイト管理/ブログ・システムの「WordPress」を「IBM Cloud Kubernetes Service」へデプロイすることで、負荷に合わせたスケーラブルな構成を想定したWordPress環境の構築を行おうという記事になります。ここではこれを基に、より本番環境を見据えた「もっと」スケーラブルなWordPress実装について、ご紹介したいと思います。
Code Patternsの記事では、データベースをKubernetes内にDB用コンテナを立ち上げて実行し、ファイルをローカルストレージやNFSストレージを利用する方法を紹介しています。有料クラスタを利用して本格的にサービスを一般公開することを念頭にPatternを拡張していきます。
Code Patternとの違い・変更箇所の一覧
項目 | 変更内容 |
---|---|
データベース | Compose for MySQLを使用(Code Pattern内で選択) |
ストレージ | ファイル・ストレージ(NFS)使用(Code Pattern内で選択) |
ロードバランス | 外部からの接続方法を追加 |
ポッドのオートスケール | 負荷状況に応じてポッド数を自動で増減 |
投稿メディア | IBM Cloud Object Storage(ICOS)を使用 |
※IBM Cloud Kubernetes Service(IKS)、Compose for MySQLは執筆時点でStandard版以上で有料のPay-As-You-Go(PAYG)が必要となります。
Code Patternsのサンプルでは、Kubernetesで提供されるNodePortという仕組みでポート公開されます。外部のWordPressリンクにアクセスするで、具体的なアクセス方法が紹介されていますが、環境ごとにポート番号が変わってしまい、ポート番号を調べて接続する必要があります。
IngressというKubernetesで提供される内部ロードバランサを利用して、ポート番号をHTTP(80)、証明書付きでHTTPS(443)へのアクセスができるようにします。まずは、基礎である外部のWordPressリンクにアクセスするに書かれている手順を基にアクセスを行えることを確認した上で、以下のマニフェストを作成して、Ingress内部ロードバランサを定義します。
IBM Cloud Kubernetes Serviceが提供するドメイン名を取得します。
$ ibmcloud ks cluster-get --cluster {クラスタ名}
コマンドの結果で、Ingress Subdomain: (日本語表示の場合は入口サブドメイン: )、Ingress Secret: (日本語表示の場合は入口の秘密: )の結果を控えておきます。
Ingress Subdomainが実際にインターネット側からアクセスするためのドメイン名となります。SSLについても証明書が提供されます。
本記事では、IBM Cloud Kubernetes Serviceが提供するドメインを利用しての公開を行いましたが、IBM Cloudのドキュメント内では、独自ドメインでの公開方法も紹介されています。
以下のサンプルを参考に先程控えたIngress SubdomainとIngress Secretに置き換えた上でマニフェストファイルを作成し、KubernetesクラスタへYAMLファイルを適用します。
wordpress-ingress.yml
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: wordpress-ingress spec: tls: - hosts: - {Ingress Subdomain} secretName: {Ingress Secret} rules: - host: {Ingress Subdomain} http: paths: - path: / backend: serviceName: wordpress servicePort: 80
以下コマンドでYAMLファイルの適用を行います。
$ kubectl create -f wordpress-ingress.yml ingress "wordpress-ingress" created
以下コマンドでIngressが適用されたことを確認します。
$ kubectl get ingress NAME HOSTS ADDRESS PORTS AGE wordpress-ingress {IngressSubdomain} {IP-ADDRESS} 80, 443 8s
確認後、Ingress Subdomainをブラウザからアクセスしてみます。
WordPressインストール画面が表示されれば完了です。インストール画面に従って、WordPressのセットアップを行います。
Code Patternsの記事中では、ポッドを手動でスケールアウトする手順が紹介されています。ここで十分なポッドを作っておくことで、大きな負荷に耐えることができるようになりますが、スケーラビリティを向上させるため、負荷が増えたら必要な分のポッド数を増強し、不要になったらポッド数を減らすことができるオーケストレーターを使用したいと思います。
Kubernetesのオーケストレーション技術では現在2つの大きな活動があり、どちらの活動もIBM Cloud Kubernetes Serviceで利用が可能となります。
名称 | 役割 |
---|---|
Horizonal Pod Autoscaler | CPU負荷などに応じてポッドを増減させる |
Cluster Autoscaler | ワーカー・ノードの負荷に応じてサーバ自身を増減させる |
今回は負荷に応じてWordPressアプリケーションコンテナを増減させるHorizonal Pod Autoscalerを利用します。
Horizonal Pod Autoscalerでは、ポッドのCPUの使用率を監視しながら、ポッドのレプリカ数を増減します。AutoscalerがポッドのCPU、メモリ使用率などの情報収集を行うため、Heapster、InfluxDB、Grafanaというパッケージを導入します。
1. 各パッケージのマニフェストYAMLファイルをダウンロード:
$ curl https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/grafana.yaml > grafana.yaml $ curl https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/heapster.yaml > heapster.yaml $ curl https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/influxdb/influxdb.yaml > influxdb.yaml $ curl https://raw.githubusercontent.com/kubernetes/heapster/master/deploy/kube-config/rbac/heapster-rbac.yaml > heapster-rbac.yaml
2. ダウンロードしたマニフェストYAMLファイルを元にポッドのセットアップ:
$ kubectl create -f grafana.yaml deployment "monitoring-grafana" created service "monitoring-grafana" created $ kubectl create -f heapster.yaml serviceaccount "heapster" created deployment "heapster" created service "heapster" created $ kubectl create -f influxdb.yaml deployment "monitoring-influxdb" created service "monitoring-influxdb" created $ kubectl create -f heapster-rbac.yaml clusterrolebinding "heapster" created
3. オートスケール用のマニフェストYAMLを作成・適用する
以下のマニフェストでは、最小で起動時にWordPressのアプリケーションPodを2ポット用意し、各ポッドがCPU70%となったら新たにポッドを作成、最大で5ポッドまでの拡張を行います。
wordpress-hpa.yml
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: wordpress-hpa namespace: default spec: # オートスケールさせるターゲットを設定 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: wordpress # downscaleする最小値 minReplicas: 2 # upscaleする最大値 maxReplicas: 5 # Podの平均CPU使用率の目標値(%の値を設定する) targetCPUUtilizationPercentage: 70
4. オートスケール用マニフェストYAMLファイルの適用
以下コマンドでYAMLファイルの適用を行います。
$ kubectl apply -f wordpress-hpa.yml horizontalpodautoscaler.autoscaling/wordpress-hpa created
以下コマンドでHorizonal Pod Autoscalerが適用されたことを確認します。
kubectl get hpa NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE wordpress-hpa Deployment/wordpress <unknown>/70% 2 5 0 7s
確認後、Ingress Subdomainをブラウザからアクセスしてみます。abコマンドなどで負荷をかけていくとPod数が増減していく様子が見られますので上記コマンドを何度か実行し、確認をしてみてください。YAML内のmaxReplicasを修正していくことで、最大数を自由に変更できます。Nodeやリソースに合わせてこの部分はあとからも変更が可能です。
ここまででポッドへのアクセスが大量になった際に自動的にスケールアップする方法を紹介しました。
IBM Cloud Kubernetes Serviceでは、日本のリージョンでも利用することができ、2018年11月からはアベイラビリティ・ゾーン(AZ)の提供により、物理的に異なるデータセンターでKubernetesノードを定義することができるようになりました。
アベイラビリティ・ゾーンを利用した場合、Ingressの設計がアベイラビリティ・ゾーン対応に修正が必要になるなど、追加点が増えますが、これらを組み合わせることで、突発的な大量アクセスに耐えることのできるシステムづくりが可能となります。
WordPressの標準では、WordPressメディア機能により、WordPressが実行されているサーバ内のwp-contents/uploadsディレクトリ内に画像を保存し、画像のリクエストごとに直接コンテンツをWebサーバ経由で表示するようになります。
上記機能によりNFSストレージに保存された画像を表示する形となりますが、ここでは「IBM Cloud Object Storage」(ICOS)というS3互換のオブジェクトストレージを利用して公開する方法を紹介します。
IBM Cloud Object Storageを利用するメリットは以下の通りです。
IBM Cloud Object Storageには、毎月20GBまで無料となるLiteプランが存在します。LiteプランをIBM Cloudでオーダーし、リージョンをjp-tok、プランをStandardとしました。※IBM Cloud Object Storageの各プランについての説明はこちら
WordPressのPluginとして公開されているMedia Cloudを利用します。プラグインのページからダウンロードし、アップロードするか、プラグイン管理ページから上記名称で検索後、インストール、アクティブ化を行います。
Media Cloudプラグインの設定を行います。WordPress管理画面の左下に「Media Cloud」と書かれた項目があります。以下の内容で設定を行い、ページごとにSave Changesボタンをクリックして保存していきます。
設定ページ名 | 項目 | 値 | 説明 |
---|---|---|---|
Enable/DisableTools | Storage | Enable(チェック) | 自動でメディアをストレージにアップロードする |
Storage Settings | Storage Provider | Other S3 Compatible Service | IBM Cloud Object Storageを利用する場合はこちらを選択 |
Access Key | (access_key_id) | サービス資格情報で取得したaccess_key_id | |
Secret | (secret_access_key) | サービス資格情報で取得したsecret_access_key | |
Bucket | (バケット名) | IBM Cloud Object Storageで作成したバケット名 | |
Region | Automatic | 変更不要 | |
Custom EndpointURL | (URL) | IBM Cloud Object Storageで注文したリージョンに合わせたエンドポイントURL | |
WordPressの画像ファイルをIBM Cloud Object Storageへ格納することが、比較的カンタンにできるようになりました。IBM Cloud Object Storageを活用することで、WordPressのDBや設定情報などをS3互換のストレージへデータバックアップできる仕組みを利用でき、S3互換のストレージを活用する形でKubernetesをはじめ、さまざまなアプリケーションでも再利用ができることが分かりました。
今回は「IBM Cloud Kubernetesサービスを利用してWordPressを立ち上げる」というCodePatternsの記事を使って、アプリケーションをインターネットへ公開することをより現実的に考えた上で、サービスの利用例を説明しました。ご自身で開発されたアプリケーションをKubernetes環境へ組み込んでサービス提供する際に必要なパターンとして、本記事をご参考にしていただければ幸いです。
なお、これらの内容はOSS(オープンソースソフトウェア)であるKubernetesをベースにしています。IBM Cloud Kubernetes Serviceについても開発者とSlackでつながることができ、さまざまな知見を得ることができますから、ぜひ「ここは困った」「こんなことが知りたい」などあれば、日本のユーザーグループコミュニティやIBM Cloud Kubernetes ServiceのSlackでコミュニケーションを取ってみてはいかがでしょうか。
私の記事で最終回となりましたが、今回の一連の記事が、皆さんがいろんな技術に触れる一つのきっかけになれば幸いです。皆さんも、IBM Cloudをはじめ、さまざまなクラウドサービスのいいところを集めて、ご自身のビジネスに役立ててみてはいかがでしょうか。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:日本アイ・ビー・エム株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2019年5月27日