apim
2015/02/09
9 Feb, 2015

[Article] WSO2 API Manager Scalable Deployment Patterns - Part 2

  • Sanjeewa Malalgoda
  • Director - Engineering | Architect at WSO2 - WSO2
Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.

WSO2 API Manager's functional component architecture supports effective deployment of a distributed setup. The choice of deployment option comes down to specific scalable requirements and cost. In the first part of this three-part series, we discussed in detail some key deployment patterns of WSO2 API Manager. This article will focus on single-server, cluster, and cloud deployment; production deployment models; fine-tuning and best practices; and how to solve common problems encountered with deployment patterns.

Introduction

WSO2 API Manager is a complete solution for publishing APIs, creating and managing a developer community, and for scalably routing API traffic. It leverages proven, production-ready, integration, security and governance components from WSO2 Enterprise Service Bus, WSO2 Identity Server, and WSO2 Governance Registry. Moreover, it is powered by WSO2 Business Activity Monitor, thereby making WSO2 API Manager ready for any large-scale deployments right away.

It is important to design an enterprise's server deployment infrastructure based on business information gathered and design requirements. Users need to understand the limitations and identify areas of performance degradation to ensure that they design a deployment model that can perform well, regardless of the load.

WSO2 API Manager provides a scalable and flexible deployment option with complete control over infrastructure and management of APIs. It overcomes the challenges of building cost-effective, future-proof infrastructure that satisfies both the user's and organization's budgets.

WSO2 API Manager's functional component architecture supports effective deployment of a distributed setup. The choice of deployment option comes down to specific scalable requirements and cost. In this part of a three-part series, we will mainly focus on the following areas of discussion:

  • Single-server deployment
  • Cluster (with load balancer) deployment
  • Cloud deployment
  • Production deployment models
  • Fine-tuning and best practices
  • Solving common problems encountered with deployment patterns

When we deploy servers in production deployment, we should design the solution carefully. In this part, we will discuss the different deployment patterns and deployment models of WSO2 API Manager. Most of these deployment patterns are based on real-world use cases. You may have a different solution depending on your exact requirements.

Applies to

WSO2 API Manager Version 1.8.0 and above

Table of contents

  1. How to deploy across zones
  2. Message flows of distributed deployment
  3. Integration with workflow engine
  4. Enabling statistics for WSO2 API Manager
  5. Multi data center deployment
  6. Conclusion

 

How to deploy across zones

Most API Manager distributed production deployments are deployed in multiple zones due to security concerns.

In computer industry, a DMZ or a demilitarized zone is a physical or logical sub network that contains and exposes an organization's external-facing services to a larger and untrusted network (usually the Internet). The purpose of a DMZ is to include an additional layer of security to an organization's local area network (LAN). When it comes to API Manager deployments, most users deploy gateway and store components in a demilitarized zone. The reason for this is that two components are accessed by external users most of the time. Generally in production deployments we allow users to login to the API store and consume APIs. We also allow them to access APIs via the gateway, hence we normally keep them in outer layer.

Usually the API store will communicate with the auth server (which is deployed in the militarized zone) for user login and permission checks. The gateway will communicate with the key manager to validate access tokens. Both these service calls happen from DMZ to MZ. Generally we configure MZ to block external service calls (only servers at DMZ can talk to MZ). Hence, we can safely manage database servers, and authentication and authorization servers at MZ. Sometimes we may see cache attacks to servers deployed in DMZ. To avoid such issues we may disable cache at the gateway side enable cache at the key manager side.

API Manager fully distributed deployment across zones.

 

Message flows of distributed deployment

When we work with distributed deployments it's important to understand message flows between components.

First let's discuss the message flow between components when we login to API store or publisher. As you can see, when a user attempts to login, the system call will first go to the auth server. Then the auth server will call LDAP and thereafter will check the required permissions with permission database.

Let's see how the message flows when the user creates API and published it to the gateway. When the user creates an API from publisher we will store information in the registry and database. Once the user published the API to the gateway, API publisher will call the gateway manager node via web service call and deploy API configuration in synapse runtime. Once the gateway manager is updated with the new artifact, it will commit changes to the svn server (svn server is used as the central repository for deployment synchronization). Thereafter, the gateway manager will send a cluster message and gateway workers will update their APIs with the latest artifacts in the svn server.

 

Let's analyze message flow for API invocation by an external client.

As illustrated in the diagram, the first client requests access token via the API gateway. In the API gateway, we have deployed a token API that is fronted oauth2 app deployed in the key management server. Once the token generation request is received to the auth app, it will validate the user and application details (consumer key and secret key). If the provided information is accurate, the key manager will then return the access token to the user. Thereafter the user will have a valid access token and may call the gateway. The API gateway will accept the API call and go through handlers (first one would be auth handler). The API gateway will talk to the key manager and validate the token. If the user has a valid token, then the auth handler will pass the request and it will go to the throttle handler. Here, we will check throttling counters and the current request and decide if the request can proceed or would need to be blocked. If the request is not blocked it can go through other handlers. Once all handlers are passed we will allow the request to go back to the end server.

Integration with workflow engine

Workflow extensions allow you to attach a custom workflow for various operations in the API Manager such as user signup, application creation, registration, subscription, etc. If you want to have human interaction, approval process, or trigger some external system you can use workflow extension points available in API Manager (https://docs.wso2.com/display/AM180/Adding+Workflow+Extensions). The following diagram explains how you can deploy API Manager with the business process server. You can deploy required artifacts in the business process server and add required configuration changes. If you need high availability for the business process server, then you may use the business process server cluster for your deployment.

Enabling statistics for WSO2 API Manager

Next we will discuss API Manager deployment with WSO2 BAM. For this, in the API Manager gateway, we have the handler to collect all required information from an incoming request. For this kind of deployment we may have a single BAM server, a partially distributed BAM deployment or fully distributed deployment. As shown in the diagram, when API requests comes in, the API gateway will collect the required information and send events to BAM. Then BAM will process them and write to the relational database. Finally, the API publisher will retrieve the summarized data from the database and visualize it in UI. For these types of deployments, we need to configure the usage section of api-manager.xml configuration file properly in the API gateway and publisher. We also need to configure data sources in the BAM and APIM servers. If you have multiple gateway worker nodes then you need to point all of them to the BAM server event receiver.

How the API manager-BAM integration works

Multi data center deployment

Another common deployment type is API manager deployment across data centers (these data centers may be located in different parts of the world). Sometimes we have multiple data centers to avoid network latency and sometimes, to achieve high availability. Nevertheless, when we deploy WSO2 API Manager across data centers, we need to pay special attention to clustering and replication between nodes. For this, we may sometimes create a virtual network across data centers.

When we have this kind of deployment, we normally recommend to run BAM in each data center. The reason for this is we need to publish data to BAM per each API call. If BAM is located in different data centers this may result in massive network level traffic between data centers. API stats will initially persist in the Cassandra server at the data center. Then toolboxes will summarize and push them to the database server (this stats database can be located in the centralized database server and all BAM nodes may write to this). For this, we need to add slight changes to tool boxes deployed in the BAM servers. We may persist data center ID or some kind of attribute to identify data center uniquely. With this, we may analyze stats based on the data center, geographical location, and other requirements.

 

Conclusion

In this article, we discussed the basics of WSO2 API Manager deployments. The part of the series mainly focused on deployments across zones, message flows for user actions, integration with workflows, enabling statistics, and multi data center deployment.. Understanding message flow in distributed deployment will help you to troubleshoot issues in deployments. In the next part of this series, we will discuss more advanced topics like scaling deployments, other patterns, tune up, etc. We will discuss the following topics in detail:

  • Deployment with online/offline monitoring
  • How to scale up and scale out
  • API Façade deployment pattern
  • Amazon EC2 deployment
  • Fine-tune deployment

 

References

[1] https://en.wikipedia.org/wiki/DMZ_(computing)

[2] https://docs.wso2.com/display/AM180/WSO2+API+Manager+Documentation

 

About Author

  • Sanjeewa Malalgoda
  • Director - Engineering | Architect at WSO2
  • WSO2